Draft: draft-ietf-rtcweb-security-arch

Commentary: I looked at the deletion issue and I do n't think it 's worth leaving it in as an exception , because you 'd have to DTLS re - handshake anyway .
Paragraph (version A):
When an offerer sends an offer, in order to provide its identity
assertion to the peer, it includes an 'identity' attribute in the
offer.  In addition, the offerer includes one or more SDP
'fingerprint' attributes.  The set of fingerprints MUST be the same
as the set to which the identity assertion is bound.
Paragraph (version B):
When an offerer sends an offer, in order to provide its identity
assertion to the peer, it includes an 'identity' attribute in the
offer.  In addition, the offerer includes one or more SDP
'fingerprint' attributes.  The 'identity' attribute MUST be bound to
all the 'fingerprint' attributes in the session description.
Paragraph (version A):
When an endpoint has provided its identity assertion in a previous
successful offer/answer exchange, and when the endpoint later in the
session sends an offer or answer, the endpoint can either keep the
identity assertion value unchanged, modify the value, or revoke the
identity assertion.  This section describes the procedures for doing
so.
Paragraph (version A):
If the endpoint wants to maintain the previously provided identity
assertion, it MUST include an 'identity' attribute with the
previously provided attribute value in the offer or answer.
Paragraph (version A):
If the endpoint wants to modify its identity assertion within the
session, it MUST include an 'identity' attribute value with the new
identity assertion in the offer or answer.
Paragraph (version A):
If the endpoint maintains or modifies its identity assertion within
the session, it includes one or more SDP 'fingerprint' attributes.
The set of fingerprints MUST be the same as the set to which the
identity assertion is bound.
Paragraph (version A):
If the endpoint wants to revoke its identity assertion from the
session, it MUST NOT include an 'identity' attribute in the offer or
answer.
Paragraph (version A):
Specific usages might restrict the modification and/or revoking of
the identity assertion within a session.  Endpoints can add, modify,
or remove 'fingerprint' attributes when modifying a session.  If a
modified session retains the 'identity' attribute, there MUST be at
least one 'fingerprint' attribute included.
Paragraph (version B):
When modifying a session, if the set of fingerprints is unchanged,
then the sender MAY send the same 'identity' attribute.  In this
case, the established identity SHOULD be applied to existing DTLS
connections as well as new connections established using one of those
fingerprints.  Note that I-D.ietf-rtcweb-jsep, Section 5.2.1 requires
that each media section use the same set of fingerprints for every
media section.
Paragraph (version B):
If the set of fingerprints changes, then the sender MUST either send
a new 'identity' attribute or none at all.  Because a change in
fingerprints also causes a new DTLS connection to be established, the
receiver MUST discard all previously established identities.
Paragraph (version B):
Rewrite the Identity section in more conventional offer/answer
format.
Paragraph (version B):
Clarify rules on changing identities.