< draft-ietf-oauth-dpop-05.txt		draft-ietf-oauth-dpop-06.txt >
	Web Authorization Protocol D. Fett		Web Authorization Protocol D. Fett
	Internet-Draft yes.com		Internet-Draft yes.com
	Intended status: Standards Track B. Campbell		Intended status: Standards Track B. Campbell
	Expires: 23 August 2022 Ping Identity		Expires: 2 September 2022 Ping Identity
	J. Bradley		J. Bradley
	Yubico		Yubico
	T. Lodderstedt		T. Lodderstedt
	yes.com		yes.com
	M. Jones		M. Jones
	Microsoft		Microsoft
	D. Waite		D. Waite
	Ping Identity		Ping Identity
	19 February 2022		1 March 2022
	OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer		OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer
	(DPoP)		(DPoP)
	draft-ietf-oauth-dpop-05		draft-ietf-oauth-dpop-06
	Abstract		Abstract
	This document describes a mechanism for sender-constraining OAuth 2.0		This document describes a mechanism for sender-constraining OAuth 2.0
	tokens via a proof-of-possession mechanism on the application level.		tokens via a proof-of-possession mechanism on the application level.
	This mechanism allows for the detection of replay attacks with access		This mechanism allows for the detection of replay attacks with access
	and refresh tokens.		and refresh tokens.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 23 August 2022.		This Internet-Draft will expire on 2 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	6.1. JWK Thumbprint Confirmation Method . . . . . . . . . . . 15		6.1. JWK Thumbprint Confirmation Method . . . . . . . . . . . 15
	6.2. JWK Thumbprint Confirmation Method in Token		6.2. JWK Thumbprint Confirmation Method in Token
	Introspection . . . . . . . . . . . . . . . . . . . . . . 15		Introspection . . . . . . . . . . . . . . . . . . . . . . 15
	7. Protected Resource Access . . . . . . . . . . . . . . . . . . 17		7. Protected Resource Access . . . . . . . . . . . . . . . . . . 17
	7.1. The DPoP Authentication Scheme . . . . . . . . . . . . . 17		7.1. The DPoP Authentication Scheme . . . . . . . . . . . . . 17
	7.2. Compatibility with the Bearer Authentication Scheme . . . 20		7.2. Compatibility with the Bearer Authentication Scheme . . . 20
	8. Authorization Server-Provided Nonce . . . . . . . . . . . . . 20		8. Authorization Server-Provided Nonce . . . . . . . . . . . . . 20
	8.1. Providing a New Nonce Value . . . . . . . . . . . . . . . 22		8.1. Providing a New Nonce Value . . . . . . . . . . . . . . . 22
	9. Resource Server-Provided Nonce . . . . . . . . . . . . . . . 23		9. Resource Server-Provided Nonce . . . . . . . . . . . . . . . 23
	10. Authorization Code Binding to DPoP Key . . . . . . . . . . . 23		10. Authorization Code Binding to DPoP Key . . . . . . . . . . . 23
	11. DPoP with Pushed Authorization Requests . . . . . . . . . . . 24		10.1. DPoP with Pushed Authorization Requests . . . . . . . . 24
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 25		11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	12.1. DPoP Proof Replay . . . . . . . . . . . . . . . . . . . 25		11.1. DPoP Proof Replay . . . . . . . . . . . . . . . . . . . 25
	12.2. DPoP Proof Pre-Generation . . . . . . . . . . . . . . . 26		11.2. DPoP Proof Pre-Generation . . . . . . . . . . . . . . . 26
	12.3. DPoP Nonce Downgrade . . . . . . . . . . . . . . . . . . 26		11.3. DPoP Nonce Downgrade . . . . . . . . . . . . . . . . . . 26
	12.4. Untrusted Code in the Client Context . . . . . . . . . . 26		11.4. Untrusted Code in the Client Context . . . . . . . . . . 26
	12.5. Signed JWT Swapping . . . . . . . . . . . . . . . . . . 27		11.5. Signed JWT Swapping . . . . . . . . . . . . . . . . . . 27
	12.6. Signature Algorithms . . . . . . . . . . . . . . . . . . 27		11.6. Signature Algorithms . . . . . . . . . . . . . . . . . . 27
	12.7. Message Integrity . . . . . . . . . . . . . . . . . . . 27		11.7. Message Integrity . . . . . . . . . . . . . . . . . . . 27
	12.8. Access Token and Public Key Binding . . . . . . . . . . 28		11.8. Access Token and Public Key Binding . . . . . . . . . . 28
	12.9. Authorization Code and Public Key Binding . . . . . . . 29		11.9. Authorization Code and Public Key Binding . . . . . . . 29
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	13.1. OAuth Access Token Type Registration . . . . . . . . . . 29		12.1. OAuth Access Token Type Registration . . . . . . . . . . 29
	13.2. OAuth Extensions Error Registration . . . . . . . . . . 30		12.2. OAuth Extensions Error Registration . . . . . . . . . . 30
	13.3. OAuth Parameters Registration . . . . . . . . . . . . . 30		12.3. OAuth Parameters Registration . . . . . . . . . . . . . 30
	13.4. HTTP Authentication Scheme Registration . . . . . . . . 31		12.4. HTTP Authentication Scheme Registration . . . . . . . . 31
	13.5. Media Type Registration . . . . . . . . . . . . . . . . 31		12.5. Media Type Registration . . . . . . . . . . . . . . . . 31
	13.6. JWT Confirmation Methods Registration . . . . . . . . . 31		12.6. JWT Confirmation Methods Registration . . . . . . . . . 31
	13.7. JSON Web Token Claims Registration . . . . . . . . . . . 31		12.7. JSON Web Token Claims Registration . . . . . . . . . . . 31
	13.8. HTTP Message Header Field Names Registration . . . . . . 32		12.8. HTTP Message Header Field Names Registration . . . . . . 32
	13.9. OAuth Authorization Server Metadata Registration . . . . 33		12.9. OAuth Authorization Server Metadata Registration . . . . 33
	13.10. OAuth Dynamic Client Registration Metadata . . . . . . . 33		12.10. OAuth Dynamic Client Registration Metadata . . . . . . . 33
	14. Normative References . . . . . . . . . . . . . . . . . . . . 33		13. Normative References . . . . . . . . . . . . . . . . . . . . 33
	15. Informative References . . . . . . . . . . . . . . . . . . . 34		14. Informative References . . . . . . . . . . . . . . . . . . . 34
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 37		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 37
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 38		Appendix B. Document History . . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
	1. Introduction		1. Introduction
	DPoP (for Demonstrating Proof-of-Possession at the Application Layer)		DPoP (for Demonstrating Proof-of-Possession at the Application Layer)
	is an application-level mechanism for sender-constraining OAuth		is an application-level mechanism for sender-constraining OAuth
	access and refresh tokens. It enables a client to prove the		access and refresh tokens. It enables a client to prove the
	possession of a public/private key pair by including a DPoP header in		possession of a public/private key pair by including a DPoP header in
	skipping to change at page 5, line 41 ¶		skipping to change at page 5, line 41 ¶
	independent of the client application to access protected resources.		independent of the client application to access protected resources.
	To prevent this, servers can optionally require clients to include a		To prevent this, servers can optionally require clients to include a
	server-chosen value into the proof that cannot be predicted by an		server-chosen value into the proof that cannot be predicted by an
	attacker (nonce). In the absence of the optional nonce, the impact		attacker (nonce). In the absence of the optional nonce, the impact
	of pre-computed DPoP proofs is limited somewhat by the proof being		of pre-computed DPoP proofs is limited somewhat by the proof being
	bound to an access token on protected resource access. Because a		bound to an access token on protected resource access. Because a
	proof covering an access token that does not yet exist cannot		proof covering an access token that does not yet exist cannot
	feasibly be created, access tokens obtained with an exfiltrated		feasibly be created, access tokens obtained with an exfiltrated
	refresh token and pre-computed proofs will be unusable.		refresh token and pre-computed proofs will be unusable.
	Additional security considerations are discussed in Section 12.		Additional security considerations are discussed in Section 11.
	3. Concept		3. Concept
	The main data structure introduced by this specification is a DPoP		The main data structure introduced by this specification is a DPoP
	proof JWT, described in detail below, which is sent as a header in an		proof JWT, described in detail below, which is sent as a header in an
	HTTP request. A client uses a DPoP proof JWT to prove the possession		HTTP request. A client uses a DPoP proof JWT to prove the possession
	of a private key corresponding to a certain public key.		of a private key corresponding to a certain public key.
	Roughly speaking, a DPoP proof is a signature over some data of the		Roughly speaking, a DPoP proof is a signature over some data of the
	HTTP request to which it is attached, a timestamp, a unique		HTTP request to which it is attached, a timestamp, a unique
	skipping to change at page 7, line 22 ¶		skipping to change at page 7, line 22 ¶
	in all other respects.		in all other respects.
	The DPoP mechanism presented herein is not a client authentication		The DPoP mechanism presented herein is not a client authentication
	method. In fact, a primary use case of DPoP is for public clients		method. In fact, a primary use case of DPoP is for public clients
	(e.g., single page applications and native applications) that do not		(e.g., single page applications and native applications) that do not
	use client authentication. Nonetheless, DPoP is designed such that		use client authentication. Nonetheless, DPoP is designed such that
	it is compatible with private_key_jwt and all other client		it is compatible with private_key_jwt and all other client
	authentication methods.		authentication methods.
	DPoP does not directly ensure message integrity but relies on the TLS		DPoP does not directly ensure message integrity but relies on the TLS
	layer for that purpose. See Section 12 for details.		layer for that purpose. See Section 11 for details.
	4. DPoP Proof JWTs		4. DPoP Proof JWTs
	DPoP introduces the concept of a DPoP proof, which is a JWT created		DPoP introduces the concept of a DPoP proof, which is a JWT created
	by the client and sent with an HTTP request using the DPoP header		by the client and sent with an HTTP request using the DPoP header
	field. Each HTTP request requires a unique DPoP proof.		field. Each HTTP request requires a unique DPoP proof.
	A valid DPoP proof demonstrates to the server that the client holds		A valid DPoP proof demonstrates to the server that the client holds
	the private key that was used to sign the DPoP proof JWT. This		the private key that was used to sign the DPoP proof JWT. This
	enables authorization servers to bind issued tokens to the		enables authorization servers to bind issued tokens to the
	skipping to change at page 8, line 48 ¶		skipping to change at page 8, line 48 ¶
	The payload of a DPoP proof contains at least the following claims:		The payload of a DPoP proof contains at least the following claims:
	* jti: Unique identifier for the DPoP proof JWT (REQUIRED). The		* jti: Unique identifier for the DPoP proof JWT (REQUIRED). The
	value MUST be assigned such that there is a negligible probability		value MUST be assigned such that there is a negligible probability
	that the same value will be assigned to any other DPoP proof used		that the same value will be assigned to any other DPoP proof used
	in the same context during the time window of validity. Such		in the same context during the time window of validity. Such
	uniqueness can be accomplished by encoding (base64url or any other		uniqueness can be accomplished by encoding (base64url or any other
	suitable encoding) at least 96 bits of pseudorandom data or by		suitable encoding) at least 96 bits of pseudorandom data or by
	using a version 4 UUID string according to [RFC4122]. The jti can		using a version 4 UUID string according to [RFC4122]. The jti can
	be used by the server for replay detection and prevention, see		be used by the server for replay detection and prevention, see
	Section 12.1.		Section 11.1.
	* htm: The HTTP method for the request to which the JWT is attached,		* htm: The HTTP method for the request to which the JWT is attached,
	as defined in [RFC7231] (REQUIRED).		as defined in [RFC7231] (REQUIRED).
	* htu: The HTTP URI used for the request, without query and fragment		* htu: The HTTP URI used for the request, without query and fragment
	parts (REQUIRED).		parts (REQUIRED).
	* iat: Time at which the JWT was created (REQUIRED).		* iat: Time at which the JWT was created (REQUIRED).
	When the DPoP proof is used in conjunction with the presentation of		When the DPoP proof is used in conjunction with the presentation of
	skipping to change at page 10, line 13 ¶		skipping to change at page 10, line 13 ¶
	Figure 3: Example JWT content of a DPoP proof		Figure 3: Example JWT content of a DPoP proof
	Of the HTTP content in the request, only the HTTP method and URI are		Of the HTTP content in the request, only the HTTP method and URI are
	included in the DPoP JWT, and therefore only these 2 headers of the		included in the DPoP JWT, and therefore only these 2 headers of the
	request are covered by the DPoP proof and its signature. The idea is		request are covered by the DPoP proof and its signature. The idea is
	sign just enough of the HTTP data to provide reasonable proof-of-		sign just enough of the HTTP data to provide reasonable proof-of-
	possession with respect to the HTTP request. But that it be a		possession with respect to the HTTP request. But that it be a
	minimal subset of the HTTP data so as to avoid the substantial		minimal subset of the HTTP data so as to avoid the substantial
	difficulties inherent in attempting to normalize HTTP messages.		difficulties inherent in attempting to normalize HTTP messages.
	Nonetheless, DPoP proofs can be extended to contain other information		Nonetheless, DPoP proofs can be extended to contain other information
	of the HTTP request (see also Section 12.7).		of the HTTP request (see also Section 11.7).
	4.3. Checking DPoP Proofs		4.3. Checking DPoP Proofs
	To check if a string that was received as part of an HTTP Request is		To check if a string that was received as part of an HTTP Request is
	a valid DPoP proof, the receiving server MUST ensure that		a valid DPoP proof, the receiving server MUST ensure that
	1. that there is not more than one DPoP header in the request,		1. that there is not more than one DPoP header in the request,
	2. the string value of the header field is a well-formed JWT,		2. the string value of the header field is a well-formed JWT,
	skipping to change at page 10, line 49 ¶		skipping to change at page 10, line 49 ¶
	in which the JWT was received, ignoring any query and fragment		in which the JWT was received, ignoring any query and fragment
	parts,		parts,
	9. if the server provided a nonce value to the client, the nonce		9. if the server provided a nonce value to the client, the nonce
	claim matches the server-provided nonce value,		claim matches the server-provided nonce value,
	10. the token was issued within an acceptable timeframe and, within		10. the token was issued within an acceptable timeframe and, within
	a reasonable consideration of accuracy and resource utilization,		a reasonable consideration of accuracy and resource utilization,
	a proof JWT with the same jti value has not previously been		a proof JWT with the same jti value has not previously been
	received at the same resource during that time period (see		received at the same resource during that time period (see
	Section 12.1),		Section 11.1),
	11. when presented to a protected resource in conjunction with an		11. when presented to a protected resource in conjunction with an
	access token, ensure that the value of the ath claim equals the		access token, ensure that the value of the ath claim equals the
	hash of that access token and confirm that the public key to		hash of that access token and confirm that the public key to
	which the access token is bound matches the public key from the		which the access token is bound matches the public key from the
	DPoP proof.		DPoP proof.
	Servers SHOULD employ Syntax-Based Normalization and Scheme-Based		Servers SHOULD employ Syntax-Based Normalization and Scheme-Based
	Normalization in accordance with Section 6.2.2. and Section 6.2.3. of		Normalization in accordance with Section 6.2.2. and Section 6.2.3. of
	[RFC3986] before comparing the htu claim.		[RFC3986] before comparing the htu claim.
	skipping to change at page 14, line 24 ¶		skipping to change at page 14, line 24 ¶
	extensions to it, also imply a general data model for clients that is		extensions to it, also imply a general data model for clients that is
	useful for authorization server implementations even when the Dynamic		useful for authorization server implementations even when the Dynamic
	Client Registration Protocol isn't in play. Such implementations		Client Registration Protocol isn't in play. Such implementations
	will typically have some sort of user interface available for		will typically have some sort of user interface available for
	managing client configuration.		managing client configuration.
	This document introduces the following client registration metadata		This document introduces the following client registration metadata
	[RFC7591] parameter to indicate that the client always uses DPoP when		[RFC7591] parameter to indicate that the client always uses DPoP when
	requesting tokens from the authorization server.		requesting tokens from the authorization server.
	always_uses_dpop Boolean value specifying whether the client always		dpop_bound_access_tokens Boolean value specifying whether the client
	uses DPoP for token requests. If omitted, the default value is		always uses DPoP for token requests. If omitted, the default
	false.		value is false.
	If true, the authorization server MUST reject token requests from		If true, the authorization server MUST reject token requests from
	this client that do not contain the DPoP header.		this client that do not contain the DPoP header.
	6. Public Key Confirmation		6. Public Key Confirmation
	Resource servers MUST be able to reliably identify whether an access		Resource servers MUST be able to reliably identify whether an access
	token is bound using DPoP and ascertain sufficient information about		token is bound using DPoP and ascertain sufficient information about
	the public key to which the token is bound in order to verify the		the public key to which the token is bound in order to verify the
	binding with respect to the presented DPoP proof (see Section 7.1).		binding with respect to the presented DPoP proof (see Section 7.1).
	skipping to change at page 18, line 40 ¶		skipping to change at page 18, line 40 ¶
	{		{
	"jti":"e1j3V_bKic8-LAEB",		"jti":"e1j3V_bKic8-LAEB",
	"htm":"GET",		"htm":"GET",
	"htu":"https://resource.example.org/protectedresource",		"htu":"https://resource.example.org/protectedresource",
	"iat":1562262618,		"iat":1562262618,
	"ath":"fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQEo"		"ath":"fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQEo"
	}		}
	Figure 13: Decoded Content of the DPoP Proof JWT in Figure 12		Figure 13: Decoded Content of the DPoP Proof JWT in Figure 12
	Upon receipt of a request for a URI of a protected resource within		Upon receipt of a request to a protected resource within the
	the protection space requiring DPoP authentication, if the request		protection space requiring DPoP authentication, if the request does
	does not include valid credentials or does not contain an access		not include valid credentials or does not contain an access token
	token sufficient for access to the protected resource, the server can		sufficient for access, the server can respond with a challenge to the
	reply with a challenge using the 401 (Unauthorized) status code		client to provide DPoP authentication information. Such a challenge
	([RFC7235], Section 3.1) and the WWW-Authenticate header field		is made using the 401 (Unauthorized) response status code ([RFC7235],
	([RFC7235], Section 4.1). The server MAY include the WWW-		Section 3.1) and the WWW-Authenticate header field ([RFC7235],
	Authenticate header in response to other conditions as well.		Section 4.1). The server MAY include the WWW-Authenticate header in
			response to other conditions as well.
	In such challenges:		In such challenges:
	* The scheme name is DPoP.		* The scheme name is DPoP.
	* The authentication parameter realm MAY be included to indicate the		* The authentication parameter realm MAY be included to indicate the
	scope of protection in the manner described in [RFC7235],		scope of protection in the manner described in [RFC7235],
	Section 2.2.		Section 2.2.
	* A scope authentication parameter MAY be included as defined in		* A scope authentication parameter MAY be included as defined in
	skipping to change at page 20, line 14 ¶		skipping to change at page 20, line 14 ¶
	Figure 15: HTTP 401 Response to a Protected Resource Request with		Figure 15: HTTP 401 Response to a Protected Resource Request with
	an Invalid Token		an Invalid Token
	7.2. Compatibility with the Bearer Authentication Scheme		7.2. Compatibility with the Bearer Authentication Scheme
	Protected resources simultaneously supporting both the DPoP and		Protected resources simultaneously supporting both the DPoP and
	Bearer schemes need to update how evaluation of bearer tokens is		Bearer schemes need to update how evaluation of bearer tokens is
	performed to prevent downgraded usage of a DPoP-bound access tokens.		performed to prevent downgraded usage of a DPoP-bound access tokens.
	Specifically, such a protected resource MUST reject an access token		Specifically, such a protected resource MUST reject an access token
	received as a bearer token per [!@RFC6750], if that token is		received as a bearer token per [RFC6750], if that token is determined
	determined to be DPoP-bound.		to be DPoP-bound.
	Section 4.1 of [RFC7235] allows a protected resource to indicate		Section 4.1 of [RFC7235] allows a protected resource to indicate
	support for multiple authentication schemes (i.e., Bearer and DPoP)		support for multiple authentication schemes (i.e., Bearer and DPoP)
	with the WWW-Authenticate header field of a 401 (Unauthorized)		with the WWW-Authenticate header field of a 401 (Unauthorized)
	response.		response.
	A protected resource that supports only [RFC6750] and is unaware of		A protected resource that supports only [RFC6750] and is unaware of
	DPoP would most presumably accept a DPoP-bound access token as a		DPoP would most presumably accept a DPoP-bound access token as a
	bearer token (JWT [RFC7519] says to ignore unrecognized claims,		bearer token (JWT [RFC7519] says to ignore unrecognized claims,
	Introspection [RFC7662] says that other parameters might be present		Introspection [RFC7662] says that other parameters might be present
	skipping to change at page 23, line 28 ¶		skipping to change at page 23, line 28 ¶
	with a DPoP-Nonce value such as the following to provide a nonce		with a DPoP-Nonce value such as the following to provide a nonce
	value to include in the DPoP proof:		value to include in the DPoP proof:
	HTTP/1.1 401 Unauthorized		HTTP/1.1 401 Unauthorized
	WWW-Authenticate: DPoP error="use_dpop_nonce",		WWW-Authenticate: DPoP error="use_dpop_nonce",
	error_description="Resource server requires nonce in DPoP proof"		error_description="Resource server requires nonce in DPoP proof"
	DPoP-Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v		DPoP-Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v
	Figure 20: HTTP 401 Response to a Resource Request without a Nonce		Figure 20: HTTP 401 Response to a Resource Request without a Nonce
	Note that the nonces provided by the two kinds of servers are		Note that the nonces provided by an authorization server and a
	different and MUST not be confused with one another. In particular,		resource server are different and should not be confused with one
	a nonce provided to the client by a particular server MUST only be		another, since nonces will be only accepted by the server that issued
	used with that server and no other. Developers should also take care		them. Likewise, should a client use multiple authorization servers
	to not confuse this nonce with the OpenID Connect [OpenID.Core] ID		and/or resource servers, a nonce issued by any of them should be used
	Token nonce, should one also be present.		only at the issuing server. Developers should also take care to not
			confuse DPoP nonces with the OpenID Connect [OpenID.Core] ID Token
			nonce.
	10. Authorization Code Binding to DPoP Key		10. Authorization Code Binding to DPoP Key
	Binding the authorization code issued to the client's proof-of-		Binding the authorization code issued to the client's proof-of-
	possession key can enable end-to-end binding of the entire		possession key can enable end-to-end binding of the entire
	authorization flow. This specification defines the dpop_jkt		authorization flow. This specification defines the dpop_jkt
	authorization request parameter for this purpose. The value of the		authorization request parameter for this purpose. The value of the
	dpop_jkt authorization request parameter is the JSON Web Key (JWK)		dpop_jkt authorization request parameter is the JSON Web Key (JWK)
	Thumbprint [RFC7638] of the proof-of-possession public key using the		Thumbprint [RFC7638] of the proof-of-possession public key using the
	SHA-256 hash function - the same value as used for the jkt		SHA-256 hash function - the same value as used for the jkt
	skipping to change at page 24, line 21 ¶		skipping to change at page 24, line 27 ¶
	&code_challenge_method=S256		&code_challenge_method=S256
	&dpop_jkt=NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs HTTP/1.1		&dpop_jkt=NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Figure 21: Authorization Request using the dpop_jkt Parameter		Figure 21: Authorization Request using the dpop_jkt Parameter
	Use of the dpop_jkt authorization request parameter is OPTIONAL.		Use of the dpop_jkt authorization request parameter is OPTIONAL.
	Note that the dpop_jkt authorization request parameter MAY also be		Note that the dpop_jkt authorization request parameter MAY also be
	used in combination with PKCE [RFC7636].		used in combination with PKCE [RFC7636].
	11. DPoP with Pushed Authorization Requests		10.1. DPoP with Pushed Authorization Requests
	When Pushed Authorization Requests (PAR, [RFC9126]) are used in		When Pushed Authorization Requests (PAR, [RFC9126]) are used in
	conjunction with DPoP, there are two ways in which the DPoP key can		conjunction with DPoP, there are two ways in which the DPoP key can
	be communicated in the PAR request:		be communicated in the PAR request:
	* The dpop_jkt parameter can be used as described above to bind the		* The dpop_jkt parameter can be used as described above to bind the
	issued authorization code to a specific key. In this case,		issued authorization code to a specific key. In this case,
	dpop_jkt MUST be included alongside other authorization request		dpop_jkt MUST be included alongside other authorization request
	parameters in the POST body of the PAR request.		parameters in the POST body of the PAR request.
	skipping to change at page 25, line 5 ¶		skipping to change at page 25, line 11 ¶
	the type of request. Additionally, it provides a stronger		the type of request. Additionally, it provides a stronger
	binding, as the DPoP header contains a proof of possession of the		binding, as the DPoP header contains a proof of possession of the
	private key.		private key.
	Both mechanisms MUST be supported by an authorization server that		Both mechanisms MUST be supported by an authorization server that
	supports PAR and DPoP. If both mechanisms are used at the same time,		supports PAR and DPoP. If both mechanisms are used at the same time,
	the authorization server MUST reject the request if the JWK		the authorization server MUST reject the request if the JWK
	Thumbprint in dpop_jkt does not match the public key in the DPoP		Thumbprint in dpop_jkt does not match the public key in the DPoP
	header.		header.
	12. Security Considerations		11. Security Considerations
	In DPoP, the prevention of token replay at a different endpoint (see		In DPoP, the prevention of token replay at a different endpoint (see
	Section 2) is achieved through the binding of the DPoP proof to a		Section 2) is achieved through the binding of the DPoP proof to a
	certain URI and HTTP method plus the optional server-provided nonce.		certain URI and HTTP method plus the optional server-provided nonce.
	DPoP, however, has a somewhat different nature of protection than		DPoP, however, has a somewhat different nature of protection than
	TLS-based methods such as OAuth Mutual TLS [RFC8705] or OAuth Token		TLS-based methods such as OAuth Mutual TLS [RFC8705] or OAuth Token
	Binding [I-D.ietf-oauth-token-binding] (see also Section 12.1 and		Binding [I-D.ietf-oauth-token-binding] (see also Section 11.1 and
	Section 12.7). TLS-based mechanisms can leverage a tight integration		Section 11.7). TLS-based mechanisms can leverage a tight integration
	between the TLS layer and the application layer to achieve a very		between the TLS layer and the application layer to achieve a very
	high level of message integrity with respect to the transport layer		high level of message integrity with respect to the transport layer
	to which the token is bound and replay protection in general.		to which the token is bound and replay protection in general.
	12.1. DPoP Proof Replay		11.1. DPoP Proof Replay
	If an adversary is able to get hold of a DPoP proof JWT, the		If an adversary is able to get hold of a DPoP proof JWT, the
	adversary could replay that token at the same endpoint (the HTTP		adversary could replay that token at the same endpoint (the HTTP
	endpoint and method are enforced via the respective claims in the		endpoint and method are enforced via the respective claims in the
	JWTs). To prevent this, servers MUST only accept DPoP proofs for a		JWTs). To prevent this, servers MUST only accept DPoP proofs for a
	limited time window after their iat time, preferably only for a		limited time window after their iat time, preferably only for a
	relatively brief period.		relatively brief period.
	Servers SHOULD store, in the context of the request URI, the jti		Servers SHOULD store, in the context of the request URI, the jti
	value of each DPoP proof for the time window in which the respective		value of each DPoP proof for the time window in which the respective
	skipping to change at page 26, line 5 ¶		skipping to change at page 26, line 5 ¶
	proofs that carry an iat time in the reasonably near future. Because		proofs that carry an iat time in the reasonably near future. Because
	clock skews between servers and clients may be large, servers may		clock skews between servers and clients may be large, servers may
	choose to limit DPoP proof lifetimes by using server-provided nonce		choose to limit DPoP proof lifetimes by using server-provided nonce
	values containing the time at the server rather than comparing the		values containing the time at the server rather than comparing the
	client-supplied iat time to the time at the server, yielding intended		client-supplied iat time to the time at the server, yielding intended
	results even in the face of arbitrarily large clock skews.		results even in the face of arbitrarily large clock skews.
	Server-provided nonces are an effective means of preventing DPoP		Server-provided nonces are an effective means of preventing DPoP
	proof replay.		proof replay.
	12.2. DPoP Proof Pre-Generation		11.2. DPoP Proof Pre-Generation
	An attacker in control of the client can pre-generate DPoP proofs for		An attacker in control of the client can pre-generate DPoP proofs for
	use arbitrarily far into the future by choosing the iat value in the		use arbitrarily far into the future by choosing the iat value in the
	DPoP proof to be signed by the proof-of-possession key. Note that		DPoP proof to be signed by the proof-of-possession key. Note that
	one such attacker is the person who is the legitimate user of the		one such attacker is the person who is the legitimate user of the
	client. The user may pre-generate DPoP proofs to exfiltrate from the		client. The user may pre-generate DPoP proofs to exfiltrate from the
	machine possessing the proof-of-possession key upon which they were		machine possessing the proof-of-possession key upon which they were
	generated and copy them to another machine that does not possess the		generated and copy them to another machine that does not possess the
	key. For instance, a bank employee might pre-generate DPoP proofs on		key. For instance, a bank employee might pre-generate DPoP proofs on
	a bank computer and then copy them to another machine for use in the		a bank computer and then copy them to another machine for use in the
	skipping to change at page 26, line 38 ¶		skipping to change at page 26, line 38 ¶
	The ath claim limits the use of pre-generated DPoP proofs to the		The ath claim limits the use of pre-generated DPoP proofs to the
	lifetime of the access token. Deployments that do not utilize the		lifetime of the access token. Deployments that do not utilize the
	nonce mechanism SHOULD NOT issue long-lived DPoP constrained access		nonce mechanism SHOULD NOT issue long-lived DPoP constrained access
	tokens, preferring instead to use short-lived access tokens and		tokens, preferring instead to use short-lived access tokens and
	refresh tokens. Whilst an attacker could pre-generate DPoP proofs to		refresh tokens. Whilst an attacker could pre-generate DPoP proofs to
	use the refresh token to obtain a new access token, they would be		use the refresh token to obtain a new access token, they would be
	unable to realistically pre-generate DPoP proofs to use a newly		unable to realistically pre-generate DPoP proofs to use a newly
	issued access token.		issued access token.
	12.3. DPoP Nonce Downgrade		11.3. DPoP Nonce Downgrade
	A server MUST NOT accept any DPoP proofs without the nonce claim when		A server MUST NOT accept any DPoP proofs without the nonce claim when
	a DPoP nonce has been provided to the client.		a DPoP nonce has been provided to the client.
	12.4. Untrusted Code in the Client Context		11.4. Untrusted Code in the Client Context
	If an adversary is able to run code in the client's execution		If an adversary is able to run code in the client's execution
	context, the security of DPoP is no longer guaranteed. Common issues		context, the security of DPoP is no longer guaranteed. Common issues
	in web applications leading to the execution of untrusted code are		in web applications leading to the execution of untrusted code are
	cross-site scripting and remote code inclusion attacks.		cross-site scripting and remote code inclusion attacks.
	If the private key used for DPoP is stored in such a way that it		If the private key used for DPoP is stored in such a way that it
	cannot be exported, e.g., in a hardware or software security module,		cannot be exported, e.g., in a hardware or software security module,
	the adversary cannot exfiltrate the key and use it to create		the adversary cannot exfiltrate the key and use it to create
	arbitrary DPoP proofs. The adversary can, however, create new DPoP		arbitrary DPoP proofs. The adversary can, however, create new DPoP
	skipping to change at page 27, line 31 ¶		skipping to change at page 27, line 31 ¶
	has access to the resulting authorization code and can use it to		has access to the resulting authorization code and can use it to
	associate their own DPoP keys with the tokens returned from the token		associate their own DPoP keys with the tokens returned from the token
	endpoint. The adversary is then able to use the resulting tokens on		endpoint. The adversary is then able to use the resulting tokens on
	their own device even if the client is offline.		their own device even if the client is offline.
	Therefore, protecting clients against the execution of untrusted code		Therefore, protecting clients against the execution of untrusted code
	is extremely important even if DPoP is used. Besides secure coding		is extremely important even if DPoP is used. Besides secure coding
	practices, Content Security Policy [W3C.CSP] can be used as a second		practices, Content Security Policy [W3C.CSP] can be used as a second
	layer of defense against cross-site scripting.		layer of defense against cross-site scripting.
	12.5. Signed JWT Swapping		11.5. Signed JWT Swapping
	Servers accepting signed DPoP proof JWTs MUST check the typ field in		Servers accepting signed DPoP proof JWTs MUST check the typ field in
	the headers of the JWTs to ensure that adversaries cannot use JWTs		the headers of the JWTs to ensure that adversaries cannot use JWTs
	created for other purposes.		created for other purposes.
	12.6. Signature Algorithms		11.6. Signature Algorithms
	Implementers MUST ensure that only asymmetric digital signature		Implementers MUST ensure that only asymmetric digital signature
	algorithms that are deemed secure can be used for signing DPoP		algorithms that are deemed secure can be used for signing DPoP
	proofs. In particular, the algorithm none MUST NOT be allowed.		proofs. In particular, the algorithm none MUST NOT be allowed.
	12.7. Message Integrity		11.7. Message Integrity
	DPoP does not ensure the integrity of the payload or headers of		DPoP does not ensure the integrity of the payload or headers of
	requests. The DPoP proof only contains claims for the HTTP URI and		requests. The DPoP proof only contains claims for the HTTP URI and
	method, but not, for example, the message body or general request		method, but not, for example, the message body or general request
	headers.		headers.
	This is an intentional design decision intended to keep DPoP simple		This is an intentional design decision intended to keep DPoP simple
	to use, but as described, makes DPoP potentially susceptible to		to use, but as described, makes DPoP potentially susceptible to
	replay attacks where an attacker is able to modify message contents		replay attacks where an attacker is able to modify message contents
	and headers. In many setups, the message integrity and		and headers. In many setups, the message integrity and
	skipping to change at page 28, line 21 ¶		skipping to change at page 28, line 21 ¶
	Implementers that have stronger requirements on the integrity of		Implementers that have stronger requirements on the integrity of
	messages are encouraged to either use TLS-based mechanisms or signed		messages are encouraged to either use TLS-based mechanisms or signed
	requests. TLS-based mechanisms are in particular OAuth Mutual TLS		requests. TLS-based mechanisms are in particular OAuth Mutual TLS
	[RFC8705] and OAuth Token Binding [I-D.ietf-oauth-token-binding].		[RFC8705] and OAuth Token Binding [I-D.ietf-oauth-token-binding].
	Note: While signatures covering other parts of requests are out of		Note: While signatures covering other parts of requests are out of
	the scope of this specification, additional information to be signed		the scope of this specification, additional information to be signed
	can be added into DPoP proofs.		can be added into DPoP proofs.
	12.8. Access Token and Public Key Binding		11.8. Access Token and Public Key Binding
	The binding of the access token to the DPoP public key, which is		The binding of the access token to the DPoP public key, which is
	specified in Section 6, uses a cryptographic hash of the JWK		specified in Section 6, uses a cryptographic hash of the JWK
	representation of the public key. It relies on the hash function		representation of the public key. It relies on the hash function
	having sufficient second-preimage resistance so as to make it		having sufficient second-preimage resistance so as to make it
	computationally infeasible to find or create another key that		computationally infeasible to find or create another key that
	produces to the same hash output value. The SHA-256 hash function		produces to the same hash output value. The SHA-256 hash function
	was used because it meets the aforementioned requirement while being		was used because it meets the aforementioned requirement while being
	widely available. If, in the future, JWK Thumbprints need to be		widely available. If, in the future, JWK Thumbprints need to be
	computed using hash function(s) other than SHA-256, it is suggested		computed using hash function(s) other than SHA-256, it is suggested
	skipping to change at page 29, line 5 ¶		skipping to change at page 29, line 5 ¶
	Similarly, the binding of the DPoP proof to the access token uses a		Similarly, the binding of the DPoP proof to the access token uses a
	hash of that access token as the value of the ath claim in the DPoP		hash of that access token as the value of the ath claim in the DPoP
	proof (see Section 4.2). This relies on the value of the hash being		proof (see Section 4.2). This relies on the value of the hash being
	sufficiently unique so as to reliably identify the access token. The		sufficiently unique so as to reliably identify the access token. The
	collision resistance of SHA-256 meets that requirement. If, in the		collision resistance of SHA-256 meets that requirement. If, in the
	future, access token digests need be computed using hash function(s)		future, access token digests need be computed using hash function(s)
	other than SHA-256, it is suggested that an additional related JWT		other than SHA-256, it is suggested that an additional related JWT
	claim be defined for that purpose, registered in the respective IANA		claim be defined for that purpose, registered in the respective IANA
	registry, and used in place of the ath claim defined herein.		registry, and used in place of the ath claim defined herein.
	12.9. Authorization Code and Public Key Binding		11.9. Authorization Code and Public Key Binding
	Cryptographic binding of the authorization code to the DPoP public		Cryptographic binding of the authorization code to the DPoP public
	key, is specified in Section 10. This binding prevents attacks in		key, is specified in Section 10. This binding prevents attacks in
	which the attacker captures the authorization code and creates a DPoP		which the attacker captures the authorization code and creates a DPoP
	proof using a proof-of-possession key other than that held by the		proof using a proof-of-possession key other than that held by the
	client and redeems the authorization code using that DPoP proof. By		client and redeems the authorization code using that DPoP proof. By
	ensuring end-to-end that only the client's DPoP key can be used, this		ensuring end-to-end that only the client's DPoP key can be used, this
	prevents captured authorization codes from being exfiltrated and used		prevents captured authorization codes from being exfiltrated and used
	at locations other than the one to which the authorization code was		at locations other than the one to which the authorization code was
	issued.		issued.
	skipping to change at page 29, line 39 ¶		skipping to change at page 29, line 39 ¶
	code_verifier), the attacker can create a forged token request,		code_verifier), the attacker can create a forged token request,
	binding the resulting token to an attacker-controlled key. For		binding the resulting token to an attacker-controlled key. For
	example, using cross-site scripting, attackers might obtain access to		example, using cross-site scripting, attackers might obtain access to
	the authorization code and PKCE parameters. Use of the dpop_jkt		the authorization code and PKCE parameters. Use of the dpop_jkt
	parameter prevents this attack.		parameter prevents this attack.
	The binding of the authorization code to the DPoP public key uses a		The binding of the authorization code to the DPoP public key uses a
	JWK Thumbprint of the public key, just as the access token binding		JWK Thumbprint of the public key, just as the access token binding
	does. The same JWK Thumbprint considerations apply.		does. The same JWK Thumbprint considerations apply.
	13. IANA Considerations		12. IANA Considerations
	13.1. OAuth Access Token Type Registration		12.1. OAuth Access Token Type Registration
	This specification requests registration of the following access		This specification requests registration of the following access
	token type in the "OAuth Access Token Types" registry		token type in the "OAuth Access Token Types" registry
	[IANA.OAuth.Params] established by [RFC6749].		[IANA.OAuth.Params] established by [RFC6749].
	* Type name: DPoP		* Type name: DPoP
	* Additional Token Endpoint Response Parameters: (none)		* Additional Token Endpoint Response Parameters: (none)
	* HTTP Authentication Scheme(s): DPoP		* HTTP Authentication Scheme(s): DPoP
	* Change controller: IESG		* Change controller: IESG
	* Specification document(s): [[ this specification ]]		* Specification document(s): [[ this specification ]]
	13.2. OAuth Extensions Error Registration		12.2. OAuth Extensions Error Registration
	This specification requests registration of the following error		This specification requests registration of the following error
	values in the "OAuth Extensions Error" registry [IANA.OAuth.Params]		values in the "OAuth Extensions Error" registry [IANA.OAuth.Params]
	established by [RFC6749].		established by [RFC6749].
	Invalid DPoP proof:		Invalid DPoP proof:
	* Name: invalid_dpop_proof		* Name: invalid_dpop_proof
	* Usage Location: token error response, resource error response		* Usage Location: token error response, resource error response
	skipping to change at page 30, line 38 ¶		skipping to change at page 30, line 38 ¶
	* Name: use_dpop_nonce		* Name: use_dpop_nonce
	* Usage Location: token error response, resource error response		* Usage Location: token error response, resource error response
	* Protocol Extension: Demonstrating Proof of Possession (DPoP)		* Protocol Extension: Demonstrating Proof of Possession (DPoP)
	* Change controller: IETF		* Change controller: IETF
	* Specification document(s): [[ this specification ]]		* Specification document(s): [[ this specification ]]
	13.3. OAuth Parameters Registration		12.3. OAuth Parameters Registration
	This specification requests registration of the following		This specification requests registration of the following
	authorization request parameter in the "OAuth Parameters" registry		authorization request parameter in the "OAuth Parameters" registry
	[IANA.OAuth.Params] established by [RFC6749].		[IANA.OAuth.Params] established by [RFC6749].
	* Name: dpop_jkt		* Name: dpop_jkt
	* Parameter Usage Locaion: authorization request		* Parameter Usage Location: authorization request
	* Change Controller: IESG		* Change Controller: IESG
	* Reference: [[ {#dpop_jkt} of this specification ]]		* Reference: [[ {#dpop_jkt} of this specification ]]
	13.4. HTTP Authentication Scheme Registration		12.4. HTTP Authentication Scheme Registration
	This specification requests registration of the following scheme in		This specification requests registration of the following scheme in
	the "Hypertext Transfer Protocol (HTTP) Authentication Scheme		the "Hypertext Transfer Protocol (HTTP) Authentication Scheme
	Registry" [RFC7235][IANA.HTTP.AuthSchemes]:		Registry" [RFC7235][IANA.HTTP.AuthSchemes]:
	* Authentication Scheme Name: DPoP		* Authentication Scheme Name: DPoP
	* Reference: [[ Section 7.1 of this specification ]]		* Reference: [[ Section 7.1 of this specification ]]
	13.5. Media Type Registration		12.5. Media Type Registration
	[[ Is a media type registration at [IANA.MediaTypes] necessary for		[[ Is a media type registration at [IANA.MediaTypes] necessary for
	application/dpop+jwt? There is a +jwt structured syntax suffix		application/dpop+jwt? There is a +jwt structured syntax suffix
	registered already at [IANA.MediaType.StructuredSuffix] by		registered already at [IANA.MediaType.StructuredSuffix] by
	Section 7.2 of [RFC8417], which is maybe sufficient? A full-blown		Section 7.2 of [RFC8417], which is maybe sufficient? A full-blown
	registration of application/dpop+jwt seems like it'd be overkill.		registration of application/dpop+jwt seems like it'd be overkill.
	The dpop+jwt is used in the JWS/JWT typ header for explicit typing of		The dpop+jwt is used in the JWS/JWT typ header for explicit typing of
	the JWT per Section 3.11 of [RFC8725] but it is not used anywhere		the JWT per Section 3.11 of [RFC8725] but it is not used anywhere
	else (such as the Content-Type of HTTP messages).		else (such as the Content-Type of HTTP messages).
	Note that there does seem to be some precedence for [IANA.MediaTypes]		Note that there does seem to be some precedence for [IANA.MediaTypes]
	registration with application/at+jwt in [RFC9068], application/oauth-		registration with application/at+jwt in [RFC9068], application/oauth-
	authz-req+jwt in [RFC9101], application/secevent+jwt in [RFC8417],		authz-req+jwt in [RFC9101], application/secevent+jwt in [RFC8417],
	and regular old application/jwt in [RFC7519]. But precedence isn't		and regular old application/jwt in [RFC7519]. But precedence isn't
	always right. ]]		always right. ]]
	13.6. JWT Confirmation Methods Registration		12.6. JWT Confirmation Methods Registration
	This specification requests registration of the following value in		This specification requests registration of the following value in
	the IANA "JWT Confirmation Methods" registry [IANA.JWT] for JWT cnf		the IANA "JWT Confirmation Methods" registry [IANA.JWT] for JWT cnf
	member values established by [RFC7800].		member values established by [RFC7800].
	* Confirmation Method Value: jkt		* Confirmation Method Value: jkt
	* Confirmation Method Description: JWK SHA-256 Thumbprint		* Confirmation Method Description: JWK SHA-256 Thumbprint
	* Change Controller: IESG		* Change Controller: IESG
	* Specification Document(s): [[ Section 6 of this specification ]]		* Specification Document(s): [[ Section 6 of this specification ]]
	13.7. JSON Web Token Claims Registration		12.7. JSON Web Token Claims Registration
	This specification requests registration of the following Claims in		This specification requests registration of the following Claims in
	the IANA "JSON Web Token Claims" registry [IANA.JWT] established by		the IANA "JSON Web Token Claims" registry [IANA.JWT] established by
	[RFC7519].		[RFC7519].
	HTTP method:		HTTP method:
	* Claim Name: htm		* Claim Name: htm
	* Claim Description: The HTTP method of the request		* Claim Description: The HTTP method of the request
	skipping to change at page 32, line 35 ¶		skipping to change at page 32, line 35 ¶
	* Claim Name: ath		* Claim Name: ath
	* Claim Description: The base64url encoded SHA-256 hash of the ASCII		* Claim Description: The base64url encoded SHA-256 hash of the ASCII
	encoding of the associated access token's value		encoding of the associated access token's value
	* Change Controller: IESG		* Change Controller: IESG
	* Specification Document(s): [[ Section 4.2 of this specification ]]		* Specification Document(s): [[ Section 4.2 of this specification ]]
	13.8. HTTP Message Header Field Names Registration		12.8. HTTP Message Header Field Names Registration
	This document specifies the following HTTP header fields,		This document specifies the following HTTP header fields,
	registration of which is requested in the "Permanent Message Header		registration of which is requested in the "Permanent Message Header
	Field Names" registry [IANA.Headers] defined in [RFC3864].		Field Names" registry [IANA.Headers] defined in [RFC3864].
	* Header Field Name: DPoP		* Header Field Name: DPoP
	* Applicable protocol: HTTP		* Applicable protocol: HTTP
	* Status: standard		* Status: standard
	* Author/change Controller: IETF		* Author/change Controller: IETF
	* Specification Document(s): [[ this specification ]]		* Specification Document(s): [[ this specification ]]
	13.9. OAuth Authorization Server Metadata Registration		12.9. OAuth Authorization Server Metadata Registration
	This specification requests registration of the following value in		This specification requests registration of the following value in
	the IANA "OAuth Authorization Server Metadata" registry		the IANA "OAuth Authorization Server Metadata" registry
	[IANA.OAuth.Parameters] established by [RFC8414].		[IANA.OAuth.Parameters] established by [RFC8414].
	* Metadata Name: dpop_signing_alg_values_supported		* Metadata Name: dpop_signing_alg_values_supported
	* Metadata Description: JSON array containing a list of the JWS		* Metadata Description: JSON array containing a list of the JWS
	algorithms supported for DPoP proof JWTs		algorithms supported for DPoP proof JWTs
	* Change Controller: IESG		* Change Controller: IESG
	* Specification Document(s): [[ Section 5.1 of this specification ]]		* Specification Document(s): [[ Section 5.1 of this specification ]]
	13.10. OAuth Dynamic Client Registration Metadata		12.10. OAuth Dynamic Client Registration Metadata
	This specification requests registration of the following value in		This specification requests registration of the following value in
	the IANA "OAuth Dynamic Client Registration Metadata" registry		the IANA "OAuth Dynamic Client Registration Metadata" registry
	[IANA.OAuth.Parameters] established by [RFC7591].		[IANA.OAuth.Parameters] established by [RFC7591].
	* Metadata Name: always_uses_dpop		* Metadata Name: dpop_bound_access_tokens
	* Metadata Description: Boolean value specifying whether the client		* Metadata Description: Boolean value specifying whether the client
	always uses DPoP for token requests		always uses DPoP for token requests
	* Change Controller: IESG		* Change Controller: IESG
	* Specification Document(s): [[ Section 5.2 of this specification ]]		* Specification Document(s): [[ Section 5.2 of this specification ]]
	14. Normative References		13. Normative References
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014,
	<https://www.rfc-editor.org/info/rfc7231>.
	[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September		Requirement Levels", BCP 14, RFC 2119,
	2015, <https://www.rfc-editor.org/info/rfc7638>.		DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
	[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	DOI 10.17487/RFC7518, May 2015,		Resource Identifier (URI): Generic Syntax", STD 66,
	<https://www.rfc-editor.org/info/rfc7518>.		RFC 3986, DOI 10.17487/RFC3986, January 2005,
			<https://www.rfc-editor.org/info/rfc3986>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
			[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
			RFC 6749, DOI 10.17487/RFC6749, October 2012,
			<https://www.rfc-editor.org/info/rfc6749>.
			[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
			Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
			DOI 10.17487/RFC7231, June 2014,
			<https://www.rfc-editor.org/info/rfc7231>.
	[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web		[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
	Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May		Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
	2015, <https://www.rfc-editor.org/info/rfc7515>.		2015, <https://www.rfc-editor.org/info/rfc7515>.
	[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",		[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
	RFC 6749, DOI 10.17487/RFC6749, October 2012,		DOI 10.17487/RFC7518, May 2015,
	<https://www.rfc-editor.org/info/rfc6749>.		<https://www.rfc-editor.org/info/rfc7518>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
	Resource Identifier (URI): Generic Syntax", STD 66,		Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		2015, <https://www.rfc-editor.org/info/rfc7638>.
	<https://www.rfc-editor.org/info/rfc3986>.
	[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-		[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
	Possession Key Semantics for JSON Web Tokens (JWTs)",		Possession Key Semantics for JSON Web Tokens (JWTs)",
	RFC 7800, DOI 10.17487/RFC7800, April 2016,		RFC 7800, DOI 10.17487/RFC7800, April 2016,
	<https://www.rfc-editor.org/info/rfc7800>.		<https://www.rfc-editor.org/info/rfc7800>.
	15. Informative References		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			14. Informative References
	[I-D.ietf-oauth-security-topics]		[I-D.ietf-oauth-security-topics]
	Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,		Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
	"OAuth 2.0 Security Best Current Practice", Work in		"OAuth 2.0 Security Best Current Practice", Work in
	Progress, Internet-Draft, draft-ietf-oauth-security-		Progress, Internet-Draft, draft-ietf-oauth-security-
	topics-19, 16 December 2021,		topics-19, 16 December 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-		<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
	security-topics-19>.		security-topics-19>.
	[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0		[I-D.ietf-oauth-token-binding]
	Authorization Server Metadata", RFC 8414,		Jones, M. B., Campbell, B., Bradley, J., and W. Denniss,
	DOI 10.17487/RFC8414, June 2018,		"OAuth 2.0 Token Binding", Work in Progress, Internet-
	<https://www.rfc-editor.org/info/rfc8414>.		Draft, draft-ietf-oauth-token-binding-08, 19 October 2018,
			<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
	[IANA.OAuth.Params]		token-binding-08>.
	IANA, "OAuth Parameters",
	<https://www.iana.org/assignments/oauth-parameters>.
	[IANA.HTTP.AuthSchemes]		[IANA.HTTP.AuthSchemes]
	IANA, "Hypertext Transfer Protocol (HTTP) Authentication		IANA, "Hypertext Transfer Protocol (HTTP) Authentication
	Scheme Registry",		Scheme Registry",
	<https://www.iana.org/assignments/http-authschemes>.		<https://www.iana.org/assignments/http-authschemes>.
	[IANA.Headers]		[IANA.Headers]
	IANA, "Message Headers",		IANA, "Message Headers",
	<https://www.iana.org/assignments/message-headers>.		<https://www.iana.org/assignments/message-headers>.
	[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and		[IANA.JWT] IANA, "JSON Web Token Claims",
	P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",		<http://www.iana.org/assignments/jwt>.
	RFC 7591, DOI 10.17487/RFC7591, July 2015,
	<https://www.rfc-editor.org/info/rfc7591>.
	[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<https://www.rfc-editor.org/info/rfc7519>.
	[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
	(JWT) Profile for OAuth 2.0 Client Authentication and
	Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
	2015, <https://www.rfc-editor.org/info/rfc7523>.
	[IANA.MediaType.StructuredSuffix]		[IANA.MediaType.StructuredSuffix]
	IANA, "Structured Syntax Suffix Registry",		IANA, "Structured Syntax Suffix Registry",
	<https://www.iana.org/assignments/media-type-structured-		<https://www.iana.org/assignments/media-type-structured-
	suffix>.		suffix>.
	[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best		[IANA.MediaTypes]
	Current Practices", BCP 225, RFC 8725,		IANA, "Media Types",
	DOI 10.17487/RFC8725, February 2020,		<https://www.iana.org/assignments/media-types>.
	<https://www.rfc-editor.org/info/rfc8725>.
			[IANA.OAuth.Params]
			IANA, "OAuth Parameters",
			<https://www.iana.org/assignments/oauth-parameters>.
	[OpenID.Core]		[OpenID.Core]
	Sakimura, N., Bradley, J., Jones, M.B., Medeiros, B.d.,		Sakimura, N., Bradley, J., Jones, M.B., Medeiros, B.d.,
	and C. Mortimore, "OpenID Connect Core 1.0", November		and C. Mortimore, "OpenID Connect Core 1.0", November
	2014,		2014,
	<http://openid.net/specs/openid-connect-core-1_0.html>.		<http://openid.net/specs/openid-connect-core-1_0.html>.
	[RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
	and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
	RFC 9126, DOI 10.17487/RFC9126, September 2021,
	<https://www.rfc-editor.org/info/rfc9126>.
	[RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari,
	"Security Event Token (SET)", RFC 8417,
	DOI 10.17487/RFC8417, July 2018,
	<https://www.rfc-editor.org/info/rfc8417>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	Unique IDentifier (UUID) URN Namespace", RFC 4122,
	DOI 10.17487/RFC4122, July 2005,
	<https://www.rfc-editor.org/info/rfc4122>.
	[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
	RFC 7662, DOI 10.17487/RFC7662, October 2015,
	<https://www.rfc-editor.org/info/rfc7662>.
	[RFC9101] Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0
	Authorization Framework: JWT-Secured Authorization Request
	(JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021,
	<https://www.rfc-editor.org/info/rfc9101>.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	DOI 10.17487/RFC3864, September 2004,		DOI 10.17487/RFC3864, September 2004,
	<https://www.rfc-editor.org/info/rfc3864>.		<https://www.rfc-editor.org/info/rfc3864>.
	[IANA.MediaTypes]		[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	IANA, "Media Types",		Unique IDentifier (UUID) URN Namespace", RFC 4122,
	<https://www.iana.org/assignments/media-types>.		DOI 10.17487/RFC4122, July 2005,
			<https://www.rfc-editor.org/info/rfc4122>.
	[I-D.ietf-oauth-token-binding]		[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
	Jones, M. B., Campbell, B., Bradley, J., and W. Denniss,		Framework: Bearer Token Usage", RFC 6750,
	"OAuth 2.0 Token Binding", Work in Progress, Internet-		DOI 10.17487/RFC6750, October 2012,
	Draft, draft-ietf-oauth-token-binding-08, 19 October 2018,		<https://www.rfc-editor.org/info/rfc6750>.
	<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
	token-binding-08>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<https://www.rfc-editor.org/info/rfc7230>.		<https://www.rfc-editor.org/info/rfc7230>.
	[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
	Framework: Bearer Token Usage", RFC 6750,
	DOI 10.17487/RFC6750, October 2012,
	<https://www.rfc-editor.org/info/rfc6750>.
	[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Authentication", RFC 7235,		Protocol (HTTP/1.1): Authentication", RFC 7235,
	DOI 10.17487/RFC7235, June 2014,		DOI 10.17487/RFC7235, June 2014,
	<https://www.rfc-editor.org/info/rfc7235>.		<https://www.rfc-editor.org/info/rfc7235>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	Requirement Levels", BCP 14, RFC 2119,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	DOI 10.17487/RFC2119, March 1997,		<https://www.rfc-editor.org/info/rfc7519>.
	<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource		[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
	Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,		(JWT) Profile for OAuth 2.0 Client Authentication and
	February 2020, <https://www.rfc-editor.org/info/rfc8707>.		Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
			2015, <https://www.rfc-editor.org/info/rfc7523>.
	[W3C.WebCryptoAPI]		[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
	Watson, M., "Web Cryptography API", 26 January 2017,		P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
	<https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126>.		RFC 7591, DOI 10.17487/RFC7591, July 2015,
			<https://www.rfc-editor.org/info/rfc7591>.
	[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key		[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
	for Code Exchange by OAuth Public Clients", RFC 7636,		for Code Exchange by OAuth Public Clients", RFC 7636,
	DOI 10.17487/RFC7636, September 2015,		DOI 10.17487/RFC7636, September 2015,
	<https://www.rfc-editor.org/info/rfc7636>.		<https://www.rfc-editor.org/info/rfc7636>.
	[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0		[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
	Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October		RFC 7662, DOI 10.17487/RFC7662, October 2015,
	2021, <https://www.rfc-editor.org/info/rfc9068>.		<https://www.rfc-editor.org/info/rfc7662>.
	[IANA.JWT] IANA, "JSON Web Token Claims",		[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
	<http://www.iana.org/assignments/jwt>.		Authorization Server Metadata", RFC 8414,
			DOI 10.17487/RFC8414, June 2018,
			<https://www.rfc-editor.org/info/rfc8414>.
			[RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari,
			"Security Event Token (SET)", RFC 8417,
			DOI 10.17487/RFC8417, July 2018,
			<https://www.rfc-editor.org/info/rfc8417>.
	[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.		[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
	Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication		Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
	and Certificate-Bound Access Tokens", RFC 8705,		and Certificate-Bound Access Tokens", RFC 8705,
	DOI 10.17487/RFC8705, February 2020,		DOI 10.17487/RFC8705, February 2020,
	<https://www.rfc-editor.org/info/rfc8705>.		<https://www.rfc-editor.org/info/rfc8705>.
	[W3C.CSP] West, M., "Content Security Policy Level 3", 15 October		[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
			Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
			February 2020, <https://www.rfc-editor.org/info/rfc8707>.
			[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
			Current Practices", BCP 225, RFC 8725,
			DOI 10.17487/RFC8725, February 2020,
			<https://www.rfc-editor.org/info/rfc8725>.
			[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
			Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
			2021, <https://www.rfc-editor.org/info/rfc9068>.
			[RFC9101] Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0
			Authorization Framework: JWT-Secured Authorization Request
			(JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021,
			<https://www.rfc-editor.org/info/rfc9101>.
			[RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
			and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
			RFC 9126, DOI 10.17487/RFC9126, September 2021,
			<https://www.rfc-editor.org/info/rfc9126>.
			[W3C.CSP] West, M., "Content Security Policy Level 3", World Wide
			Web Consortium Working Draft WD-CSP3-20181015, 15 October
	2018, <https://www.w3.org/TR/2018/WD-CSP3-20181015/>.		2018, <https://www.w3.org/TR/2018/WD-CSP3-20181015/>.
			[W3C.WebCryptoAPI]
			Watson, M., "Web Cryptography API", World Wide Web
			Consortium Recommendation REC-WebCryptoAPI-20170126, 26
			January 2017,
			<https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126>.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	We would like to thank Annabelle Backman, Dominick Baier, Andrii		We would like to thank Annabelle Backman, Dominick Baier, Andrii
	Deinega, William Denniss, Vladimir Dzhuvinov, Mike Engan, Nikos		Deinega, William Denniss, Vladimir Dzhuvinov, Mike Engan, Nikos
	Fotiou, Mark Haine, Dick Hardt, Joseph Heenan, Bjorn Hjelm, Jared		Fotiou, Mark Haine, Dick Hardt, Joseph Heenan, Bjorn Hjelm, Jared
	Jennings, Benjamin Kaduk, Pieter Kasselman, Steinar Noem, Neil		Jennings, Benjamin Kaduk, Pieter Kasselman, Steinar Noem, Neil
	Madden, Rob Otto, Aaron Parecki, Michael Peck, Paul Querna, Justin		Madden, Karsten Meyer zu Selhausen, Rob Otto, Aaron Parecki, Michael
	Richer, Filip Skokan, Dmitry Telegin, Dave Tonge, Jim Willeke,		Peck, Paul Querna, Justin Richer, Filip Skokan, Dmitry Telegin, Dave
	Philippe De Ryck, and others (please let us know, if you've been		Tonge, Jim Willeke, Philippe De Ryck, and others (please let us know,
	mistakenly omitted) for their valuable input, feedback and general		if you've been mistakenly omitted) for their valuable input, feedback
	support of this work.		and general support of this work.
	This document originated from discussions at the 4th OAuth Security		This document originated from discussions at the 4th OAuth Security
	Workshop in Stuttgart, Germany. We thank the organizers of this		Workshop in Stuttgart, Germany. We thank the organizers of this
	workshop (Ralf Kusters, Guido Schmitz).		workshop (Ralf Kusters, Guido Schmitz).
	Appendix B. Document History		Appendix B. Document History
	[[ To be removed from the final specification ]]		[[ To be removed from the final specification ]]
			-06
			* Editorial updates and fixes
			* Changed name of client metadata parameter to
			dpop_bound_access_tokens
	-05		-05
	* Added Authorization Code binding via the dpop_jkt parameter.		* Added Authorization Code binding via the dpop_jkt parameter.
	* Described the authorization code reuse attack and how dpop_jkt		* Described the authorization code reuse attack and how dpop_jkt
	mitigates it.		mitigates it.
	* Enhanced description of DPoP proof expiration checking.		* Enhanced description of DPoP proof expiration checking.
	* Described nonce storage requirements and how nonce mismatches and		* Described nonce storage requirements and how nonce mismatches and
	skipping to change at page 38, line 40 ¶		skipping to change at page 38, line 43 ¶
	errors to do so.		errors to do so.
	* Added a bit more about ath and pre-generated proofs to the		* Added a bit more about ath and pre-generated proofs to the
	security considerations.		security considerations.
	* Mentioned confirming the DPoP binding of the access token in the		* Mentioned confirming the DPoP binding of the access token in the
	list in Section 4.3.		list in Section 4.3.
	* Added the always_uses_dpop client registration metadata parameter.		* Added the always_uses_dpop client registration metadata parameter.
			* Described the relatioship between DPoP and Pushed Authorization
			Requests (PAR).
	* Updated references for drafts that are now RFCs.		* Updated references for drafts that are now RFCs.
	-04		-04
	* Added the option for a server-provided nonce in the DPoP proof.		* Added the option for a server-provided nonce in the DPoP proof.
	* Registered the invalid_dpop_proof and use_dpop_nonce error codes.		* Registered the invalid_dpop_proof and use_dpop_nonce error codes.
	* Removed fictitious uses of realm from the examples, as they added		* Removed fictitious uses of realm from the examples, as they added
	no value.		no value.
End of changes. 63 change blocks.
	186 lines changed or deleted		202 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/