draft-ietf-rtcweb-security-arch-18.txt		draft-ietf-rtcweb-security-arch-19.txt
	RTCWEB E. Rescorla		RTCWEB E. Rescorla
	Internet-Draft RTFM, Inc.		Internet-Draft RTFM, Inc.
	Intended status: Standards Track February 1, 2019		Intended status: Standards Track July 7, 2019
	Expires: August 5, 2019		Expires: January 8, 2020
	WebRTC Security Architecture		WebRTC Security Architecture
	draft-ietf-rtcweb-security-arch-18		draft-ietf-rtcweb-security-arch-19
	Abstract		Abstract
	This document defines the security architecture for WebRTC, a		This document defines the security architecture for WebRTC, a
	protocol suite intended for use with real-time applications that can		protocol suite intended for use with real-time applications that can
	be deployed in browsers - "real time communication on the Web".		be deployed in browsers - "real time communication on the Web".
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 5, 2019.		This Internet-Draft will expire on January 8, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 35 ¶		skipping to change at page 3, line 35 ¶
	12.2. Changes since -11 . . . . . . . . . . . . . . . . . . . 37		12.2. Changes since -11 . . . . . . . . . . . . . . . . . . . 37
	12.3. Changes since -10 . . . . . . . . . . . . . . . . . . . 37		12.3. Changes since -10 . . . . . . . . . . . . . . . . . . . 37
	12.4. Changes since -06 . . . . . . . . . . . . . . . . . . . 37		12.4. Changes since -06 . . . . . . . . . . . . . . . . . . . 37
	12.5. Changes since -05 . . . . . . . . . . . . . . . . . . . 38		12.5. Changes since -05 . . . . . . . . . . . . . . . . . . . 38
	12.6. Changes since -03 . . . . . . . . . . . . . . . . . . . 38		12.6. Changes since -03 . . . . . . . . . . . . . . . . . . . 38
	12.7. Changes since -03 . . . . . . . . . . . . . . . . . . . 38		12.7. Changes since -03 . . . . . . . . . . . . . . . . . . . 38
	12.8. Changes since -02 . . . . . . . . . . . . . . . . . . . 38		12.8. Changes since -02 . . . . . . . . . . . . . . . . . . . 38
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
	13.1. Normative References . . . . . . . . . . . . . . . . . . 39		13.1. Normative References . . . . . . . . . . . . . . . . . . 39
	13.2. Informative References . . . . . . . . . . . . . . . . . 42		13.2. Informative References . . . . . . . . . . . . . . . . . 42
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43
	1. Introduction		1. Introduction
	The Real-Time Communications on the Web (WebRTC) working group is		The Real-Time Communications on the Web (RTCWEB) working group
	tasked with standardizing protocols for real-time communications		standardized protocols for real-time communications between Web
	between Web browsers. The major use cases for WebRTC technology are		browsers, generally called "WebRTC" [I-D.ietf-rtcweb-overview]. The
	real-time audio and/or video calls, Web conferencing, and direct data		major use cases for WebRTC technology are real-time audio and/or
	transfer. Unlike most conventional real-time systems, (e.g., SIP-		video calls, Web conferencing, and direct data transfer. Unlike most
	based [RFC3261] soft phones) WebRTC communications are directly		conventional real-time systems, (e.g., SIP-based [RFC3261] soft
	controlled by some Web server, via a JavaScript (JS) API as shown in		phones) WebRTC communications are directly controlled by some Web
	Figure 1.		server, via a JavaScript (JS) API as shown in Figure 1.
	+----------------+		+----------------+
	| |		| |
	| Web Server |		| Web Server |
	| |		| |
	+----------------+		+----------------+
	^ ^		^ ^
	/ \		/ \
	HTTP / \ HTTP		HTTP / \ HTTP
	/ \		/ \
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 28 ¶
	| | Media | |		| | Media | |
	| Browser |<---------->| Browser |		| Browser |<---------->| Browser |
	| | | |		| | | |
	+-----------+ +-----------+		+-----------+ +-----------+
	Figure 1: A simple WebRTC system		Figure 1: A simple WebRTC system
	A more complicated system might allow for interdomain calling, as		A more complicated system might allow for interdomain calling, as
	shown in Figure 2. The protocol to be used between the domains is		shown in Figure 2. The protocol to be used between the domains is
	not standardized by WebRTC, but given the installed base and the form		not standardized by WebRTC, but given the installed base and the form
	of the WebRTC API is likely to be something SDP-based like SIP.		of the WebRTC API is likely to be something SDP-based like SIP or
			something like Extensible Messaging and Presence Protocol (XMPP)
			[RFC6120].
	+--------------+ +--------------+		+--------------+ +--------------+
	| | SIP,XMPP,...| |		| | SIP,XMPP,...| |
	| Web Server |<----------->| Web Server |		| Web Server |<----------->| Web Server |
	| | | |		| | | |
	+--------------+ +--------------+		+--------------+ +--------------+
	^ ^		^ ^
	| |		| |
	HTTP | | HTTP		HTTP | | HTTP
	| |		| |
	skipping to change at page 5, line 47 ¶		skipping to change at page 5, line 49 ¶
	o Calling services: Web sites whose origin we can verify (optimally		o Calling services: Web sites whose origin we can verify (optimally
	via HTTPS, but in some cases because we are on a topologically		via HTTPS, but in some cases because we are on a topologically
	restricted network, such as behind a firewall, and can infer		restricted network, such as behind a firewall, and can infer
	authentication from firewall behavior).		authentication from firewall behavior).
	o Other users: WebRTC peers whose origin we can verify		o Other users: WebRTC peers whose origin we can verify
	cryptographically (optimally via DTLS-SRTP).		cryptographically (optimally via DTLS-SRTP).
	Note that merely being authenticated does not make these entities		Note that merely being authenticated does not make these entities
	trusted. For instance, just because we can verify that		trusted. For instance, just because we can verify that
	https://www.evil.org/ is owned by Dr. Evil does not mean that we can		https://www.example.org/ is owned by Dr. Evil does not mean that we
	trust Dr. Evil to access our camera and microphone. However, it		can trust Dr. Evil to access our camera and microphone. However, it
	gives the user an opportunity to determine whether he wishes to trust		gives the user an opportunity to determine whether he wishes to trust
	Dr. Evil or not; after all, if he desires to contact Dr. Evil		Dr. Evil or not; after all, if he desires to contact Dr. Evil
	(perhaps to arrange for ransom payment), it's safe to temporarily		(perhaps to arrange for ransom payment), it's safe to temporarily
	give him access to the camera and microphone for the purpose of the		give him access to the camera and microphone for the purpose of the
	call, but he doesn't want Dr. Evil to be able to access his camera		call, but he doesn't want Dr. Evil to be able to access his camera
	and microphone other than during the call. The point here is that we		and microphone other than during the call. The point here is that we
	must first identify other elements before we can determine whether		must first identify other elements before we can determine whether
	and how much to trust them. Additionally, sometimes we need to		and how much to trust them. Additionally, sometimes we need to
	identify the communicating peer before we know what policies to		identify the communicating peer before we know what policies to
	apply.		apply.
	skipping to change at page 8, line 39 ¶		skipping to change at page 8, line 41 ¶
	| | +------------------------>| |		| | +------------------------>| |
	+-----------+ +-----------+		+-----------+ +-----------+
	Figure 4: A federated call with IdP-based identity		Figure 4: A federated call with IdP-based identity
	4.1. Initial Signaling		4.1. Initial Signaling
	For simplicity, assume the topology in Figure 3. Alice and Bob are		For simplicity, assume the topology in Figure 3. Alice and Bob are
	both users of a common calling service; they both have approved the		both users of a common calling service; they both have approved the
	calling service to make calls (we defer the discussion of device		calling service to make calls (we defer the discussion of device
	access permissions till later). They are both connected to the		access permissions until later). They are both connected to the
	calling service via HTTPS and so know the origin with some level of		calling service via HTTPS and so know the origin with some level of
	confidence. They also have accounts with some identity provider.		confidence. They also have accounts with some identity provider.
	This sort of identity service is becoming increasingly common in the		This sort of identity service is becoming increasingly common in the
	Web environment (with technologies such as Federated Google Login,		Web environment (with technologies such as Federated Google Login,
	Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as		Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as
	a side effect service of a user's ordinary accounts with some		a side effect service of a user's ordinary accounts with some
	service. In this example, we show Alice and Bob using a separate		service. In this example, we show Alice and Bob using a separate
	identity service, though the identity service may be the same entity		identity service, though the identity service may be the same entity
	as the calling service or there may be no identity service at all.		as the calling service or there may be no identity service at all.
	skipping to change at page 9, line 40 ¶		skipping to change at page 9, line 44 ¶
	Prior to sending out the signaling message, the PeerConnection code		Prior to sending out the signaling message, the PeerConnection code
	contacts the identity service and obtains an assertion binding		contacts the identity service and obtains an assertion binding
	Alice's identity to her fingerprint. The exact details depend on the		Alice's identity to her fingerprint. The exact details depend on the
	identity service (though as discussed in Section 7 PeerConnection can		identity service (though as discussed in Section 7 PeerConnection can
	be agnostic to them), but for now it's easiest to think of as an		be agnostic to them), but for now it's easiest to think of as an
	OAuth token. The assertion may bind other information to the		OAuth token. The assertion may bind other information to the
	identity besides the fingerprint, but at minimum it needs to bind the		identity besides the fingerprint, but at minimum it needs to bind the
	fingerprint.		fingerprint.
	This message is sent to the signaling server, e.g., by XMLHttpRequest		This message is sent to the signaling server, e.g., by XMLHttpRequest
	[XmlHttpRequest] or by WebSockets [RFC6455], preferably over TLS		[XmlHttpRequest] or by WebSockets [RFC6455], over TLS [RFC5246]. The
	[RFC5246]. The signaling server processes the message from Alice's		signaling server processes the message from Alice's browser,
	browser, determines that this is a call to Bob and sends a signaling		determines that this is a call to Bob and sends a signaling message
	message to Bob's browser (again, the format is currently undefined).		to Bob's browser (again, the format is currently undefined). The JS
	The JS on Bob's browser processes it, and alerts Bob to the incoming		on Bob's browser processes it, and alerts Bob to the incoming call
	call and to Alice's identity. In this case, Alice has provided an		and to Alice's identity. In this case, Alice has provided an
	identity assertion and so Bob's browser contacts Alice's identity		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		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		specific knowledge of the IdP) to verify the assertion. It is also
	the browser to display a trusted element in the browser chrome		possible to have IdPs with which the browser has a specific
	indicating that a call is coming in from Alice. If Alice is in Bob's		trustrelationship, as described in Section 7.1. This allows the
	address book, then this interface might also include her real name, a		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		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		element (e.g., a button) to allow Bob to answer the call, though this
	is most likely not part of the trusted UI.		is most likely not part of the trusted UI.
	If Bob agrees a PeerConnection is instantiated with the message from		If Bob agrees a PeerConnection is instantiated with the message from
	Alice's side. Then, a similar process occurs as on Alice's browser:		Alice's side. Then, a similar process occurs as on Alice's browser:
	Bob's browser prompts him for device permission, the media streams		Bob's browser prompts him for device permission, the media streams
	are created, and a return signaling message containing media		are created, and a return signaling message containing media
	information, ICE candidates, and a fingerprint is sent back to Alice		information, ICE candidates, and a fingerprint is sent back to Alice
	via the signaling service. If Bob has a relationship with an IdP,		via the signaling service. If Bob has a relationship with an IdP,
	skipping to change at page 11, line 9 ¶		skipping to change at page 11, line 13 ¶
	is willing to exchange traffic with her and (b) that either Bob is at		is willing to exchange traffic with her and (b) that either Bob is at
	the IP address which she has verified via ICE or there is an attacker		the IP address which she has verified via ICE or there is an attacker
	who is on-path to that IP address detouring the traffic. Note that		who is on-path to that IP address detouring the traffic. Note that
	it is not possible for an attacker who is on-path between Alice and		it is not possible for an attacker who is on-path between Alice and
	Bob but not attached to the signaling service to spoof these checks		Bob but not attached to the signaling service to spoof these checks
	because they do not have the ICE credentials. Bob has the same		because they do not have the ICE credentials. Bob has the same
	security guarantees with respect to Alice.		security guarantees with respect to Alice.
	4.3. DTLS Handshake		4.3. DTLS Handshake
	Once the ICE checks have completed [more specifically, once some ICE		Once the requisite ICE checks have completed, Alice and Bob can set
	checks have completed], Alice and Bob can set up a secure channel or		up a secure channel or channels. This is performed via DTLS
	channels. This is performed via DTLS [RFC6347] and DTLS-SRTP		[RFC6347] and DTLS-SRTP [RFC5763] keying for SRTP [RFC3711] for the
	[RFC5763] keying for SRTP [RFC3711] for the media channel and SCTP		media channel and SCTP over DTLS [RFC8261] for data channels.
	over DTLS [RFC8261] for data channels. Specifically, Alice and Bob		Specifically, Alice and Bob perform a DTLS handshake on every
	perform a DTLS handshake on every component which has been		component which has been established by ICE. The total number of
	established by ICE. The total number of channels depends on the		channels depends on the amount of muxing; in the most likely case we
	amount of muxing; in the most likely case we are using both RTP/RTCP		are using both RTP/RTCP mux and muxing multiple media streams on the
	mux and muxing multiple media streams on the same channel, in which		same channel, in which case there is only one DTLS handshake. Once
	case there is only one DTLS handshake. Once the DTLS handshake has		the DTLS handshake has completed, the keys are exported [RFC5705] and
	completed, the keys are exported [RFC5705] and used to key SRTP for		used to key SRTP for the media channels.
	the media channels.
	At this point, Alice and Bob know that they share a set of secure		At this point, Alice and Bob know that they share a set of secure
	data and/or media channels with keys which are not known to any		data and/or media channels with keys which are not known to any
	third-party attacker. If Alice and Bob authenticated via their IdPs,		third-party attacker. If Alice and Bob authenticated via their IdPs,
	then they also know that the signaling service is not mounting a man-		then they also know that the signaling service is not mounting a man-
	in-the-middle attack on their traffic. Even if they do not use an		in-the-middle attack on their traffic. Even if they do not use an
	IdP, as long as they have minimal trust in the signaling service not		IdP, as long as they have minimal trust in the signaling service not
	to perform a man-in-the-middle attack, they know that their		to perform a man-in-the-middle attack, they know that their
	communications are secure against the signaling service as well		communications are secure against the signaling service as well
	(i.e., that the signaling service cannot mount a passive attack on		(i.e., that the signaling service cannot mount a passive attack on
	skipping to change at page 13, line 5 ¶		skipping to change at page 13, line 5 ¶
	Value: identity-assertion		Value: identity-assertion
	Usage Level: session		Usage Level: session
	Charset Dependent: no		Charset Dependent: no
	Default Value: N/A		Default Value: N/A
	Name: identity		Name: identity
	Syntax:		Syntax:
	identity-assertion = identity-assertion-value		identity-assertion = identity-assertion-value
	*(SP identity-extension)		*(SP identity-extension)
	identity-assertion-value = base64		identity-assertion-value = base64
	identity-extension = extension-name [ "=" extension-value ]		identity-extension = extension-name [ "=" extension-value ]
	extension-name = token		extension-name = token
	extension-value = 1*(%x01-09 / %x0b-0c / %x0e-3a / %x3c-ff)		extension-value = 1*(%x01-09 / %x0b-0c / %x0e-3a / %x3c-ff)
	; byte-string from [RFC4566]		; byte-string from [RFC4566]
	<ALPHA and DIGIT as defined in [RFC4566]>		<ALPHA and DIGIT as defined in [RFC4566]>
	<base64 as defined in [RFC4566]>		<base64 as defined in [RFC4566]>
	Example:		Example:
	a=identity:\		a=identity:\
	eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\		eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\
	In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\		In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\
	IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\		IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\
	aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9		aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9
	Note that long lines in the example are folded to meet the column		Note that long lines in the example are folded to meet the column
	width constraints of this document; the backslash ("\") at the end of		width constraints of this document; the backslash ("\") at the end of
	a line and the carriage return that follows shall be ignored.		a line, the carriage return that follows, and whitespace shall be ignored.
	This specification does not define any extensions for the attribute.		This specification does not define any extensions for the attribute.
	The identity-assertion value is a JSON [RFC8259] encoded string. The		The identity-assertion value is a JSON [RFC8259] encoded string. The
	JSON object contains two keys: "assertion" and "idp". The		JSON object contains two keys: "assertion" and "idp". The
	"assertion" key value contains an opaque string that is consumed by		"assertion" key value contains an opaque string that is consumed by
	the IdP. The "idp" key value contains a dictionary with one or two		the IdP. The "idp" key value contains a dictionary with one or two
	further values that identify the IdP. See Section 7.6 for more		further values that identify the IdP. See Section 7.6 for more
	details.		details.
	skipping to change at page 14, line 18 ¶		skipping to change at page 14, line 18 ¶
	If the answerer elects to include an 'identity' attribute, it follows		If the answerer elects to include an 'identity' attribute, it follows
	the same steps as those in Section 5.1.1. The answerer can choose to		the same steps as those in Section 5.1.1. The answerer can choose to
	include or omit an 'identity' attribute independently, regardless of		include or omit an 'identity' attribute independently, regardless of
	whether the offerer did so.		whether the offerer did so.
	5.1.3. Processing an SDP Offer or Answer		5.1.3. Processing an SDP Offer or Answer
	When an endpoint receives an offer or answer that contains an		When an endpoint receives an offer or answer that contains an
	'identity' attribute, the answerer can use the the attribute		'identity' attribute, the answerer can use the the attribute
	information to contact the IdP, and verify the identity of the peer.		information to contact the IdP and verify the identity of the peer.
	If the identity verification fails, the answerer MUST discard the		If the identity requires a third-party IdP as described in
	offer or answer as malformed.		Section 7.1 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.
	5.1.4. Modifying the Session		5.1.4. Modifying the Session
	When modifying a session, if the set of fingerprints is unchanged,		When modifying a session, if the set of fingerprints is unchanged,
	then the sender MAY send the same 'identity' attribute. In this		then the sender MAY send the same 'identity' attribute. In this
	case, the established identity SHOULD be applied to existing DTLS		case, the established identity MUST be applied to existing DTLS
	connections as well as new connections established using one of those		connections as well as new connections established using one of those
	fingerprints. Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1		fingerprints. Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1
	requires that each media section use the same set of fingerprints for		requires that each media section use the same set of fingerprints for
	every media section.		every media section. If a new identity attribute is received, then
			the receiver MUST apply that identity to all existing connections.
	If the set of fingerprints changes, then the sender MUST either send		If the set of fingerprints changes, then the sender MUST either send
	a new 'identity' attribute or none at all. Because a change in		a new 'identity' attribute or none at all. Because a change in
	fingerprints also causes a new DTLS connection to be established, the		fingerprints also causes a new DTLS connection to be established, the
	receiver MUST discard all previously established identities.		receiver MUST discard all previously established identities.
	6. Detailed Technical Description		6. Detailed Technical Description
	6.1. Origin and Web Security Issues		6.1. Origin and Web Security Issues
	The basic unit of permissions for WebRTC is the origin [RFC6454].		The basic unit of permissions for WebRTC is the origin [RFC6454].
	Because the security of the origin depends on being able to		Because the security of the origin depends on being able to
	authenticate content from that origin, the origin can only be		authenticate content from that origin, the origin can only be
	securely established if data is transferred over HTTPS [RFC2818].		securely established if data is transferred over HTTPS [RFC2818].
	Thus, clients MUST treat HTTP and HTTPS origins as different		Thus, clients MUST treat HTTP and HTTPS origins as different
	permissions domains. [Note: this follows directly from the origin		permissions domains. Note: this follows directly from the origin
	security model and is stated here merely for clarity.]		security model and is stated here merely for clarity.
	Many web browsers currently forbid by default any active mixed		Many web browsers currently forbid by default any active mixed
	content on HTTPS pages. That is, when JavaScript is loaded from an		content on HTTPS pages. That is, when JavaScript is loaded from an
	HTTP origin onto an HTTPS page, an error is displayed and the HTTP		HTTP origin onto an HTTPS page, an error is displayed and the HTTP
	content is not executed unless the user overrides the error. Any		content is not executed unless the user overrides the error. Any
	browser which enforces such a policy will also not permit access to		browser which enforces such a policy will also not permit access to
	WebRTC functionality from mixed content pages (because they never		WebRTC functionality from mixed content pages (because they never
	display mixed content). Browsers which allow active mixed content		display mixed content). Browsers which allow active mixed content
	MUST nevertheless disable WebRTC functionality in mixed content		MUST nevertheless disable WebRTC functionality in mixed content
	settings.		settings.
	skipping to change at page 15, line 34 ¶		skipping to change at page 15, line 38 ¶
	Implementations MUST obtain explicit user consent prior to providing		Implementations MUST obtain explicit user consent prior to providing
	access to the camera and/or microphone. Implementations MUST at		access to the camera and/or microphone. Implementations MUST at
	minimum support the following two permissions models for HTTPS		minimum support the following two permissions models for HTTPS
	origins.		origins.
	o Requests for one-time camera/microphone access.		o Requests for one-time camera/microphone access.
	o Requests for permanent access.		o Requests for permanent access.
	Because HTTP origins cannot be securely established against network		Because HTTP origins cannot be securely established against network
	attackers, implementations MUST NOT allow the setting of permanent		attackers, implementations MUST refuse all permissions grants for
	access permissions for HTTP origins. Implementations MUST refuse all		HTTP origins.
	permissions grants for HTTP origins.
	In addition, they SHOULD support requests for access that promise		In addition, they SHOULD support requests for access that promise
	that media from this grant will be sent to a single communicating		that media from this grant will be sent to a single communicating
	peer (obviously there could be other requests for other peers).		peer (obviously there could be other requests for other peers),
	E.g., "Call customerservice@ford.com". The semantics of this request		eE.g., "Call customerservice@example.org". The semantics of this
	are that the media stream from the camera and microphone will only be		request are that the media stream from the camera and microphone will
	routed through a connection which has been cryptographically verified		only be routed through a connection which has been cryptographically
	(through the IdP mechanism or an X.509 certificate in the DTLS-SRTP		verified (through the IdP mechanism or an X.509 certificate in the
	handshake) as being associated with the stated identity. Note that		DTLS-SRTP handshake) as being associated with the stated identity.
	it is unlikely that browsers would have an X.509 certificate, but		Note that it is unlikely that browsers would have X.509 certificates,
	servers might. Browsers servicing such requests SHOULD clearly		but servers might. Browsers servicing such requests SHOULD clearly
	indicate that identity to the user when asking for permission. The		indicate that identity to the user when asking for permission. The
	idea behind this type of permissions is that a user might have a		idea behind this type of permissions is that a user might have a
	fairly narrow list of peers he is willing to communicate with, e.g.,		fairly narrow list of peers he is willing to communicate with, e.g.,
	"my mother" rather than "anyone on Facebook". Narrow permissions		"my mother" rather than "anyone on Facebook". Narrow permissions
	grants allow the browser to do that enforcement.		grants allow the browser to do that enforcement.
	API Requirement: The API MUST provide a mechanism for the requesting		API Requirement: The API MUST provide a mechanism for the requesting
	JS to relinquish the ability to see or modify the media (e.g., via		JS to relinquish the ability to see or modify the media (e.g., via
	MediaStream.record()). Combined with secure authentication of the		MediaStream.record()). Combined with secure authentication of the
	communicating peer, this allows a user to be sure that the calling		communicating peer, this allows a user to be sure that the calling
	skipping to change at page 16, line 42 ¶		skipping to change at page 16, line 43 ¶
	o Browsers MUST provide a separate dialog request for screen/		o Browsers MUST provide a separate dialog request for screen/
	application sharing permissions even if the media request is made		application sharing permissions even if the media request is made
	at the same time as camera and microphone.		at the same time as camera and microphone.
	o The browser MUST indicate any windows which are currently being		o The browser MUST indicate any windows which are currently being
	shared in some unambiguous way. Windows which are not visible		shared in some unambiguous way. Windows which are not visible
	MUST NOT be shared even if the application is being shared. If		MUST NOT be shared even if the application is being shared. If
	the screen is being shared, then that MUST be indicated.		the screen is being shared, then that MUST be indicated.
	Clients MAY permit the formation of data channels without any direct		Browsers MAY permit the formation of data channels without any direct
	user approval. Because sites can always tunnel data through the		user approval. Because sites can always tunnel data through the
	server, further restrictions on the data channel do not provide any		server, further restrictions on the data channel do not provide any
	additional security. (though see Section 6.3 for a related issue).		additional security. (See Section 6.3 for a related issue).
	Implementations which support some form of direct user authentication		Implementations which support some form of direct user authentication
	SHOULD also provide a policy by which a user can authorize calls only		SHOULD also provide a policy by which a user can authorize calls only
	to specific communicating peers. Specifically, the implementation		to specific communicating peers. Specifically, the implementation
	SHOULD provide the following interfaces/controls:		SHOULD provide the following interfaces/controls:
	o Allow future calls to this verified user.		o Allow future calls to this verified user.
	o Allow future calls to any verified user who is in my system		o Allow future calls to any verified user who is in my system
	address book (this only works with address book integration, of		address book (this only works with address book integration, of
	skipping to change at page 17, line 43 ¶		skipping to change at page 17, line 43 ¶
	requires that implementations respond to such requests, so this		requires that implementations respond to such requests, so this
	approach is maximally compatible. A separate document will profile		approach is maximally compatible. A separate document will profile
	the ICE timers to be used; see [RFC7675].		the ICE timers to be used; see [RFC7675].
	6.4. IP Location Privacy		6.4. IP Location Privacy
	A side effect of the default ICE behavior is that the peer learns		A side effect of the default ICE behavior is that the peer learns
	one's IP address, which leaks large amounts of location information.		one's IP address, which leaks large amounts of location information.
	This has negative privacy consequences in some circumstances. The		This has negative privacy consequences in some circumstances. The
	API requirements in this section are intended to mitigate this issue.		API requirements in this section are intended to mitigate this issue.
	Note that these requirements are NOT intended to protect the user's		Note that these requirements are not intended to protect the user's
	IP address from a malicious site. In general, the site will learn at		IP address from a malicious site. In general, the site will learn at
	least a user's server reflexive address from any HTTP transaction.		least a user's server reflexive address from any HTTP transaction.
	Rather, these requirements are intended to allow a site to cooperate		Rather, these requirements are intended to allow a site to cooperate
	with the user to hide the user's IP address from the other side of		with the user to hide the user's IP address from the other side of
	the call. Hiding the user's IP address from the server requires some		the call. Hiding the user's IP address from the server requires some
	sort of explicit privacy preserving mechanism on the client (e.g.,		sort of explicit privacy preserving mechanism on the client (e.g.,
	Tor Browser [https://www.torproject.org/projects/torbrowser.html.en])		Tor Browser [https://www.torproject.org/projects/torbrowser.html.en])
	and is out of scope for this specification.		and is out of scope for this specification.
	API Requirement: The API MUST provide a mechanism to allow the JS to		API Requirement: The API MUST provide a mechanism to allow the JS to
	skipping to change at page 18, line 28 ¶		skipping to change at page 18, line 28 ¶
	API Requirement: The API MUST provide a mechanism for the calling		API Requirement: The API MUST provide a mechanism for the calling
	application to reconfigure an existing call to add non-TURN		application to reconfigure an existing call to add non-TURN
	candidates. Taken together, this and the previous requirement		candidates. Taken together, this and the previous requirement
	allow ICE negotiation to start immediately on incoming call		allow ICE negotiation to start immediately on incoming call
	notification, thus reducing post-dial delay, but also to avoid		notification, thus reducing post-dial delay, but also to avoid
	disclosing the user's IP address until they have decided to		disclosing the user's IP address until they have decided to
	answer. They also allow users to completely hide their IP address		answer. They also allow users to completely hide their IP address
	for the duration of the call. Finally, they allow a mechanism for		for the duration of the call. Finally, they allow a mechanism for
	the user to optimize performance by reconfiguring to allow non-		the user to optimize performance by reconfiguring to allow non-
	turn candidates during an active call if the user decides they no		TURN candidates during an active call if the user decides they no
	longer need to hide their IP address		longer need to hide their IP address
	Note that some enterprises may operate proxies and/or NATs designed		Note that some enterprises may operate proxies and/or NATs designed
	to hide internal IP addresses from the outside world. WebRTC		to hide internal IP addresses from the outside world. WebRTC
	provides no explicit mechanism to allow this function. Either such		provides no explicit mechanism to allow this function. Either such
	enterprises need to proxy the HTTP/HTTPS and modify the SDP and/or		enterprises need to proxy the HTTP/HTTPS and modify the SDP and/or
	the JS, or there needs to be browser support to set the "TURN-only"		the JS, or there needs to be browser support to set the "TURN-only"
	policy regardless of the site's preferences.		policy regardless of the site's preferences.
	6.5. Communications Security		6.5. Communications Security
	Implementations MUST implement SRTP [RFC3711]. Implementations MUST		Implementations MUST support SRTP [RFC3711]. Implementations MUST
	implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP		support DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP
	keying. Implementations MUST implement [RFC8261].		keying. Implementations MUST support SCTP over DTLS [RFC8261].
	All media channels MUST be secured via SRTP and SRTCP. Media traffic		All media channels MUST be secured via SRTP and SRTCP. Media traffic
	MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is,		MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is,
	implementations MUST NOT negotiate cipher suites with NULL encryption		implementations MUST NOT negotiate cipher suites with NULL encryption
	modes. DTLS-SRTP MUST be offered for every media channel. WebRTC		modes. DTLS-SRTP MUST be offered for every media channel. WebRTC
	implementations MUST NOT offer SDP Security Descriptions [RFC4568] or		implementations MUST NOT offer SDP Security Descriptions [RFC4568] or
	select it if offered. A SRTP MKI MUST NOT be used.		select it if offered. A SRTP MKI MUST NOT be used.
	All data channels MUST be secured via DTLS.		All data channels MUST be secured via DTLS.
	All Implementations MUST implement DTLS 1.2 with the		All Implementations MUST support DTLS 1.2 with the
	TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256		TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256
	curve [FIPS186]. Earlier drafts of this specification required DTLS		curve [FIPS186]. Earlier drafts of this specification required DTLS
	1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and		1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and
	at the time of this writing some implementations do not support DTLS		at the time of this writing some implementations do not support DTLS
	1.2; endpoints which support only DTLS 1.2 might encounter		1.2; endpoints which support only DTLS 1.2 might encounter
	interoperability issues. The DTLS-SRTP protection profile		interoperability issues. The DTLS-SRTP protection profile
	SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.		SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.
	Implementations MUST favor cipher suites which support (Perfect		Implementations MUST favor cipher suites which support (Perfect
	Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD		Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD
	over non-AEAD cipher suites.		over non-AEAD cipher suites.
	skipping to change at page 20, line 20 ¶		skipping to change at page 20, line 20 ¶
	party verifiable X.509 certificate or via a Web IdP mechanism		party verifiable X.509 certificate or via a Web IdP mechanism
	(see Section 7) the "security characteristics" MUST include the		(see Section 7) the "security characteristics" MUST include the
	verified information. X.509 identities and Web IdP identities		verified information. X.509 identities and Web IdP identities
	have similar semantics and should be displayed in a similar		have similar semantics and should be displayed in a similar
	way.		way.
	The following properties are more likely to require some "drill-		The following properties are more likely to require some "drill-
	down" from the user:		down" from the user:
	* The "security characteristics" MUST indicate the cryptographic		* The "security characteristics" MUST indicate the cryptographic
	algorithms in use (For example: "AES-CBC".) However, if Null		algorithms in use (For example: "AES-CBC".)
	ciphers are used, that MUST be presented to the user at the
	top-level UI.
	* The "security characteristics" MUST indicate whether PFS is		* The "security characteristics" MUST indicate whether PFS is
	provided.		provided.
	* The "security characteristics" MUST include some mechanism to		* The "security characteristics" MUST include some mechanism to
	allow an out-of-band verification of the peer, such as a		allow an out-of-band verification of the peer, such as a
	certificate fingerprint or a Short Authentication String (SAS).		certificate fingerprint or a Short Authentication String (SAS).
			These are compared by the peers to authenticate one another.
	7. Web-Based Peer Authentication		7. Web-Based Peer Authentication
	In a number of cases, it is desirable for the endpoint (i.e., the		In a number of cases, it is desirable for the endpoint (i.e., the
	browser) to be able to directly identify the endpoint on the other		browser) to be able to directly identify the endpoint on the other
	side without trusting the signaling service to which they are		side without trusting the signaling service to which they are
	connected. For instance, users may be making a call via a federated		connected. For instance, users may be making a call via a federated
	system where they wish to get direct authentication of the other		system where they wish to get direct authentication of the other
	side. Alternately, they may be making a call on a site which they		side. Alternately, they may be making a call on a site which they
	minimally trust (such as a poker site) but to someone who has an		minimally trust (such as a poker site) but to someone who has an
	identity on a site they do trust (such as a social network.)		identity on a site they do trust (such as a social network.)
	Recently, a number of Web-based identity technologies (OAuth,		Recently, a number of Web-based identity technologies (OAuth,
	Facebook Connect etc.) have been developed. While the details vary,		Facebook Connect etc.) have been developed. While the details vary,
	what these technologies share is that they have a Web-based (i.e.,		what these technologies share is that they have a Web-based (i.e.,
	HTTP/HTTPS) identity provider which attests to your identity. For		HTTP/HTTPS) identity provider which attests to Alice's identity. For
	instance, if I have an account at example.org, I could use the		instance, if Alice has an account at example.org, Alice could use the
	example.org identity provider to prove to others that I was		example.org identity provider to prove to others that Alice is
	alice@example.org. The development of these technologies allows us		alice@example.org. The development of these technologies allows us
	to separate calling from identity provision: I could call you on		to separate calling from identity provision: Alice could call you on
	Poker Galaxy but identify myself as alice@example.org.		a poker site but identify herself as alice@example.org.
	Whatever the underlying technology, the general principle is that the		Whatever the underlying technology, the general principle is that the
	party which is being authenticated is NOT the signaling site but		party which is being authenticated is NOT the signaling site but
	rather the user (and their browser). Similarly, the relying party is		rather the user (and their browser). Similarly, the relying party is
	the browser and not the signaling site. Thus, the browser MUST		the browser and not the signaling site. Thus, the browser MUST
	generate the input to the IdP assertion process and display the		generate the input to the IdP assertion process and display the
	results of the verification process to the user in a way which cannot		results of the verification process to the user in a way which cannot
	be imitated by the calling site.		be imitated by the calling site.
	The mechanisms defined in this document do not require the browser to		The mechanisms defined in this document do not require the browser to
	skipping to change at page 25, line 6 ¶		skipping to change at page 25, line 6 ¶
	7.4. Binding Identity Assertions to JSEP Offer/Answer Transactions		7.4. Binding Identity Assertions to JSEP Offer/Answer Transactions
	An identity assertion binds the user's identity (as asserted by the		An identity assertion binds the user's identity (as asserted by the
	IdP) to the SDP offer/answer exchange and specifically to the media.		IdP) to the SDP offer/answer exchange and specifically to the media.
	In order to achieve this, the PeerConnection must provide the DTLS-		In order to achieve this, the PeerConnection must provide the DTLS-
	SRTP fingerprint to be bound to the identity. This is provided as a		SRTP fingerprint to be bound to the identity. This is provided as a
	JavaScript object (also known as a dictionary or hash) with a single		JavaScript object (also known as a dictionary or hash) with a single
	"fingerprint" key, as shown below:		"fingerprint" key, as shown below:
	{		{
	"fingerprint": [ {		"fingerprint":
	"algorithm": "sha-256",		[
	"digest": "4A:AD:B9:B1:3F:...:E5:7C:AB"		{ "algorithm": "sha-256",
	}, {		"digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" },
	"algorithm": "sha-1",		{ "algorithm": "sha-1",
	"digest": "74:E9:76:C8:19:...:F4:45:6B"		"digest": "74:E9:76:C8:19:...:F4:45:6B" }
	} ]		]
	}		}
	The "fingerprint" value is an array of objects. Each object in the		The "fingerprint" value is an array of objects. Each object in the
	array contains "algorithm" and "digest" values, which correspond		array contains "algorithm" and "digest" values, which correspond
	directly to the algorithm and digest values in the "fingerprint"		directly to the algorithm and digest values in the "fingerprint"
	attribute of the SDP [RFC8122].		attribute of the SDP [RFC8122].
	This object is encoded in a JSON [RFC8259] string for passing to the		This object is encoded in a JSON [RFC8259] string for passing to the
	IdP. The identity assertion returned by the IdP, which is encoded in		IdP. The identity assertion returned by the IdP, which is encoded in
	the "identity" attribute, is a JSON object that is encoded as		the "identity" attribute, is a JSON object that is encoded as
	skipping to change at page 26, line 5 ¶		skipping to change at page 26, line 5 ¶
	7.4.1. Carrying Identity Assertions		7.4.1. Carrying Identity Assertions
	Once an IdP has generated an assertion (see Section 7.6), it is		Once an IdP has generated an assertion (see Section 7.6), it is
	attached to the SDP offer/answer message. This is done by adding a		attached to the SDP offer/answer message. This is done by adding a
	new 'identity' attribute to the SDP. The sole contents of this value		new 'identity' attribute to the SDP. The sole contents of this value
	is the identity assertion. The identity assertion produced by the		is the identity assertion. The identity assertion produced by the
	IdP is encoded into a UTF-8 JSON text, then Base64-encoded [RFC4648]		IdP is encoded into a UTF-8 JSON text, then Base64-encoded [RFC4648]
	to produce this string. For example:		to produce this string. For example:
	v=0		v=0
	o=- 1181923068 1181923196 IN IP4 ua1.example.com		o=- 1181923068 1181923196 IN IP4 ua1.example.com
	s=example1		s=example1
	c=IN IP4 ua1.example.com		c=IN IP4 ua1.example.com
	a=fingerprint:sha-1 \		a=fingerprint:sha-1 \
	4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB		4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
	a=identity:\		a=identity:\
	eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\		eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\
	In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\		In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\
	IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\		IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\
	aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9		aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9
	a=...		a=...
	t=0 0		t=0 0
	m=audio 6056 RTP/SAVP 0		m=audio 6056 RTP/SAVP 0
	a=sendrecv		a=sendrecv
	...		...
	Note that long lines in the example are folded to meet the column		Note that long lines in the example are folded to meet the column
	width constraints of this document; the backslash ("\") at the end of		width constraints of this document; the backslash ("\") at the end of
	a line and the carriage return that follows shall be ignored.		a line, the carriage return that follows, and whitespace shall be ignored.
	The 'identity' attribute attests to all "fingerprint" attributes in		The 'identity' attribute attests to all "fingerprint" attributes in
	the session description. It is therefore a session-level attribute.		the session description. It is therefore a session-level attribute.
	Multiple "fingerprint" values can be used to offer alternative		Multiple "fingerprint" values can be used to offer alternative
	certificates for a peer. The "identity" attribute MUST include all		certificates for a peer. The "identity" attribute MUST include all
	fingerprint values that are included in "fingerprint" attributes of		fingerprint values that are included in "fingerprint" attributes of
	the session description.		the session description.
	The RP browser MUST verify that the in-use certificate for a DTLS		The RP browser MUST verify that the in-use certificate for a DTLS
	skipping to change at page 26, line 47 ¶		skipping to change at page 26, line 47 ¶
	7.5. Determining the IdP URI		7.5. Determining the IdP URI
	In order to ensure that the IdP is under control of the domain owner		In order to ensure that the IdP is under control of the domain owner
	rather than someone who merely has an account on the domain owner's		rather than someone who merely has an account on the domain owner's
	server (e.g., in shared hosting scenarios), the IdP JavaScript is		server (e.g., in shared hosting scenarios), the IdP JavaScript is
	hosted at a deterministic location based on the IdP's domain name.		hosted at a deterministic location based on the IdP's domain name.
	Each IdP proxy instance is associated with two values:		Each IdP proxy instance is associated with two values:
	Authority: The authority [RFC3986] at which the IdP's service is		Authority: The authority [RFC3986] at which the IdP's service is
	hosted. Note that this may include a non-default port or a		hosted.
	userinfo component, but neither will be available in a certificate
	verifying the site.
	protocol: The specific IdP protocol which the IdP is using. This is		protocol: The specific IdP protocol which the IdP is using. This is
	a completely opaque IdP-specific string, but allows an IdP to		a completely opaque IdP-specific string, but allows an IdP to
	implement two protocols in parallel. This value may be the empty		implement two protocols in parallel. This value may be the empty
	string. If no value for protocol is provided, a value of		string. If no value for protocol is provided, a value of
	"default" is used.		"default" is used.
	Each IdP MUST serve its initial entry page (i.e., the one loaded by		Each IdP MUST serve its initial entry page (i.e., the one loaded by
	the IdP proxy) from a well-known URI [RFC5785]. The well-known URI		the IdP proxy) from a well-known URI [RFC5785]. The well-known URI
	for an IdP proxy is formed from the following URI components:		for an IdP proxy is formed from the following URI components:
	skipping to change at page 28, line 49 ¶		skipping to change at page 28, line 49 ¶
	identify a different IdP or protocol from the one that generated		identify a different IdP or protocol from the one that generated
	the assertion.		the assertion.
	assertion: An opaque value containing the assertion itself. This is		assertion: An opaque value containing the assertion itself. This is
	only interpretable by the identified IdP or the IdP code running		only interpretable by the identified IdP or the IdP code running
	in the client.		in the client.
	Figure 5 shows an example assertion formatted as JSON. In this case,		Figure 5 shows an example assertion formatted as JSON. In this case,
	the message has presumably been digitally signed/MACed in some way		the message has presumably been digitally signed/MACed in some way
	that the IdP can later verify it, but this is an implementation		that the IdP can later verify it, but this is an implementation
	detail and out of scope of this document. Line breaks are inserted		detail and out of scope of this document.
	solely for readability.
	{		{
	"idp":{		"idp":{
	"domain": "example.org",		"domain": "example.org",
	"protocol": "bogus"		"protocol": "bogus"
	},		},
	"assertion": "{\"identity\":\"bob@example.org\",		"assertion": "{\"identity\":\"bob@example.org\",
	\"contents\":\"abcdefghijklmnopqrstuvwyz\",		\"contents\":\"abcdefghijklmnopqrstuvwyz\",
	\"signature\":\"010203040506\"}"		\"signature\":\"010203040506\"}"
	}		}
	Figure 5: Example assertion		Figure 5: Example assertion
	For use in signaling, the assertion is serialized into JSON,		For use in signaling, the assertion is serialized into JSON,
	Base64-encoded [RFC4648], and used as the value of the "identity"		Base64-encoded [RFC4648], and used as the value of the "identity"
	attribute.		attribute. IdPs SHOULD ensure that any assertions they generate
			cannot be interpreted in a different context. E.g., they should use
			a distinct format or have separate cryptographic keys for assertion
			generation and other purposes. Line breaks are inserted solely for
			readability.
	7.7. Managing User Login		7.7. Managing User Login
	In order to generate an identity assertion, the IdP needs proof of		In order to generate an identity assertion, the IdP needs proof of
	the user's identity. It is common practice to authenticate users		the user's identity. It is common practice to authenticate users
	(using passwords or multi-factor authentication), then use Cookies		(using passwords or multi-factor authentication), then use Cookies
	[RFC6265] or HTTP authentication [RFC7617] for subsequent exchanges.		[RFC6265] or HTTP authentication [RFC7617] for subsequent exchanges.
	The IdP proxy is able to access cookies, HTTP authentication or other		The IdP proxy is able to access cookies, HTTP authentication or other
	persistent session data because it operates in the security context		persistent session data because it operates in the security context
	skipping to change at page 30, line 16 ¶		skipping to change at page 30, line 21 ¶
	Regardless of the mechanism, if verification succeeds, a successful		Regardless of the mechanism, if verification succeeds, a successful
	response from the IdP proxy consists of the following information:		response from the IdP proxy consists of the following information:
	identity: The identity of the AP from the IdP's perspective.		identity: The identity of the AP from the IdP's perspective.
	Details of this are provided in Section 8.1.		Details of this are provided in Section 8.1.
	contents: The original unmodified string provided by the AP as input		contents: The original unmodified string provided by the AP as input
	to the assertion generation process.		to the assertion generation process.
	Figure 6 shows an example response formatted as JSON for illustrative		Figure 6 shows an example response, which is JSON-formatted.
	purposes.
	{		{
	"identity": "bob@example.org",		"identity": "bob@example.org",
	"contents": "{\"fingerprint\":[ ... ]}"		"contents": "{\"fingerprint\":[ ... ]}"
	}		}
	Figure 6: Example verification result		Figure 6: Example verification result
	8.1. Identity Formats		8.1. Identity Formats
	The identity provided from the IdP to the RP browser MUST consist of		The identity provided from the IdP to the RP browser MUST consist of
	a string representing the user's identity. This string is in the		a string representing the user's identity. This string is in the
	form "<user>@<domain>", where "user" consists of any character except		form "<user>@<domain>", where "user" consists of any character, and
	'@', and domain is an internationalized domain name [RFC5890] encoded		domain is aninternationalized domain name [RFC5890] encoded as a
	as a sequence of U-labels.		sequence of U-labels.
	The PeerConnection API MUST check this string as follows:		The PeerConnection API MUST check this string as follows:
	1. If the domain portion of the string is equal to the domain name		1. If the "domain" portion of the string is equal to the domain name
	of the IdP proxy, then the assertion is valid, as the IdP is		of the IdP proxy, then the assertion is valid, as the IdP is
	authoritative for this domain. Comparison of domain names is		authoritative for this domain. Comparison of domain names is
	done using the label equivalence rule defined in Section 2.3.2.4		done using the label equivalence rule defined in Section 2.3.2.4
	of [RFC5890].		of [RFC5890].
	2. If the domain portion of the string is not equal to the domain		2. If the "domain" portion of the string is not equal to the domain
	name of the IdP proxy, then the PeerConnection object MUST reject		name of the IdP proxy, then the PeerConnection object MUST reject
	the assertion unless:		the assertion unless both:
	1. the IdP domain is trusted as an acceptable third-party IdP;		1. the IdP domain is trusted as an acceptable third-party IdP;
	and		and
	2. local policy is configured to trust this IdP domain for the		2. local policy is configured to trust this IdP domain for the
	domain portion of the identity string.		domain portion of the identity string.
	Any "@" or "%" characters in the "user" portion of the identity MUST		Any "@" or "%" characters in the "user" portion of the identity MUST
	be escaped according to the "Percent-Encoding" rules defined in		be escaped according to the "Percent-Encoding" rules defined in
	Section 2.1 of [RFC3986]. Characters other than "@" and "%" MUST NOT		Section 2.1 of [RFC3986]. Characters other than "@" and "%" MUST NOT
	be percent-encoded. For example, with a user of "user@133" and a		be percent-encoded. For example, with a "user" of "user@133" and a
	domain of "identity.example.com", the resulting string will be		"domain" of "identity.example.com", the resulting string will be
	encoded as "user%40133@identity.example.com".		encoded as "user%40133@identity.example.com".
	Implementations are cautioned to take care when displaying user		Implementations are cautioned to take care when displaying user
	identities containing escaped "@" characters. If such characters are		identities containing escaped "@" characters. If such characters are
	unescaped prior to display, implementations MUST distinguish between		unescaped prior to display, implementations MUST distinguish between
	the domain of the IdP proxy and any domain that might be implied by		the domain of the IdP proxy and any domain that might be implied by
	the portion of the <user> portion that appears after the escaped "@"		the portion of the "<user>" portion that appears after the escaped
	sign.		"@" sign.
	9. Security Considerations		9. Security Considerations
	Much of the security analysis of this problem is contained in		Much of the security analysis of this problem is contained in
	[I-D.ietf-rtcweb-security] or in the discussion of the particular		[I-D.ietf-rtcweb-security] or in the discussion of the particular
	issues above. In order to avoid repetition, this section focuses on		issues above. In order to avoid repetition, this section focuses on
	(a) residual threats that are not addressed by this document and (b)		(a) residual threats that are not addressed by this document and (b)
	threats produced by failure/misbehavior of one of the components in		threats produced by failure/misbehavior of one of the components in
	the system.		the system.
	skipping to change at page 31, line 46 ¶		skipping to change at page 31, line 49 ¶
	Even if HTTPS is used, the signaling server can potentially mount a		Even if HTTPS is used, the signaling server can potentially mount a
	man-in-the-middle attack unless implementations have some mechanism		man-in-the-middle attack unless implementations have some mechanism
	for independently verifying keys. The UI requirements in Section 6.5		for independently verifying keys. The UI requirements in Section 6.5
	are designed to provide such a mechanism for motivated/security		are designed to provide such a mechanism for motivated/security
	conscious users, but are not suitable for general use. The identity		conscious users, but are not suitable for general use. The identity
	service mechanisms in Section 7 are more suitable for general use.		service mechanisms in Section 7 are more suitable for general use.
	Note, however, that a malicious signaling service can strip off any		Note, however, that a malicious signaling service can strip off any
	such identity assertions, though it cannot forge new ones. Note that		such identity assertions, though it cannot forge new ones. Note that
	all of the third-party security mechanisms available (whether X.509		all of the third-party security mechanisms available (whether X.509
	certificates or a third-party IdP) rely on the security of the third		certificates or a third-party IdP) rely on the security of the third
	party--this is of course also true of your connection to the Web site		party--this is of course also true of the user's connection to the
	itself. Users who wish to assure themselves of security against a		Web site itself. Users who wish to assure themselves of security
	malicious identity provider can only do so by verifying peer		against a malicious identity provider can only do so by verifying
	credentials directly, e.g., by checking the peer's fingerprint		peer credentials directly, e.g., by checking the peer's fingerprint
	against a value delivered out of band.		against a value delivered out of band.
	In order to protect against malicious content JavaScript, that		In order to protect against malicious content JavaScript, that
	JavaScript MUST NOT be allowed to have direct access to---or perform		JavaScript MUST NOT be allowed to have direct access to---or perform
	computations with---DTLS keys. For instance, if content JS were able		computations with---DTLS keys. For instance, if content JS were able
	to compute digital signatures, then it would be possible for content		to compute digital signatures, then it would be possible for content
	JS to get an identity assertion for a browser's generated key and		JS to get an identity assertion for a browser's generated key and
	then use that assertion plus a signature by the key to authenticate a		then use that assertion plus a signature by the key to authenticate a
	call protected under an ephemeral Diffie-Hellman (DH) key controlled		call protected under an ephemeral Diffie-Hellman (DH) key controlled
	by the content JS, thus violating the security guarantees otherwise		by the content JS, thus violating the security guarantees otherwise
	skipping to change at page 32, line 49 ¶		skipping to change at page 32, line 51 ¶
	privacy against the calling sites they are using must use separate		privacy against the calling sites they are using must use separate
	privacy enhancing technologies such as Tor. Combined WebRTC/Tor		privacy enhancing technologies such as Tor. Combined WebRTC/Tor
	implementations SHOULD arrange to route the media as well as the		implementations SHOULD arrange to route the media as well as the
	signaling through Tor. Currently this will produce very suboptimal		signaling through Tor. Currently this will produce very suboptimal
	performance.		performance.
	Additionally, any identifier which persists across multiple calls is		Additionally, any identifier which persists across multiple calls is
	potentially a problem for privacy, especially for anonymous calling		potentially a problem for privacy, especially for anonymous calling
	services. Such services SHOULD instruct the browser to use separate		services. Such services SHOULD instruct the browser to use separate
	DTLS keys for each call and also to use TURN throughout the call.		DTLS keys for each call and also to use TURN throughout the call.
	Otherwise, the other side will learn linkable information.		Otherwise, the other side will learn linkable information that would
			allow them to correlate the browser across multiple calls.
	Additionally, browsers SHOULD implement the privacy-preserving CNAME		Additionally, browsers SHOULD implement the privacy-preserving CNAME
	generation mode of [RFC7022].		generation mode of [RFC7022].
	9.3. Denial of Service		9.3. Denial of Service
	The consent mechanisms described in this document are intended to		The consent mechanisms described in this document are intended to
	mitigate denial of service attacks in which an attacker uses clients		mitigate denial of service attacks in which an attacker uses clients
	to send large amounts of traffic to a victim without the consent of		to send large amounts of traffic to a victim without the consent of
	the victim. While these mechanisms are sufficient to protect victims		the victim. While these mechanisms are sufficient to protect victims
	who have not implemented WebRTC at all, WebRTC implementations need		who have not implemented WebRTC at all, WebRTC implementations need
	skipping to change at page 35, line 18 ¶		skipping to change at page 35, line 18 ¶
	may learn the user's identity from the perspective of the IdP. In		may learn the user's identity from the perspective of the IdP. In
	many cases this is not an issue because the user is authenticating to		many cases this is not an issue because the user is authenticating to
	the site via the IdP in any case, for instance when the user has		the site via the IdP in any case, for instance when the user has
	logged in with Facebook Connect and is then authenticating their call		logged in with Facebook Connect and is then authenticating their call
	with a Facebook identity. However, in other case, the user may not		with a Facebook identity. However, in other case, the user may not
	have already revealed their identity to the site. In general, IdPs		have already revealed their identity to the site. In general, IdPs
	SHOULD either verify that the user is willing to have their identity		SHOULD either verify that the user is willing to have their identity
	revealed to the site (e.g., through the usual IdP permissions dialog)		revealed to the site (e.g., through the usual IdP permissions dialog)
	or arrange that the identity information is only available to known		or arrange that the identity information is only available to known
	RPs (e.g., social graph adjacencies) but not to the calling site.		RPs (e.g., social graph adjacencies) but not to the calling site.
	The "origin" field of the signature request can be used to check that		The "domain" field of the assertion request can be used to check that
	the user has agreed to disclose their identity to the calling site;		the user has agreed to disclose their identity to the calling site;
	because it is supplied by the PeerConnection it can be trusted to be		because it is supplied by the PeerConnection it can be trusted to be
	correct.		correct.
	9.4.4. Security of Third-Party IdPs		9.4.4. Security of Third-Party IdPs
	As discussed above, each third-party IdP represents a new universal		As discussed above, each third-party IdP represents a new universal
	trust point and therefore the number of these IdPs needs to be quite		trust point and therefore the number of these IdPs needs to be quite
	limited. Most IdPs, even those which issue unqualified identities		limited. Most IdPs, even those which issue unqualified identities
	such as Facebook, can be recast as authoritative IdPs (e.g.,		such as Facebook, can be recast as authoritative IdPs (e.g.,
	skipping to change at page 36, line 7 ¶		skipping to change at page 36, line 7 ¶
	mixed script usage (see [RFC5890], section 4.4). Other best		mixed script usage (see [RFC5890], section 4.4). Other best
	practices are still in development.		practices are still in development.
	9.4.5. Web Security Feature Interactions		9.4.5. Web Security Feature Interactions
	A number of optional Web security features have the potential to		A number of optional Web security features have the potential to
	cause issues for this mechanism, as discussed below.		cause issues for this mechanism, as discussed below.
	9.4.5.1. Popup Blocking		9.4.5.1. Popup Blocking
	The IdP proxy is unable to generate popup windows, dialogs or any		When popup blocking is in use, the IdP proxy is unable to generate
	other form of user interactions. This prevents the IdP proxy from		popup windows, dialogs or any other form of user interactions. This
	being used to circumvent user interaction. The "LOGINNEEDED" message		prevents the IdP proxy from being used to circumvent user
	allows the IdP proxy to inform the calling site of a need for user		interaction. The "LOGINNEEDED" message allows the IdP proxy to
	login, providing the information necessary to satisfy this		inform the calling site of a need for user login, providing the
	requirement without resorting to direct user interaction from the IdP		information necessary to satisfy this requirement without resorting
	proxy itself.		to direct user interaction from the IdP proxy itself.
	9.4.5.2. Third Party Cookies		9.4.5.2. Third Party Cookies
	Some browsers allow users to block third party cookies (cookies		Some browsers allow users to block third party cookies (cookies
	associated with origins other than the top level page) for privacy		associated with origins other than the top level page) for privacy
	reasons. Any IdP which uses cookies to persist logins will be broken		reasons. Any IdP which uses cookies to persist logins will be broken
	by third-party cookie blocking. One option is to accept this as a		by third-party cookie blocking. One option is to accept this as a
	limitation; another is to have the PeerConnection object disable		limitation; another is to have the PeerConnection object disable
	third-party cookie blocking for the IdP proxy.		third-party cookie blocking for the IdP proxy.
	10. IANA Considerations		10. IANA Considerations
	This specification defines the "identity" SDP attribute per the		This specification defines the "identity" SDP attribute per the
	procedures of Section 8.2.4 of [RFC4566]. The required information		procedures of Section 8.2.4 of [RFC4566]. The required information
	for the registration is included here:		for the registration is included here:
	Contact Name: Eric Rescorla (ekr@rftm.com)		Contact Name: IESG (iesg@ietf.org)
	Attribute Name: identity		Attribute Name: identity
	Long Form: identity		Long Form: identity
	Type of Attribute: session-level		Type of Attribute: session-level
	Charset Considerations: This attribute is not subject to the charset		Charset Considerations: This attribute is not subject to the charset
	attribute.		attribute.
	Purpose: This attribute carries an identity assertion, binding an		Purpose: This attribute carries an identity assertion, binding an
	identity to the transport-level security session.		identity to the transport-level security session.
	Appropriate Values: See Section 5 of RFCXXXX [[Editor Note: This		Appropriate Values: See Section 5 of RFCXXXX [[Editor Note: This
	document.]]		document.]]
	Mux Category: NORMAL.		Mux Category: NORMAL.
			This section reqisters the "idp-proxy" well-known URI from [RFC5785].
			URI suffix: idp-proxy
			Change controller: IETF
	11. Acknowledgements		11. Acknowledgements
	Bernard Aboba, Harald Alvestrand, Richard Barnes, Dan Druta, Cullen		Bernard Aboba, Harald Alvestrand, Richard Barnes, Dan Druta, Cullen
	Jennings, Hadriel Kaplan, Matthew Kaufman, Jim McEachern, Martin		Jennings, Hadriel Kaplan, Matthew Kaufman, Jim McEachern, Martin
	Thomson, Magnus Westerland. Matthew Kaufman provided the UI material		Thomson, Magnus Westerland. Matthew Kaufman provided the UI material
	in Section 6.5. Christer Holmberg provided the initial version of		in Section 6.5. Christer Holmberg provided the initial version of
	Section 5.1.		Section 5.1.
	12. Changes		12. Changes
	skipping to change at page 39, line 16 ¶		skipping to change at page 39, line 18 ¶
	13.1. Normative References		13.1. Normative References
	[FIPS186] National Institute of Standards and Technology (NIST),		[FIPS186] National Institute of Standards and Technology (NIST),
	"Digital Signature Standard (DSS)", NIST PUB 186-4 , July		"Digital Signature Standard (DSS)", NIST PUB 186-4 , July
	2013.		2013.
	[I-D.ietf-mmusic-sdp-uks]		[I-D.ietf-mmusic-sdp-uks]
	Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on		Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on
	uses of TLS with the Session Description Protocol (SDP)",		uses of TLS with the Session Description Protocol (SDP)",
	draft-ietf-mmusic-sdp-uks-03 (work in progress), January		draft-ietf-mmusic-sdp-uks-05 (work in progress), June
	2019.		2019.
			[I-D.ietf-rtcweb-jsep]
			Uberti, J., Jennings, C., and E. Rescorla, "JavaScript
			Session Establishment Protocol", draft-ietf-rtcweb-jsep-26
			(work in progress), February 2019.
			[I-D.ietf-rtcweb-overview]
			Alvestrand, H., "Overview: Real Time Protocols for
			Browser-based Applications", draft-ietf-rtcweb-overview-19
			(work in progress), November 2017.
	[I-D.ietf-rtcweb-rtp-usage]		[I-D.ietf-rtcweb-rtp-usage]
	Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time		Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
	Communication (WebRTC): Media Transport and Use of RTP",		Communication (WebRTC): Media Transport and Use of RTP",
	draft-ietf-rtcweb-rtp-usage-26 (work in progress), March		draft-ietf-rtcweb-rtp-usage-26 (work in progress), March
	2016.		2016.
	[I-D.ietf-rtcweb-security]		[I-D.ietf-rtcweb-security]
	Rescorla, E., "Security Considerations for WebRTC", draft-		Rescorla, E., "Security Considerations for WebRTC", draft-
	ietf-rtcweb-security-10 (work in progress), January 2018.		ietf-rtcweb-security-12 (work in progress), July 2019.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000,		DOI 10.17487/RFC2818, May 2000,
	<https://www.rfc-editor.org/info/rfc2818>.		<https://www.rfc-editor.org/info/rfc2818>.
	skipping to change at page 40, line 14 ¶		skipping to change at page 40, line 28 ¶
	[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session		[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
	Description Protocol (SDP) Security Descriptions for Media		Description Protocol (SDP) Security Descriptions for Media
	Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,		Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
	<https://www.rfc-editor.org/info/rfc4568>.		<https://www.rfc-editor.org/info/rfc4568>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/info/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<https://www.rfc-editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.
	[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework		[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
	for Establishing a Secure Real-time Transport Protocol		for Establishing a Secure Real-time Transport Protocol
	(SRTP) Security Context Using Datagram Transport Layer		(SRTP) Security Context Using Datagram Transport Layer
	Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May		Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
	2010, <https://www.rfc-editor.org/info/rfc5763>.		2010, <https://www.rfc-editor.org/info/rfc5763>.
	skipping to change at page 41, line 47 ¶		skipping to change at page 42, line 12 ¶
	SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November		SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
	2017, <https://www.rfc-editor.org/info/rfc8261>.		2017, <https://www.rfc-editor.org/info/rfc8261>.
	[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive		[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
	Connectivity Establishment (ICE): A Protocol for Network		Connectivity Establishment (ICE): A Protocol for Network
	Address Translator (NAT) Traversal", RFC 8445,		Address Translator (NAT) Traversal", RFC 8445,
	DOI 10.17487/RFC8445, July 2018,		DOI 10.17487/RFC8445, July 2018,
	<https://www.rfc-editor.org/info/rfc8445>.		<https://www.rfc-editor.org/info/rfc8445>.
	[webcrypto]		[webcrypto]
	Dahl, Sleevi, "Web Cryptography API", June 2013.		editors, W., "Web Cryptography API", June 2013.
	Available at http://www.w3.org/TR/WebCryptoAPI/		Available at http://www.w3.org/TR/WebCryptoAPI/
	[webrtc-api]		[webrtc-api]
	Bergkvist, Burnett, Jennings, Narayanan, "WebRTC 1.0:		editors, W., "WebRTC 1.0: Real-time Communication Between
	Real-time Communication Between Browsers", October 2011.		Browsers", October 2011.
	Available at http://dev.w3.org/2011/webrtc/editor/		Available at http://dev.w3.org/2011/webrtc/editor/
	webrtc.html		webrtc.html
	13.2. Informative References		13.2. Informative References
	[I-D.ietf-rtcweb-jsep]
	Uberti, J., Jennings, C., and E. Rescorla, "JavaScript
	Session Establishment Protocol", draft-ietf-rtcweb-jsep-25
	(work in progress), October 2018.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002,
	<https://www.rfc-editor.org/info/rfc3261>.		<https://www.rfc-editor.org/info/rfc3261>.
	[RFC5705] Rescorla, E., "Keying Material Exporters for Transport		[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
	Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,		Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
	March 2010, <https://www.rfc-editor.org/info/rfc5705>.		March 2010, <https://www.rfc-editor.org/info/rfc5705>.
			[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
			Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
			March 2011, <https://www.rfc-editor.org/info/rfc6120>.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,		DOI 10.17487/RFC6265, April 2011,
	<https://www.rfc-editor.org/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
	[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",		[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
	RFC 6455, DOI 10.17487/RFC6455, December 2011,		RFC 6455, DOI 10.17487/RFC6455, December 2011,
	<https://www.rfc-editor.org/info/rfc6455>.		<https://www.rfc-editor.org/info/rfc6455>.
	[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for		[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for
	Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May		Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May
End of changes. 60 change blocks.
	165 lines changed or deleted		179 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/