Draft: draft-ietf-rtcweb-security-arch

Commentary: We 'll leave this for later . 
 What 's generic is the protocol , but if you have a third party IdP , trust has to be configured . Say that and point to 7.1 
 See also 5.1.3 . Forward reference to 7.1
Paragraph (version A):
This message is sent to the signaling server, e.g., by XMLHttpRequest
XmlHttpRequest or by WebSockets RFC6455, over TLS RFC5246.  The
signaling server processes the message from Alice's browser,
determines that this is a call to Bob and sends a signaling message
to Bob's browser (again, the format is currently undefined).  The JS
on Bob's browser processes it, and alerts Bob to the incoming call
and to Alice's identity.  In this case, Alice has provided an
identity assertion and so Bob's browser contacts Alice's identity
provider (again, this is done in a generic way so the browser has no
specific knowledge of the IdP) to verify the assertion.  This allows
the browser to display a trusted element in the browser chrome
indicating that a call is coming in from Alice.  If Alice is in Bob's
address book, then this interface might also include her real name, a
picture, etc.  The calling site will also provide some user interface
element (e.g., a button) to allow Bob to answer the call, though this
is most likely not part of the trusted UI.
Paragraph (version B):
This message is sent to the signaling server, e.g., by XMLHttpRequest
XmlHttpRequest or by WebSockets RFC6455, over TLS RFC5246.  The
signaling server processes the message from Alice's browser,
determines that this is a call to Bob and sends a signaling message
to Bob's browser (again, the format is currently undefined).  The JS
on Bob's browser processes it, and alerts Bob to the incoming call
and to Alice's identity.  In this case, Alice has provided an
identity assertion and so Bob's browser contacts Alice's identity
provider (again, this is done in a generic way so the browser has no
specific knowledge of the IdP) to verify the assertion.  It is also
possible to have IdPs with which the browser has a specific
trustrelationship, as described in sec.trust-relationships.  This
allows the browser to display a trusted element in the browser chrome
indicating that a call is coming in from Alice.  If Alice is in Bob's
address book, then this interface might also include her real name, a
picture, etc.  The calling site will also provide some user interface
element (e.g., a button) to allow Bob to answer the call, though this
is most likely not part of the trusted UI.
Paragraph (version A):
When an endpoint receives an offer or answer 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 discard the
offer or answer as malformed.
Paragraph (version B):
When an endpoint receives an offer or answer 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 requires a third-party IdP as described in sec.trust-
relationships then that IdP will need to have been specifically
configured.  If the identity verification fails, the answerer MUST
discard the offer or answer as malformed.