< draft-ietf-oauth-pop-key-distribution-04.txt		draft-ietf-oauth-pop-key-distribution-05.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: April 26, 2019 Oracle Corporation		Expires: September 12, 2019 Oracle Corporation
	M. Jones		M. Jones
	Microsoft		Microsoft
	H. Tschofenig		H. Tschofenig
	Arm Ltd.		Arm Ltd.
	M. Mihaly		M. Meszaros
	NIIF Institute		GITDA
	October 23, 2018		March 11, 2019
	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-04		draft-ietf-oauth-pop-key-distribution-05
	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 requests and obtains a PoP
			access token from the authorization server for use with HTTPS-based
			transport. Alternative transports, for example using the Constrained
			Application Protocol (CoAP), have been specified in companion
			specifications.
	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 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 September 12, 2019.
	This Internet-Draft will expire on April 26, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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. Processing Instructions . . . . . . . . . . . . . . . . . . . 4		3. Processing Instructions . . . . . . . . . . . . . . . . . . . 4
	4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Symmetric Key Transport . . . . . . . . . . . . . . . . . 5		4.1. Symmetric Key Transport . . . . . . . . . . . . . . . . . 5
	4.1.1. Client-to-AS Request . . . . . . . . . . . . . . . . 5		4.1.1. Client-to-AS Request . . . . . . . . . . . . . . . . 5
	4.1.2. Client-to-AS Response . . . . . . . . . . . . . . . . 6		4.1.2. Client-to-AS Response . . . . . . . . . . . . . . . . 5
	4.2. Asymmetric Key Transport . . . . . . . . . . . . . . . . 9		4.2. Asymmetric Key Transport . . . . . . . . . . . . . . . . 8
	4.2.1. Client-to-AS Request . . . . . . . . . . . . . . . . 9		4.2.1. Client-to-AS Request . . . . . . . . . . . . . . . . 8
	4.2.2. Client-to-AS Response . . . . . . . . . . . . . . . . 10		4.2.2. Client-to-AS Response . . . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	6.1. OAuth Access Token Types . . . . . . . . . . . . . . . . 13		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	6.2. OAuth Parameters Registration . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.3. OAuth Extensions Error Registration . . . . . . . . . . . 13		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		8.2. Informative References . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	8.1. Normative References . . . . . . . . . . . . . . . . . . 14
	8.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	The work on proof-of-possession tokens, an extended token security		The work on proof-of-possession tokens, an extended token security
	mechanisms for OAuth 2.0, is motivated in [21]. This document		mechanisms for OAuth 2.0, is motivated in [21]. This document
	defines the ability for the client request and to obtain PoP tokens		defines the ability for the client request and to obtain PoP tokens
	from the authorization server. After successfully completing the		from the authorization server. After successfully completing the
	exchange the client is in possession of a PoP token and the keying		exchange the client is in possession of a PoP token and the keying
	material bound to it. Clients that access protected resources then		material bound to it. Clients that access protected resources then
	need to demonstrate knowledge of the secret key that is bound to the		need to demonstrate knowledge of the secret key that is bound to the
	skipping to change at page 3, line 20 ¶		skipping to change at page 3, line 20 ¶
	this document are used.		this document are used.
	+--------+ +---------------+		+--------+ +---------------+
	| |--(A)- Authorization Request ->| Resource |		| |--(A)- Authorization Request ->| Resource |
	| | | Owner |		| | | Owner |
	| |<-(B)-- Authorization Grant ---| |		| |<-(B)-- Authorization Grant ---| |
	| | +---------------+		| | +---------------+
	| |		| |
	| | +---------------+		| | +---------------+
	| |--(C)-- Authorization Grant -->| |		| |--(C)-- Authorization Grant -->| |
	| Client | (resource, req_cnf) | Authorization |		| Client | (aud, cnf) | Authorization |
	| | | Server |		| | | Server |
	| |<-(D)-- PoP Access Token ------| |		| |<-(D)-- PoP Access Token ------| |
	| | (rs_cnf, token_type) +---------------+		| | (profile, cnf, rs_cnf, +---------------+
	| |		| | token_type)
	| | +---------------+		| | +---------------+
	| |--(E)-- PoP Access Token ----->| |		| |--(E)-- PoP Access Token ----->| |
	| | (with proof of private key) | Resource |		| | (with proof of private key) | Resource |
	| | | Server |		| | | Server |
	| |<-(F)--- Protected Resource ---| |		| |<-(F)--- Protected Resource ---| |
	+--------+ +---------------+		+--------+ +---------------+
	Figure 1: Augmented 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 [18]		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 specification extends the functionality of the token endpoint,		This document extends the functionality of the token endpoint, i.e.,
	i.e., the protocol exchange between the client and the authorization		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.1		the authorization server to the client is described in Section 4.1
	and the procedure for dealing with asymmetric keys is described in		and the procedure for dealing with asymmetric keys is described in
	Section 4.2.		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:
	In the context of this specification 'session key' refers to fresh		In the context of this specification 'session key' refers to fresh
	and unique keying material established between the client and the		and unique keying material established between the client and the
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 31 ¶
	JWA: JSON Web Algorithms[7]		JWA: JSON Web Algorithms[7]
	JWT: JSON Web Token[9]		JWT: JSON Web Token[9]
	JWS: JSON Web Signature[6]		JWS: JSON Web Signature[6]
	JWK: JSON Web Key[5]		JWK: JSON Web Key[5]
	JWE: JSON Web Encryption[8]		JWE: JSON Web Encryption[8]
	CWT: CBOR Web Token[13]		CWT: CBOR Web Token[14]
	COSE: CBOR Object Signing and Encryption[14]		COSE: CBOR Object Signing and Encryption[15]
	3. 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 use the resource identicator		obtain an access token it MUST follow the processing steps for the
	defined in [15] when symmetric PoP tokens are used. For		HTTPS-based transport described in Section 5.6.1 of [12]. This
	asymmetric PoP tokens the use of resource indicators is optional		includes determining whether to use the 'aud' and the 'cnf'
	but recommended.		parameters.
	Step (2): The authorization server parses the request from the
	server and determines the suitable response based on OAuth 2.0 and
	the PoP token credential procedures.
	Note that PoP access tokens may be encoded in a variety of ways:
	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].
	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].
	If the access token is only a reference then a look-up by the		Step (3): The authorization server parses the request from the
	resource server is needed, as described in the token introspection		server and determines the suitable response based on the
	specification [22].		description in Section 5.6.2 of [12]. In case of an error the
			procedure in Section 5.6.3 of [12] is applicable.
	Note that the OAuth 2.0 framework nor this specification does not		Note that PoP access tokens may be encoded in a variety of ways. In
	mandate a specific PoP token format but using a standardized format		case the access token is encoded using the JSON Web Token (JWT)
	will improve interoperability and will lead to better code re-use.		format [9] it 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]. [14] defines an alternative
			token format based on CBOR. The proof-of-possession token
			functionality is defined in [13]. Finally, access tokens can also be
			passed by reference, which then requires the token introspection
			endpoint (or a similiar, proprietary protocol mechanism) to be used.
			This specification does not mandate a specific PoP token format.
	Application layer interactions between the client and the resource		Subsequent steps for the interaction between the client and the
	server are beyond the scope of this document.		resource server are beyond the scope of this document.
	4. Examples		4. Examples
	This section provides a number of examples.		This section provides a number of examples.
	4.1. Symmetric Key Transport		4.1. Symmetric Key Transport
	4.1.1. Client-to-AS Request		4.1.1. Client-to-AS Request
	The client starts with a request to the authorization server		The client starts with a request to the authorization server
	indicating that it is interested to obtain a token for		indicating that it is interested to obtain a token for example-
	https://www.example.com		server.
	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
	&resource=https://www.example.com		&aud=example-server
	Example Request to the Authorization Server		Example Request to the Authorization Server
	4.1.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.		issues an access token and optionally a refresh token.
	Figure 2 shows a response containing a token and a "cnf" parameter		Figure 2 shows a response containing a token and a "cnf" parameter
	with a symmetric proof-of-possession key both encoded in a JSON-based		with a symmetric proof-of-possession key.
	serialization format. The "cnf" parameter contains the RFC 7517 [5]
	encoded key element.
	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",
	"cnf":{		"cnf":{
	{"keys":		"keys" : {
	[		"kty" : "Symmetric",
	{"kty":"oct",		"kid" : b64'39Gqlw',
	"alg":"A128KW",		"k" : b64'hJtXhkV8FJG+Onbc6mxCcQh'
	"k":"GawgguFyGrWKav7AX4VKUg"		}
	}		}
	]
	}
	}
	}		}
	Figure 2: Example: Response from the Authorization Server (Symmetric		Figure 2: Example: Response from the Authorization Server (Symmetric
	Variant)		Variant)
	Note that the cnf payload in Figure 2 is not encrypted at the		Note that the cnf payload in Figure 2 is not encrypted at the
	application layer since Transport Layer Security is used between the		application layer since Transport Layer Security is used between the
	AS and the client and the content of the cnf payload is consumed by		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		the client itself. Alternatively, a JWE could be used to encrypt the
	key distribution, as shown in Figure 3.		key distribution, as shown in Figure 3.
	skipping to change at page 8, line 17 ¶		skipping to change at page 7, line 17 ¶
	(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",
	"cnf":{		"cnf":{
	"jwe":		"jwe":
	"eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ.		"eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ.
	(remainder of JWE omitted for brevity)"		(remainder of JWE omitted for brevity)"
	}		}
	}		}
	}		}
	Figure 3: Example: Encrypted Symmmetric Key		Figure 3: Example: Encrypted Symmmetric Key
			The content of the key parameter, which is a JWK in our example, is
			shown in Figure 4.
			{
			"kty":"oct",
			"kid":"id123",
			"alg":"HS256",
			"k":"ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE"
			}
			Figure 4: Example: Key Transport to Client via a JWK
	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. The confirmation claim is defined in [10].		(confirmation) claim, as shown in Figure 5. The confirmation claim
	The digital signature or the keyed message digest offering integrity		is defined in [10]. The digital signature or the keyed message
	protection is not shown in this example but has to be present in a		digest offering integrity protection is not shown in this example but
	real deployment to mitigate a number of security threats.		has to be present in a real deployment to mitigate a number of
			security threats.
	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 5. 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":{
	"jwe":		"jwk":
	"eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ.		"JDLUhTMjU2IiwiY3R5Ijoi ...
	(remainder of JWE omitted for brevity)"		(remainder of JWK protected by JWE omitted for brevity)"
	}		}
	}		}
	Figure 4: Example: Access Token in JWT Format		Figure 5: 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 since content is meant for		security goals of the PoP architecture, as described in [21] since
	consumption by the selected resource server only. The details are		content is meant for consumption by the selected resource server
	described in [21].		only.
			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 but the CWT format is an equally appropriate format to
			use.
			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 [22].
	4.2. Asymmetric Key Transport		4.2. Asymmetric Key Transport
	4.2.1. Client-to-AS Request		4.2.1. Client-to-AS Request
	This example illustrates the case where an asymmetric key shall be		This example illustrates the case where an asymmetric key shall be
	bound to an access token. The client makes the following HTTPS		bound to an access token. The client makes the following HTTPS
	request shown in Figure 5. Extra line breaks are for display		request shown in Figure 6. Extra line breaks are for display
	purposes only.		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
	&req_cnf=eyJhbGciOiJSU0ExXzUi ...		&cnf=eyJhbGciOiJSU0ExXzUi ...
	(remainder of JWK omitted for brevity)		(remainder of JWK omitted for brevity)
	Figure 5: Example Request to the Authorization Server (Asymmetric Key		Figure 6: Example Request to the Authorization Server (Asymmetric Key
	Variant)		Variant)
	As shown in Figure 6 the content of the 'req_cnf' parameter contains		As shown in Figure 7 the content of the 'cnf' parameter contains the
	the ECC public key the client would like to associate with the access		ECC public key the client would like to associate with the access
	token (in JSON format).		token.
	"jwk":{		"jwk":{
	"kty": "EC",		"kty": "EC",
	"use": "sig",		"use": "sig",
	"crv": "P-256",		"crv": "P-256",
	"x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",		"x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
	"y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"		"y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
	}		}
	Figure 6: Client Providing Public Key to Authorization Server		Figure 7: Client Providing Public Key to Authorization Server
	4.2.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. The authorization server also places information about the		token. The authorization server also places information about the
	public key used by the client into the access token to create the		public key used by the client into the access token to create the
	binding between the two. The new token type "pop" is placed into the		binding between the two. The new token type "public_key" is placed
	'token_type' parameter.		into the 'token_type' parameter.
	An example of a successful response is shown in Figure 7.		An example of a successful response is shown in Figure 8.
	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",
	"expires_in":3600,		"expires_in":3600,
	"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"		"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
	}		}
	Figure 7: Example: Response from the Authorization Server (Asymmetric		Figure 8: Example: Response from the Authorization Server (Asymmetric
	Variant)		Variant)
	The content of the 'access_token' field contains an encoded JWT, as		The content of the 'access_token' field contains an encoded JWT, as
	shown in Figure 8. The digital signature covering the access token		shown in Figure 9. The digital signature covering the access token
	offering authenticity and integrity protection is not shown below		offering authenticity and integrity protection is not shown below
	(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" : {		"jwk" : {
	"kty" : "EC",		"kty" : "EC",
	"kid" : h'11',		"kid" : h'11',
	"crv" : "P-256",		"crv" : "P-256",
	"x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',		"x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
	"y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'		"y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'
	}		}
	}		}
	}		}
	Figure 8: Example: Access Token Structure (Asymmetric Variant)		Figure 9: 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 key (as well as the public key).		already in possession of the private key.
	5. Security Considerations		5. Security Considerations
	[21] 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
	skipping to change at page 13, line 10 ¶		skipping to change at page 12, line 29 ¶
	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.
	6. IANA Considerations		6. IANA Considerations
	6.1. OAuth Access Token Types		This document does not require any actions by IANA.
	This specification registers the following error in the IANA "OAuth
	Access Token Types" [24] established by [16].
	o Name: pop
	o Change controller: IESG
	o Specification document(s): [[ this specification ]]
	6.2. OAuth Parameters Registration
	This specification registers the following value in the IANA "OAuth
	Parameters" registry [24] established by [2].
	o Parameter name: cnf_req
	o Parameter usage location: authorization request, token request
	o Change controller: IESG
	o Specification document(s): [[ this specification ]]
	o Parameter name: cnf
	o Parameter usage location: authorization response, token response
	o Change controller: IESG
	o Specification document(s): [[ this specification ]]
	o Parameter name: rs_cnf
	o Parameter usage location: token response
	o Change controller: IESG
	o Specification document(s): [[ this specification ]]
	6.3. OAuth Extensions Error Registration
	This specification registers the following error in the IANA "OAuth
	Extensions Error Registry" [24] established by [2].
	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 ]]
	7. 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.
	8. References		8. References
	8.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
	skipping to change at page 15, line 14 ¶		skipping to change at page 13, line 39 ¶
	[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,
	<https://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, <https://www.rfc-editor.org/info/rfc7638>.		2015, <https://www.rfc-editor.org/info/rfc7638>.
	[12] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.		[12] 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-22
			(work in progress), March 2019.
			[13] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
	Tschofenig, "Proof-of-Possession Key Semantics for CBOR		Tschofenig, "Proof-of-Possession Key Semantics for CBOR
	Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-		Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
	possession-03 (work in progress), June 2018.		possession-06 (work in progress), February 2019.
	[13] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,		[14] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
	"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,		"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
	May 2018, <https://www.rfc-editor.org/info/rfc8392>.		May 2018, <https://www.rfc-editor.org/info/rfc8392>.
	[14] Schaad, J., "CBOR Object Signing and Encryption (COSE)",		[15] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	RFC 8152, DOI 10.17487/RFC8152, July 2017,		RFC 8152, DOI 10.17487/RFC8152, July 2017,
	<https://www.rfc-editor.org/info/rfc8152>.		<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		8.2. Informative References
	[16] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization		[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,
	<https://www.rfc-editor.org/info/rfc6750>.		<https://www.rfc-editor.org/info/rfc6750>.
	[17] 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,
	skipping to change at page 16, line 19 ¶		skipping to change at page 14, line 45 ¶
	[21] 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.
	[22] 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,
	<https://www.rfc-editor.org/info/rfc7662>.		<https://www.rfc-editor.org/info/rfc7662>.
	[23] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and		[23] IANA, "JSON Web Token Claims", March 2019.
	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.
	[24] IANA, "OAuth Parameters", October 2018.
	[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
	Oracle Corporation		Oracle Corporation
	Email: phil.hunt@yahoo.com		Email: phil.hunt@yahoo.com
	skipping to change at page 17, line 4 ¶		skipping to change at page 15, line 21 ¶
	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 Ltd.		Arm Ltd.
	Absam 6067		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		Mihaly Meszaros
	NIIF Institute		GITDA
			Debrecen 4033
	Hungary		Hungary
	Email: misi@niif.hu		Email: bakfitty@gmail.com
			URI: https://github.com/misi
End of changes. 50 change blocks.
	167 lines changed or deleted		127 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/