< draft-ietf-oauth-pop-key-distribution-03.txt		draft-ietf-oauth-pop-key-distribution-04.txt >
	Network Working Group J. Bradley		Network Working Group J. Bradley
	Internet-Draft Ping Identity		Internet-Draft Ping Identity
	Intended status: Standards Track P. Hunt		Intended status: Standards Track P. Hunt
	Expires: August 28, 2017 Oracle Corporation		Expires: April 26, 2019 Oracle Corporation
	M. Jones		M. Jones
	Microsoft		Microsoft
	H. Tschofenig		H. Tschofenig
	ARM Limited		Arm Ltd.
	February 24, 2017		M. Mihaly
			NIIF Institute
			October 23, 2018
	OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key		OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key
	Distribution		Distribution
	draft-ietf-oauth-pop-key-distribution-03		draft-ietf-oauth-pop-key-distribution-04
	Abstract		Abstract
	RFC 6750 specified the bearer token concept for securing access to		RFC 6750 specified the bearer token concept for securing access to
	protected resources. Bearer tokens need to be protected in transit		protected resources. Bearer tokens need to be protected in transit
	as well as at rest. When a client requests access to a protected		as well as at rest. When a client requests access to a protected
	resource it hands-over the bearer token to the resource server.		resource it hands-over the bearer token to the resource server.
	The OAuth 2.0 Proof-of-Possession security concept extends bearer		The OAuth 2.0 Proof-of-Possession security concept extends bearer
	token security and requires the client to demonstrate possession of a		token security and requires the client to demonstrate possession of a
	key when accessing a protected resource.		key when accessing a protected resource.
	This document describes how the client obtains this keying material
	from the authorization server.
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 http://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 28, 2017.		This Internet-Draft will expire on April 26, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Audience . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Processing Instructions . . . . . . . . . . . . . . . . . . . 4
	3.1. Audience Parameter . . . . . . . . . . . . . . . . . . . 5		4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Processing Instructions . . . . . . . . . . . . . . . . . 5		4.1. Symmetric Key Transport . . . . . . . . . . . . . . . . . 5
	4. Symmetric Key Transport . . . . . . . . . . . . . . . . . . . 6		4.1.1. Client-to-AS Request . . . . . . . . . . . . . . . . 5
	4.1. Client-to-AS Request . . . . . . . . . . . . . . . . . . 6		4.1.2. Client-to-AS Response . . . . . . . . . . . . . . . . 6
	4.2. Client-to-AS Response . . . . . . . . . . . . . . . . . . 7		4.2. Asymmetric Key Transport . . . . . . . . . . . . . . . . 9
	5. Asymmetric Key Transport . . . . . . . . . . . . . . . . . . 9		4.2.1. Client-to-AS Request . . . . . . . . . . . . . . . . 9
	5.1. Client-to-AS Request . . . . . . . . . . . . . . . . . . 9		4.2.2. Client-to-AS Response . . . . . . . . . . . . . . . . 10
	5.2. Client-to-AS Response . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. Token Types and Algorithms . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6.1. OAuth Access Token Types . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		6.2. OAuth Parameters Registration . . . . . . . . . . . . . . 13
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15		6.3. OAuth Extensions Error Registration . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Normative References . . . . . . . . . . . . . . . . . . 15		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.2. Informative References . . . . . . . . . . . . . . . . . 16		8.1. Normative References . . . . . . . . . . . . . . . . . . 14
	Appendix A. Augmented Backus-Naur Form (ABNF) Syntax . . . . . . 17		8.2. Informative References . . . . . . . . . . . . . . . . . 15
	A.1. 'aud' Syntax . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	A.2. 'key' Syntax . . . . . . . . . . . . . . . . . . . . . . 18
	A.3. 'alg' Syntax . . . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The work on additional security mechanisms beyond OAuth 2.0 bearer		The work on proof-of-possession tokens, an extended token security
	tokens [12] is motivated in [17], which also outlines use cases,		mechanisms for OAuth 2.0, is motivated in [21]. This document
	requirements and an architecture. This document defines the ability		defines the ability for the client request and to obtain PoP tokens
	for the client indicate support for this functionality and to obtain		from the authorization server. After successfully completing the
	keying material from the authorization server. As an outcome of the		exchange the client is in possession of a PoP token and the keying
	exchange between the client and the authorization server is an access		material bound to it. Clients that access protected resources then
	token that is bound to keying material. Clients that access		need to demonstrate knowledge of the secret key that is bound to the
	protected resources then need to demonstrate knowledge of the secret		PoP token.
	key that is bound to the access token.
	To best describe the scope of this specification, the OAuth 2.0		To best describe the scope of this specification, the OAuth 2.0
	protocol exchange sequence is shown in Figure 1. The extension		protocol exchange sequence is shown in Figure 1. The extension
	defined in this document piggybacks on the message exchange marked		defined in this document piggybacks on the message exchange marked
	with (C) and (D).		with (C) and (D). To demonstrate possession of the private/secret
			key to the resource server protocol mechanisms outside the scope of
			this document are used.
	+--------+ +---------------+		+--------+ +---------------+
	| |--(A)- Authorization Request ->| Resource |		| |--(A)- Authorization Request ->| Resource |
	| | | Owner |		| | | Owner |
	| |<-(B)-- Authorization Grant ---| |		| |<-(B)-- Authorization Grant ---| |
	| | +---------------+		| | +---------------+
	| |		| |
	| | +---------------+		| | +---------------+
	| |--(C)-- Authorization Grant -->| Authorization |		| |--(C)-- Authorization Grant -->| |
	| Client | | Server |		| Client | (resource, req_cnf) | Authorization |
	| |<-(D)----- Access Token -------| |		| | | Server |
	| | +---------------+		| |<-(D)-- PoP Access Token ------| |
	| |		| | (rs_cnf, token_type) +---------------+
	| | +---------------+		| |
	| |--(E)----- Access Token ------>| Resource |		| | +---------------+
	| | | Server |		| |--(E)-- PoP Access Token ----->| |
	| |<-(F)--- Protected Resource ---| |		| | (with proof of private key) | Resource |
	+--------+ +---------------+		| | | Server |
			| |<-(F)--- Protected Resource ---| |
			+--------+ +---------------+
	Figure 1: Abstract OAuth 2.0 Protocol Flow		Figure 1: Augmented OAuth 2.0 Protocol Flow
	In OAuth 2.0 [2] access tokens can be obtained via authorization		In OAuth 2.0 [2] access tokens can be obtained via authorization
	grants and using refresh tokens. The core OAuth specification		grants and using refresh tokens. The core OAuth specification
	defines four authorization grants, see Section 1.3 of [2], and [14]		defines four authorization grants, see Section 1.3 of [2], and [18]
	adds an assertion-based authorization grant to that list. The token		adds an assertion-based authorization grant to that list. The token
	endpoint, which is described in Section 3.2 of [2], is used with		endpoint, which is described in Section 3.2 of [2], is used with
	every authorization grant except for the implicit grant type. In the		every authorization grant except for the implicit grant type. In the
	implicit grant type the access token is issued directly.		implicit grant type the access token is issued directly.
	This document extends the functionality of the token endpoint, i.e.,		This specification extends the functionality of the token endpoint,
	the protocol exchange between the client and the authorization		i.e., the protocol exchange between the client and the authorization
	server, to allow keying material to be bound to an access token. Two		server, to allow keying material to be bound to an access token. Two
	types of keying material can be bound to an access token, namely		types of keying material can be bound to an access token, namely
	symmetric keys and asymmetric keys. Conveying symmetric keys from		symmetric keys and asymmetric keys. Conveying symmetric keys from
	the authorization server to the client is described in Section 4 and		the authorization server to the client is described in Section 4.1
	the procedure for dealing with asymmetric keys is described in		and the procedure for dealing with asymmetric keys is described in
	Section 5.		Section 4.2.
			This document describes how the client requests and obtains a PoP
			access token from the authorization server for use with HTTPS-based
			transport. The use of alternative transports, such as Constrained
			Application Protocol (CoAP), is described in [23].
	2. Terminology		2. Terminology
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
	'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this		'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
	specification are to be interpreted as described in [1].		specification are to be interpreted as described in [1].
	Session Key:		Session Key:
	The term session key refers to fresh and unique keying material		In the context of this specification 'session key' refers to fresh
	established between the client and the resource server. This		and unique keying material established between the client and the
	session key has a lifetime that corresponds to the lifetime of the		resource server. This session key has a lifetime that corresponds
	access token, is generated by the authorization server and bound		to the lifetime of the access token, is generated by the
	to the access token.		authorization server and bound to the access token.
	This document uses the following abbreviations:		This document uses the following abbreviations:
	JWA: JSON Web Algorithms (JWA) [7]		JWA: JSON Web Algorithms[7]
	JWT: JSON Web Token (JWT) [9]
	JWS: JSON Web Signature (JWS) [6]
	JWK: JSON Web Key (JWK) [5]
	JWE: JSON Web Encryption (JWE) [8]
	3. Audience
	When an authorization server creates an access token, according to
	the PoP security architecture [17], it may need to know which
	resource server will process it. This information is necessary when
	the authorization server applies integrity protection to the JWT
	using a symmetric key and has to selected the key of the resource
	server that has to verify it. The authorization server also requires
	this audience information if it has to encrypt a symmetric session
	key inside the access token using a long-term symmetric key.
	This section defines a new header that is used by the client to
	indicate what protected resource at which resource server it wants to
	access. This information may subsequently also communicated by the
	authorization server securely to the resource server, for example
	within the audience field of the access token.
	QUESTION: A benefit of asymmetric cryptography is to allow clients to		JWT: JSON Web Token[9]
	request a PoP token for use with multiple resource servers. The
	downside of that approach is linkability since different resource
	servers will be able to link individual requests to the same client.
	(The same is true if the a single public key is linked with PoP		JWS: JSON Web Signature[6]
	tokens used with different resource servers.) Nevertheless, to
	support the functionality the audience parameter could carry an array
	of values. Is this desirable?
	3.1. Audience Parameter		JWK: JSON Web Key[5]
	The client constructs the access token request to the token endpoint		JWE: JSON Web Encryption[8]
	by adding the 'aud' parameter using the "application/x-www-form-
	urlencoded" format with a character encoding of UTF-8 in the HTTP
	request entity-body.
	The URI included in the aud parameter MUST be an absolute URI as		CWT: CBOR Web Token[13]
	defined by Section 4.3 of [3]. It MAY include an "application/x-www-
	form-urlencoded" formatted query component (Section 3.4 of [3] ).
	The URI MUST NOT include a fragment component.
	The ABNF syntax for the 'aud' element is defined in Appendix A.		COSE: CBOR Object Signing and Encryption[14]
	3.2. Processing Instructions		3. Processing Instructions
	Step (0): As an initial step the client typically determines the		Step (0): As an initial step the client typically determines the
	resource server it wants to interact with. This may, for example,		resource server it wants to interact with. This may, for example,
	happen as part of a discovery procedure or via manual		happen as part of a discovery procedure or via manual
	configuration.		configuration.
	Step (1): The client starts the OAuth 2.0 protocol interaction		Step (1): The client starts the OAuth 2.0 protocol interaction
	based on the selected grant type.		based on the selected grant type.
	Step (2): When the client interacts with the token endpoint to		Step (2): When the client interacts with the token endpoint to
	obtain an access token it MUST populate the newly defined		obtain an access token it MUST use the resource identicator
	'audience' parameter with the information obtained in step (0).		defined in [15] when symmetric PoP tokens are used. For
			asymmetric PoP tokens the use of resource indicators is optional
			but recommended.
	Step (2): The authorization server who obtains the request from		Step (2): The authorization server parses the request from the
	the client needs to parse it to determine whether the provided		server and determines the suitable response based on OAuth 2.0 and
	audience value matches any of the resource servers it has a		the PoP token credential procedures.
	relationship with. If the authorization server fails to parse the
	provided value it MUST reject the request using an error response
	with the error code "invalid_request". If the authorization
	server does not consider the resource server acceptable it MUST
	return an error response with the error code "access_denied". In
	both cases additional error information may be provided via the
	error_description, and the error_uri parameters. If the request
	has, however, been verified successfully then the authorization
	server MUST include the audience claim into the access token with
	the value copied from the audience field provided by the client.
	In case the access token is encoded using the JSON Web Token
	format [9] the "aud" claim MUST be used. The access token, if
	passed per value, MUST be protected against modification by either
	using a digital signature or a keyed message digest. Access
	tokens can also be passed by reference, which then requires the
	token introspection endpoint (or a similiar, proprietary protocol
	mechanism) to be used. The authorization server returns the
	access token to the client, as specified in [2].
	Subsequent steps for the interaction between the client and the		Note that PoP access tokens may be encoded in a variety of ways:
	resource server are beyond the scope of this document.
	4. Symmetric Key Transport		JWT The access token may be encoded using the JSON Web Token (JWT)
			format [9]. The proof-of-possession token functionality is
			described in [10]. A JWT encoded PoP token MUST be protected
			against modification by either using a digital signature or a
			keyed message digest, as described in [6]. The JWT may also be
			encrypted using [8].
	4.1. Client-to-AS Request		CWT [13] defines an alternative token format based on CBOR. The
			proof-of-possession token functionality is defined in [12]. A CWT
			encoded PoP token MUST be protected against modification by either
			using a digital signature or a keyed message digest, as described
			in [12].
	In case a symmetric key shall be bound to an PoP token the following		If the access token is only a reference then a look-up by the
	procedure is applicable. In the request message from the OAuth		resource server is needed, as described in the token introspection
	client to the OAuth authorization server the following parameters MAY		specification [22].
	be included:
	token_type: OPTIONAL. See Section 6 for more details.		Note that the OAuth 2.0 framework nor this specification does not
			mandate a specific PoP token format but using a standardized format
			will improve interoperability and will lead to better code re-use.
	alg: OPTIONAL. See Section 6 for more details.		Application layer interactions between the client and the resource
			server are beyond the scope of this document.
	These two new parameters are optional in the case where the		4. Examples
	authorization server has prior knowledge of the capabilities of the
	client otherwise these two parameters are required. This prior
	knowledge may, for example, be set by the use of a dynamic client
	registration protocol exchange.
	QUESTION: Should we register these two parameters for use with the		This section provides a number of examples.
	dynamic client registration protocol?
	For example, the client makes the following HTTP request using TLS		4.1. Symmetric Key Transport
	(extra line breaks are for display purposes only).
			4.1.1. Client-to-AS Request
			The client starts with a request to the authorization server
			indicating that it is interested to obtain a token for
			https://www.example.com
	POST /token HTTP/1.1		POST /token HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW		Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
	Content-Type: application/x-www-form-urlencoded;charset=UTF-8		Content-Type: application/x-www-form-urlencoded;charset=UTF-8
	grant_type=authorization_code		grant_type=authorization_code
	&code=SplxlOBeZQQYbYS6WxSbIA		&code=SplxlOBeZQQYbYS6WxSbIA
	&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb		&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
	&token_type=pop		&resource=https://www.example.com
	&alg=HS256
	Example Request to the Authorization Server		Example Request to the Authorization Server
	4.2. Client-to-AS Response		4.1.2. Client-to-AS Response
	If the access token request has been successfully verified by the		If the access token request has been successfully verified by the
	authorization server and the client is authorized to obtain a PoP		authorization server and the client is authorized to obtain a PoP
	token for the indicated resource server, the authorization server		token for the indicated resource server, the authorization server
	issues an access token and optionally a refresh token. If client		issues an access token and optionally a refresh token.
	authentication failed or is invalid, the authorization server returns
	an error response as described in Section 5.2 of [2].
	The authorization server MUST include an access token and a 'key'
	element in a successful response. The 'key' parameter either
	contains a plain JWK structure or a JWK encrypted with a JWE. The
	difference between the two approaches is the following:
	Plain JWK: If the JWK container is placed in the 'key' element then
	the security of the overall PoP architecture relies on Transport
	Layer Security (TLS) between the authorization server and the
	client. Figure 2 illustrates an example response using a plain
	JWK for key transport from the authorization server to the client.
	JWK protected by a JWE: If the JWK container is protected by a JWE
	then additional security protection at the application layer is
	provided between the authorization server and the client beyond
	the use of TLS. This approach is a reasonable choice, for
	example, when a hardware security module is available on the
	client device and confidentiality protection can be offered
	directly to this hardware security module.
	Note that there are potentially two JSON-encoded structures in the		Figure 2 shows a response containing a token and a "cnf" parameter
	response, namely the access token (with the recommended JWT encoding)		with a symmetric proof-of-possession key both encoded in a JSON-based
	and the actual key transport mechanism itself. Note, however, that		serialization format. The "cnf" parameter contains the RFC 7517 [5]
	the two structures serve a different purpose and are consumed by		encoded key element.
	different parites. The access token is created by the authorization
	server and processed by the resource server (and opaque to the
	client) whereas the key transport payload is created by the
	authorization server and processed by the client; it is never
	forwarded to the resource server.
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	Cache-Control: no-store		Cache-Control: no-store
	{		{
	"access_token":"SlAV32hkKG ...		"access_token":"SlAV32hkKG ...
	(remainder of JWT omitted for brevity;		(remainder of JWT omitted for brevity;
	JWT contains JWK in the cnf claim)",		JWT contains JWK in the cnf claim)",
	"token_type":"pop",		"token_type":"pop",
	"expires_in":3600,		"expires_in":3600,
	"refresh_token":"8xLOxBtZp8",		"refresh_token":"8xLOxBtZp8",
	"key":"eyJhbGciOiJSU0ExXzUi ...		"cnf":{
	(remainder of plain JWK omitted for brevity)"		{"keys":
			[
			{"kty":"oct",
			"alg":"A128KW",
			"k":"GawgguFyGrWKav7AX4VKUg"
			}
			]
			}
			}
	}		}
	Figure 2: Example: Response from the Authorization Server (Symmetric		Figure 2: Example: Response from the Authorization Server (Symmetric
	Variant)		Variant)
	The content of the key parameter, which is a JWK in our example, is		Note that the cnf payload in Figure 2 is not encrypted at the
	shown in Figure 3.		application layer since Transport Layer Security is used between the
			AS and the client and the content of the cnf payload is consumed by
			the client itself. Alternatively, a JWE could be used to encrypt the
			key distribution, as shown in Figure 3.
	{		{
	"kty":"oct",		"access_token":"SlAV32hkKG ...
	"kid":"id123",		(remainder of JWT omitted for brevity;
	"alg":"HS256",		JWT contains JWK in the cnf claim)",
	"k":"ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE"		"token_type":"pop",
			"expires_in":3600,
			"refresh_token":"8xLOxBtZp8",
			"cnf":{
			"jwe":
			"eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ.
			(remainder of JWE omitted for brevity)"
			}
			}
	}		}
	Figure 3: Example: Key Transport to Client via a JWK		Figure 3: Example: Encrypted Symmmetric Key
	The content of the 'access_token' in JWT format contains the 'cnf'		The content of the 'access_token' in JWT format contains the 'cnf'
	(confirmation) claim, as shown in Figure 4. The confirmation claim		(confirmation) claim. The confirmation claim is defined in [10].
	is defined in [10]. The digital signature or the keyed message		The digital signature or the keyed message digest offering integrity
	digest offering integrity protection is not shown in this example but		protection is not shown in this example but has to be present in a
	MUST be present in a real deployment to mitigate a number of security		real deployment to mitigate a number of security threats.
	threats. Those security threats are described in [17].
	The JWK in the key element of the response from the authorization		The JWK in the key element of the response from the authorization
	server, as shown in Figure 2, contains the same session key as the		server, as shown in Figure 2, contains the same session key as the
	JWK inside the access token, as shown in Figure 4. It is, in this		JWK inside the access token, as shown in Figure 4. It is, in this
	example, protected by TLS and transmitted from the authorization		example, protected by TLS and transmitted from the authorization
	server to the client (for processing by the client).		server to the client (for processing by the client).
	{		{
	"iss": "https://server.example.com",		"iss": "https://server.example.com",
	"sub": "24400320",		"sub": "24400320",
	"aud": "s6BhdRkqt3",		"aud": "s6BhdRkqt3",
	"nonce": "n-0S6_WzA2Mj",		"nonce": "n-0S6_WzA2Mj",
	"exp": 1311281970,		"exp": 1311281970,
	"iat": 1311280970,		"iat": 1311280970,
	"cnf":{		"cnf":{
	"jwk":		"jwe":
	"JDLUhTMjU2IiwiY3R5Ijoi ...		"eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ.
	(remainder of JWK protected by JWE omitted for brevity)"		(remainder of JWE omitted for brevity)"
	}		}
	}		}
	Figure 4: Example: Access Token in JWT Format		Figure 4: Example: Access Token in JWT Format
	Note: When the JWK inside the access token contains a symmetric key		Note: When the JWK inside the access token contains a symmetric key
	it MUST be confidentiality protected using a JWE to maintain the		it must be confidentiality protected using a JWE to maintain the
	security goals of the PoP architecture, as described in [17] since		security goals of the PoP architecture since content is meant for
	content is meant for consumption by the selected resource server		consumption by the selected resource server only. The details are
	only.		described in [21].
	Note: This document does not impose requirements on the encoding of
	the access token. The examples used in this document make use of the
	JWT structure since this is the only standardized format.
	If the access token is only a reference then a look-up by the
	resource server is needed, as described in the token introspection
	specification [18].
	5. Asymmetric Key Transport
	5.1. Client-to-AS Request
	In case an asymmetric key shall be bound to an access token then the
	following procedure is applicable. In the request message from the
	OAuth client to the OAuth authorization server the request MAY
	include the following parameters:
	token_type: OPTIONAL. See Section 6 for more details.
	alg: OPTIONAL. See Section 6 for more details.
	key: OPTIONAL. This field contains information about the public key		4.2. Asymmetric Key Transport
	the client would like to bind to the access token in the JWK
	format. If the client does not provide a public key then the
	authorization server MUST create an ephemeral key pair
	(considering the information provided by the client) or
	alternatively respond with an error message. The client may
	also convey the fingerprint of the public key to the
	authorization server instead of passing the entire public key
	along (to conserve bandwidth). [11] defines a way to compute a
	thumbprint for a JWK and to embedd it within the JWK format.
	The 'token_type' and the 'alg' parameters are optional in the case		4.2.1. Client-to-AS Request
	where the authorization server has prior knowledge of the
	capabilities of the client otherwise these two parameters are
	required.
	For example, the client makes the following HTTP request using TLS		This example illustrates the case where an asymmetric key shall be
	(extra line breaks are for display purposes only) shown in Figure 5.		bound to an access token. The client makes the following HTTPS
			request shown in Figure 5. Extra line breaks are for display
			purposes only.
	POST /token HTTP/1.1		POST /token HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW		Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
	Content-Type: application/x-www-form-urlencoded;charset=UTF-8		Content-Type: application/x-www-form-urlencoded;charset=UTF-8
	grant_type=authorization_code		grant_type=authorization_code
	&code=SplxlOBeZQQYbYS6WxSbIA		&code=SplxlOBeZQQYbYS6WxSbIA
	&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb		&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
	&token_type=pop		&token_type=pop
	&alg=RS256		&req_cnf=eyJhbGciOiJSU0ExXzUi ...
	&key=eyJhbGciOiJSU0ExXzUi ...
	(remainder of JWK omitted for brevity)		(remainder of JWK omitted for brevity)
	Figure 5: Example Request to the Authorization Server (Asymmetric Key		Figure 5: Example Request to the Authorization Server (Asymmetric Key
	Variant)		Variant)
	As shown in Figure 6 the content of the 'key' parameter contains the		As shown in Figure 6 the content of the 'req_cnf' parameter contains
	RSA public key the client would like to associate with the access		the ECC public key the client would like to associate with the access
	token.		token (in JSON format).
	{"kty":"RSA",		"jwk":{
	"n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx		"kty": "EC",
	4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs		"use": "sig",
	tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2		"crv": "P-256",
	QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI		"x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
	SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb		"y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
	w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",		}
	"e":"AQAB",
	"alg":"RS256",
	"kid":"id123"}
	Figure 6: Client Providing Public Key to Authorization Server		Figure 6: Client Providing Public Key to Authorization Server
	5.2. Client-to-AS Response		4.2.2. Client-to-AS Response
	If the access token request is valid and authorized, the		If the access token request is valid and authorized, the
	authorization server issues an access token and optionally a refresh		authorization server issues an access token and optionally a refresh
	token. If the request client authentication failed or is invalid,		token. The authorization server also places information about the
	the authorization server returns an error response as described in		public key used by the client into the access token to create the
	Section 5.2 of [2].		binding between the two. The new token type "pop" is placed into the
	The authorization server also places information about the public key
	used by the client into the access token to create the binding
	between the two. The new token type "public_key" is placed into the
	'token_type' parameter.		'token_type' parameter.
	An example of a successful response is shown in Figure 7.		An example of a successful response is shown in Figure 7.
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json;charset=UTF-8		Content-Type: application/json;charset=UTF-8
	Cache-Control: no-store		Cache-Control: no-store
	Pragma: no-cache		Pragma: no-cache
	{		{
	"access_token":"2YotnFZFE....jr1zCsicMWpAA",		"access_token":"2YotnFZFE....jr1zCsicMWpAA",
	"token_type":"pop",		"token_type":"pop",
	"alg":"RS256",
	"expires_in":3600,		"expires_in":3600,
	"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"		"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
	}		}
	Figure 7: Example: Response from the Authorization Server (Asymmetric		Figure 7: Example: Response from the Authorization Server (Asymmetric
	Variant)		Variant)
	The content of the 'access_token' field contains an encoded JWT with		The content of the 'access_token' field contains an encoded JWT, as
	the following structure, as shown in Figure 8. The digital signature		shown in Figure 8. The digital signature covering the access token
	or the keyed message digest offering integrity protection is not		offering authenticity and integrity protection is not shown below
	shown (but must be present).		(but must be present).
	{		{
	"iss":"xas.example.com",		"iss":"xas.example.com",
	"aud":"http://auth.example.com",		"aud":"http://auth.example.com",
	"exp":"1361398824",		"exp":"1361398824",
	"nbf":"1360189224",		"nbf":"1360189224",
	"cnf":{		"cnf":{
	"jwk":{"kty":"RSA",		"jwk" : {
	"n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx		"kty" : "EC",
	4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs		"kid" : h'11',
	tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2		"crv" : "P-256",
	QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI		"x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
	SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb		"y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'
	w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",		}
	"e":"AQAB",
	"alg":"RS256",
	"kid":"id123"}
	}		}
	}		}
	Figure 8: Example: Access Token Structure (Asymmetric Variant)		Figure 8: Example: Access Token Structure (Asymmetric Variant)
	Note: In this example there is no need for the authorization server		Note: In this example there is no need for the authorization server
	to convey further keying material to the client since the client is		to convey further keying material to the client since the client is
	already in possession of the private RSA key.		already in possession of the private key (as well as the public key).
	6. Token Types and Algorithms
	To allow clients to indicate support for specific token types and
	respective algorithms they need to interact with authorization
	servers. They can either provide this information out-of-band, for
	example, via pre-configuration or up-front via the dynamic client
	registration protocol [16].
	The value in the 'alg' parameter together with value from the
	'token_type' parameter allow the client to indicate the supported
	algorithms for a given token type. The token type refers to the
	specification used by the client to interact with the resource server
	to demonstrate possession of the key. The 'alg' parameter provides
	further information about the algorithm, such as whether a symmetric
	or an asymmetric crypto-system is used. Hence, a client supporting a
	specific token type also knows how to populate the values to the
	'alg' parameter.
	The value for the 'token_type' MUST be taken from the 'OAuth Access
	Token Types' registry created by [2].
	This document does not register a new value for the OAuth Access
	Token Types registry nor does it define values to be used for the
	'alg' parameter since this is the responsibility of specifications
	defining the mechanism for clients interacting with resource servers.
	An example of such specification can be found in [19].
	The values in the 'alg' parameter are case-sensitive. If the client
	supports more than one algorithm then each individual value MUST be
	separated by a space.
	7. Security Considerations		5. Security Considerations
	[17] describes the architecture for the OAuth 2.0 proof-of-possession		[21] describes the architecture for the OAuth 2.0 proof-of-possession
	security architecture, including use cases, threats, and		security architecture, including use cases, threats, and
	requirements. This requirements describes one solution component of		requirements. This requirements describes one solution component of
	that architecture, namely the mechanism for the client to interact		that architecture, namely the mechanism for the client to interact
	with the authorization server to either obtain a symmetric key from		with the authorization server to either obtain a symmetric key from
	the authorization server, to obtain an asymmetric key pair, or to		the authorization server, to obtain an asymmetric key pair, or to
	offer a public key to the authorization. In any case, these keys are		offer a public key to the authorization. In any case, these keys are
	then bound to the access token by the authorization server.		then bound to the access token by the authorization server.
	To summarize the main security recommendations: A large range of		To summarize the main security recommendations: A large range of
	threats can be mitigated by protecting the contents of the access		threats can be mitigated by protecting the contents of the access
	skipping to change at page 14, line 27 ¶		skipping to change at page 12, line 35 ¶
	keying material is conveyed, for example, to a hardware security		keying material is conveyed, for example, to a hardware security
	module. Which version(s) of TLS ought to be implemented will vary		module. Which version(s) of TLS ought to be implemented will vary
	over time, and depend on the widespread deployment and known security		over time, and depend on the widespread deployment and known security
	vulnerabilities at the time of implementation. At the time of this		vulnerabilities at the time of implementation. At the time of this
	writing, TLS version 1.2 [4] is the most recent version. The client		writing, TLS version 1.2 [4] is the most recent version. The client
	MUST validate the TLS certificate chain when making requests to		MUST validate the TLS certificate chain when making requests to
	protected resources, including checking the validity of the		protected resources, including checking the validity of the
	certificate.		certificate.
	Similarly to the security recommendations for the bearer token		Similarly to the security recommendations for the bearer token
	specification [12] developers MUST ensure that the ephemeral		specification [16] developers MUST ensure that the ephemeral
	credentials (i.e., the private key or the session key) is not leaked		credentials (i.e., the private key or the session key) is not leaked
	to third parties. An adversary in possession of the ephemeral		to third parties. An adversary in possession of the ephemeral
	credentials bound to the access token will be able to impersonate the		credentials bound to the access token will be able to impersonate the
	client. Be aware that this is a real risk with many smart phone app		client. Be aware that this is a real risk with many smart phone app
	and Web development environments.		and Web development environments.
	Clients can at any time request a new proof-of-possession capable		Clients can at any time request a new proof-of-possession capable
	access token. Using a refresh token to regularly request new access		access token. Using a refresh token to regularly request new access
	tokens that are bound to fresh and unique keys is important. Keeping		tokens that are bound to fresh and unique keys is important. Keeping
	the lifetime of the access token short allows the authorization		the lifetime of the access token short allows the authorization
	server to use shorter key sizes, which translate to a performance		server to use shorter key sizes, which translate to a performance
	benefit for the client and for the resource server. Shorter keys		benefit for the client and for the resource server. Shorter keys
	also lead to shorter messages (particularly with asymmetric keying		also lead to shorter messages (particularly with asymmetric keying
	material).		material).
	When authorization servers bind symmetric keys to access tokens then		When authorization servers bind symmetric keys to access tokens then
	they SHOULD scope these access tokens to a specific permissions.		they SHOULD scope these access tokens to a specific permissions.
	8. IANA Considerations		6. IANA Considerations
	This specification registers the following parameters in the OAuth
	Parameters Registry established by [2].
	Parameter name: alg
	Parameter usage location: token request, token response,
	authorization response
	Change controller: IETF
	Specification document(s): [[ this document ]]
	Related information: None		6.1. OAuth Access Token Types
	Parameter name: key		This specification registers the following error in the IANA "OAuth
			Access Token Types" [24] established by [16].
	Parameter usage location: token request, token response,		o Name: pop
	authorization response		o Change controller: IESG
			o Specification document(s): [[ this specification ]]
	Change controller: IETF		6.2. OAuth Parameters Registration
	Specification document(s): [[ this document ]]		This specification registers the following value in the IANA "OAuth
			Parameters" registry [24] established by [2].
	Related information: None		o Parameter name: cnf_req
			o Parameter usage location: authorization request, token request
			o Change controller: IESG
			o Specification document(s): [[ this specification ]]
	Parameter name: aud		o Parameter name: cnf
			o Parameter usage location: authorization response, token response
			o Change controller: IESG
			o Specification document(s): [[ this specification ]]
	Parameter usage location: token request		o Parameter name: rs_cnf
			o Parameter usage location: token response
			o Change controller: IESG
			o Specification document(s): [[ this specification ]]
	Change controller: IETF		6.3. OAuth Extensions Error Registration
	Specification document(s): [[This document.]		This specification registers the following error in the IANA "OAuth
			Extensions Error Registry" [24] established by [2].
	Related information: None		o Error name: invalid_token_type
			o Error usage location: implicit grant error response, token error
			response
			o Related protocol extension: token_type parameter
			o Change controller: IESG
			o Specification document(s): [[ this specification ]]
	9. Acknowledgements		7. Acknowledgements
	We would like to thank Chuck Mortimore for his review comments.		We would like to thank Chuck Mortimore for his review comments.
	10. References		8. References
	10.1. Normative References		8.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate		[1] 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,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[2] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",		[2] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
	RFC 6749, DOI 10.17487/RFC6749, October 2012,		RFC 6749, DOI 10.17487/RFC6749, October 2012,
	<http://www.rfc-editor.org/info/rfc6749>.		<https://www.rfc-editor.org/info/rfc6749>.
	[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<http://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	[4] Dierks, T. and E. Rescorla, "The Transport Layer Security		[4] 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,
	<http://www.rfc-editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.
	[5] Jones, M., "JSON Web Key (JWK)", RFC 7517,		[5] Jones, M., "JSON Web Key (JWK)", RFC 7517,
	DOI 10.17487/RFC7517, May 2015,		DOI 10.17487/RFC7517, May 2015,
	<http://www.rfc-editor.org/info/rfc7517>.		<https://www.rfc-editor.org/info/rfc7517>.
	[6] Jones, M., Bradley, J., and N. Sakimura, "JSON Web		[6] 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, <http://www.rfc-editor.org/info/rfc7515>.		2015, <https://www.rfc-editor.org/info/rfc7515>.
	[7] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,		[7] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
	DOI 10.17487/RFC7518, May 2015,		DOI 10.17487/RFC7518, May 2015,
	<http://www.rfc-editor.org/info/rfc7518>.		<https://www.rfc-editor.org/info/rfc7518>.
	[8] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",		[8] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
	RFC 7516, DOI 10.17487/RFC7516, May 2015,		RFC 7516, DOI 10.17487/RFC7516, May 2015,
	<http://www.rfc-editor.org/info/rfc7516>.		<https://www.rfc-editor.org/info/rfc7516>.
	[9] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[9] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<http://www.rfc-editor.org/info/rfc7519>.		<https://www.rfc-editor.org/info/rfc7519>.
	[10] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-		[10] 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,
	<http://www.rfc-editor.org/info/rfc7800>.		<https://www.rfc-editor.org/info/rfc7800>.
	[11] Jones, M. and N. Sakimura, "JSON Web Key (JWK)		[11] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
	Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September		Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
	2015, <http://www.rfc-editor.org/info/rfc7638>.		2015, <https://www.rfc-editor.org/info/rfc7638>.
	10.2. Informative References		[12] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
			Tschofenig, "Proof-of-Possession Key Semantics for CBOR
			Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
			possession-03 (work in progress), June 2018.
	[12] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization		[13] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
			"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
			May 2018, <https://www.rfc-editor.org/info/rfc8392>.
			[14] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
			RFC 8152, DOI 10.17487/RFC8152, July 2017,
			<https://www.rfc-editor.org/info/rfc8152>.
			[15] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
			Indicators for OAuth 2.0", draft-ietf-oauth-resource-
			indicators-01 (work in progress), October 2018.
			8.2. Informative References
			[16] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
	Framework: Bearer Token Usage", RFC 6750,		Framework: Bearer Token Usage", RFC 6750,
	DOI 10.17487/RFC6750, October 2012,		DOI 10.17487/RFC6750, October 2012,
	<http://www.rfc-editor.org/info/rfc6750>.		<https://www.rfc-editor.org/info/rfc6750>.
	[13] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[17] 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,
	<http://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
	[14] Campbell, B., Mortimore, C., Jones, M., and Y. Goland,		[18] Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
	"Assertion Framework for OAuth 2.0 Client Authentication		"Assertion Framework for OAuth 2.0 Client Authentication
	and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521,		and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521,
	May 2015, <http://www.rfc-editor.org/info/rfc7521>.		May 2015, <https://www.rfc-editor.org/info/rfc7521>.
	[15] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key		[19] 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,
	<http://www.rfc-editor.org/info/rfc7636>.		<https://www.rfc-editor.org/info/rfc7636>.
	[16] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and		[20] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
	P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",		P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
	RFC 7591, DOI 10.17487/RFC7591, July 2015,		RFC 7591, DOI 10.17487/RFC7591, July 2015,
	<http://www.rfc-editor.org/info/rfc7591>.		<https://www.rfc-editor.org/info/rfc7591>.
	[17] Hunt, P., Richer, J., Mills, W., Mishra, P., and H.		[21] Hunt, P., Richer, J., Mills, W., Mishra, P., and H.
	Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security		Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security
	Architecture", draft-ietf-oauth-pop-architecture-08 (work		Architecture", draft-ietf-oauth-pop-architecture-08 (work
	in progress), July 2016.		in progress), July 2016.
	[18] Richer, J., Ed., "OAuth 2.0 Token Introspection",		[22] Richer, J., Ed., "OAuth 2.0 Token Introspection",
	RFC 7662, DOI 10.17487/RFC7662, October 2015,		RFC 7662, DOI 10.17487/RFC7662, October 2015,
	<http://www.rfc-editor.org/info/rfc7662>.		<https://www.rfc-editor.org/info/rfc7662>.
	[19] Richer, J., Bradley, J., and H. Tschofenig, "A Method for
	Signing HTTP Requests for OAuth", draft-ietf-oauth-signed-
	http-request-03 (work in progress), August 2016.
	Appendix A. Augmented Backus-Naur Form (ABNF) Syntax
	This section provides Augmented Backus-Naur Form (ABNF) syntax
	descriptions for the elements defined in this specification using the
	notation of [13].
	A.1. 'aud' Syntax
	The ABNF syntax is defined as follows where by the "URI-reference"
	definition is taken from [3]:
	aud = URI-reference
	A.2. 'key' Syntax
	The "key" element is defined in Section 4 and Section 5:
	key = 1*VSCHAR
	A.3. 'alg' Syntax
	The "alg" element is defined in Section 6:		[23] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
			H. Tschofenig, "Authentication and Authorization for
			Constrained Environments (ACE) using the OAuth 2.0
			Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-16
			(work in progress), October 2018.
	alg = alg-token *( SP alg-token )		[24] IANA, "OAuth Parameters", October 2018.
	alg-token = 1*NQCHAR		[25] IANA, "JSON Web Token Claims", June 2018.
	Authors' Addresses		Authors' Addresses
	John Bradley		John Bradley
	Ping Identity		Ping Identity
	Email: ve7jtb@ve7jtb.com		Email: ve7jtb@ve7jtb.com
	URI: http://www.thread-safe.com/		URI: http://www.thread-safe.com/
	Phil Hunt		Phil Hunt
	skipping to change at page 18, line 38 ¶		skipping to change at page 17, line 4 ¶
	Oracle Corporation		Oracle Corporation
	Email: phil.hunt@yahoo.com		Email: phil.hunt@yahoo.com
	URI: http://www.indepdentid.com		URI: http://www.indepdentid.com
	Michael B. Jones		Michael B. Jones
	Microsoft		Microsoft
	Email: mbj@microsoft.com		Email: mbj@microsoft.com
	URI: http://self-issued.info/		URI: http://self-issued.info/
	Hannes Tschofenig		Hannes Tschofenig
	ARM Limited		Arm Ltd.
			Absam 6067
	Austria		Austria
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
			Meszaros Mihaly
			NIIF Institute
			Hungary
			Email: misi@niif.hu
End of changes. 109 change blocks.
	405 lines changed or deleted		285 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/