Draft: draft-ietf-rtcweb-security-arch

Commentary: New chapter for the SDP Identity attribute , including offer / answer procedures . 
 got any comments ? 
 In the interest of time , I 'm going to merge this PR and then make the changes I requested . 
 Raised by   at the interim 
 I think this is now closed by MT 's revision with LOGINNEEDED . 
 Closing .  , please re - open if you believe it is not . 
 Looks good to me , besides the one small correction below . Generally , this looks good to me , modulo the changes that have been suggested by other reviewers . Thanks . This LGTM - consider the one comment I made
Paragraph (version B):
The SDP 'identity' attribute is a session-level attribute that is
used by an endpoint to convey its identity assertion to its peer.
The identity assertion value is encoded as Base-64, as described in
Section 4 of RFC4648.
Paragraph (version B):
The procedures in this section are based on the assumption that the
identity assertion of an endpoint is bound to the fingerprints of the
endpoint.  This does not preclude the definition of alternative means
of binding an assertion to the endpoint, but such means are outside
the scope of this specification.
Paragraph (version B):
The semantics of multiple 'identity' attributes within an offer or
answer are undefined.  Implementations SHOULD only include a single
'identity' attribute in an offer or answer and relying parties MAY
elect to ignore all but the first 'identity' attribute.
Paragraph (version B):
This specification does not define any extensions for the attribute.
Paragraph (version B):
The identity-assertion value is a JSON RFC8259 encoded string.  The
JSON object contains two keys: "assertion" and "idp".  The
"assertion" key value contains an opaque string that is consumed by
the IdP.  The "idp" key value contains a dictionary with one or two
further values that identify the IdP.  See sec.request-assert for
more details.
Paragraph (version B):
This section defines the SDP Offer/Answer RFC6454 considerations for
the SDP 'identity' attribute.
Paragraph (version B):
Within this section, 'initial offer' refers to the first offer in the
SDP session that contains an SDP "identity" attribute.
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 set of fingerprints MUST be the same
as the set to which the identity assertion is bound.
Paragraph (version B):
When an answerer receives an offer that contains an 'identity'
attribute, the answerer can use the the attribute information to
contact the IdP, and verify the identity of the peer.  If the
identity verification fails, the answerer MUST reject the offer.
Paragraph (version B):
When an answerer sends an answer, in order to provide its identity
assertion to the peer, it includes an 'identity' attribute in the
answer.  In addition, the answerer 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):
NOTE: The answerer can choose to include or omit an 'identity'
attribute independently, regardless of whether the offerer did so.
Paragraph (version B):
When the offerer receives an answer that contains an 'identity'
attribute, the offerer can use the attribute information to contact
the IdP, and verify the identity of the peer.  If the identity
verification fails, the offerer MUST take proper actions to reject
the answer.
Paragraph (version B):
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 B):
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 B):
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 B):
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):
The "fingerprint" value is an array of objects.  Each object in the
array contains "algorithm" and "digest" values, which correspond
directly to the algorithm and digest values in the "a=fingerprint"
line of the SDP RFC8122.
Paragraph (version B):
The "fingerprint" value is an array of objects.  Each object in the
array contains "algorithm" and "digest" values, which correspond
directly to the algorithm and digest values in the "fingerprint"
attribute of the SDP RFC8122.
Paragraph (version A):
The identity attribute attests to all "a=fingerprint" attributes in
the session description.  It is therefore a session-level attribute.
Paragraph (version A):
Multiple "a=fingerprint" values can be used to offer alternative
certificates for a peer.  The "a=identity" attribute MUST include all
fingerprint values that are included in "a=fingerprint" lines of the
session description.
Paragraph (version A):
The identity attribute is a session-level attribute only.  It
contains an identity assertion, encoded as a RFC4648.
Paragraph (version A):
No extensions are defined for this attribute.
Paragraph (version A):
The identity assertion is a JSON RFC8259 encoded dictionary that
contains two values.  The "assertion" attribute contains an opaque
string that is consumed by the IdP.  The "idp" attribute is a
dictionary with one or two further values that identify the IdP, as
described in sec.idp-uri.
Paragraph (version A):
An identity assertion as defined in this document relies on the value
of "a=fingerprint" attributes, but this does not preclude the
definition of alternative means of binding an assertion to the
identity of a peer.
Paragraph (version A):
The semantics of multiple identity attributes are undefined.
Implementations SHOULD only include a single identity attribute in an
offer and relying parties MAY elect to ignore all but the first
identity attribute.
Paragraph (version B):
The 'identity' attribute attests to all "fingerprint" attributes in
the session description.  It is therefore a session-level attribute.
Paragraph (version B):
Multiple "fingerprint" values can be used to offer alternative
certificates for a peer.  The "identity" attribute MUST include all
fingerprint values that are included in "fingerprint" attributes of
the session description.
Paragraph (version A):
For use in signaling, the assertion is serialized into JSON, RFC4648,
and used as the value of the "a=identity" attribute.
Paragraph (version B):
For use in signaling, the assertion is serialized into JSON, RFC4648,
and used as the value of the "identity" attribute.
Paragraph (version A):
The input to identity validation is the assertion string taken from a
decoded a=identity attribute.
Paragraph (version B):
The input to identity validation is the assertion string taken from a
decoded 'identity' attribute.