< draft-ietf-ace-oauth-authz-14.txt		draft-ietf-ace-oauth-authz-15.txt >
	ACE Working Group L. Seitz		ACE Working Group L. Seitz
	Internet-Draft RISE SICS		Internet-Draft RISE
	Intended status: Standards Track G. Selander		Intended status: Standards Track G. Selander
	Expires: March 23, 2019 Ericsson		Expires: March 31, 2019 Ericsson
	E. Wahlstroem		E. Wahlstroem
	S. Erdtman		S. Erdtman
	Spotify AB		Spotify AB
	H. Tschofenig		H. Tschofenig
	Arm Ltd.		Arm Ltd.
	September 19, 2018		September 27, 2018
	Authentication and Authorization for Constrained Environments (ACE)		Authentication and Authorization for Constrained Environments (ACE)
	using the OAuth 2.0 Framework (ACE-OAuth)		using the OAuth 2.0 Framework (ACE-OAuth)
	draft-ietf-ace-oauth-authz-14		draft-ietf-ace-oauth-authz-15
	Abstract		Abstract
	This specification defines a framework for authentication and		This specification defines a framework for authentication and
	authorization in Internet of Things (IoT) environments called ACE-		authorization in Internet of Things (IoT) environments called ACE-
	OAuth. The framework is based on a set of building blocks including		OAuth. The framework is based on a set of building blocks including
	OAuth 2.0 and CoAP, thus making a well-known and widely used		OAuth 2.0 and CoAP, thus making a well-known and widely used
	authorization solution suitable for IoT devices. Existing		authorization solution suitable for IoT devices. Existing
	specifications are used where possible, but where the constraints of		specifications are used where possible, but where the constraints of
	IoT devices require it, extensions are added and profiles are		IoT devices require it, extensions are added and profiles are
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 http://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 March 23, 2019.		This Internet-Draft will expire on March 31, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10		4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10
	5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.1. Discovering Authorization Servers . . . . . . . . . . . . 15		5.1. Discovering Authorization Servers . . . . . . . . . . . . 15
	5.1.1. Unauthorized Resource Request Message . . . . . . . . 15		5.1.1. Unauthorized Resource Request Message . . . . . . . . 15
	5.1.2. AS Information . . . . . . . . . . . . . . . . . . . 16		5.1.2. AS Information . . . . . . . . . . . . . . . . . . . 16
	5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 17		5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 17
	5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 18		5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 18
	5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 18		5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 18
	5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 18		5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 18
	5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 19		5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 19
	5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 19		5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 19
	5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 22		5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 22
	5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 24		5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 24
	5.6.4. Request and Response Parameters . . . . . . . . . . . 25		5.6.4. Request and Response Parameters . . . . . . . . . . . 25
	5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 25		5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 25
	5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 26		5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 26
	5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 26		5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 26
	5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 26		5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 26
	5.7. The 'Introspect' Endpoint . . . . . . . . . . . . . . . . 27		5.7. The Introspection Endpoint . . . . . . . . . . . . . . . 27
	5.7.1. RS-to-AS Request . . . . . . . . . . . . . . . . . . 28		5.7.1. Introspection Request . . . . . . . . . . . . . . . . 28
	5.7.2. AS-to-RS Response . . . . . . . . . . . . . . . . . . 28		5.7.2. Introspection Response . . . . . . . . . . . . . . . 28
	5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 29		5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 29
	5.7.4. Mapping Introspection parameters to CBOR . . . . . . 30		5.7.4. Mapping Introspection parameters to CBOR . . . . . . 30
	5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 31		5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 31
	5.8.1. The 'Authorization Information' Endpoint . . . . . . 31		5.8.1. The Authorization Information Endpoint . . . . . . . 31
	5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 32		5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 32
	5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 33		5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 33
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 34		6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
	6.1. Unprotected AS Information . . . . . . . . . . . . . . . 35		6.1. Unprotected AS Information . . . . . . . . . . . . . . . 35
	6.2. Use of Nonces for Replay Protection . . . . . . . . . . . 35		6.2. Use of Nonces for Replay Protection . . . . . . . . . . . 35
	6.3. Combining profiles . . . . . . . . . . . . . . . . . . . 35		6.3. Combining profiles . . . . . . . . . . . . . . . . . . . 35
	6.4. Error responses . . . . . . . . . . . . . . . . . . . . . 36		6.4. Error responses . . . . . . . . . . . . . . . . . . . . . 36
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
	8.1. Authorization Server Information . . . . . . . . . . . . 37		8.1. Authorization Server Information . . . . . . . . . . . . 37
	skipping to change at page 3, line 26 ¶		skipping to change at page 3, line 26 ¶
	8.5. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 39		8.5. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 39
	8.5.1. Initial Registry Contents . . . . . . . . . . . . . . 39		8.5.1. Initial Registry Contents . . . . . . . . . . . . . . 39
	8.6. ACE Profile Registry . . . . . . . . . . . . . . . . . . 39		8.6. ACE Profile Registry . . . . . . . . . . . . . . . . . . 39
	8.7. OAuth Parameter Registration . . . . . . . . . . . . . . 40		8.7. OAuth Parameter Registration . . . . . . . . . . . . . . 40
	8.8. OAuth CBOR Parameter Mappings Registry . . . . . . . . . 40		8.8. OAuth CBOR Parameter Mappings Registry . . . . . . . . . 40
	8.9. OAuth Introspection Response Parameter Registration . . . 41		8.9. OAuth Introspection Response Parameter Registration . . . 41
	8.10. Introspection Endpoint CBOR Mappings Registry . . . . . . 41		8.10. Introspection Endpoint CBOR Mappings Registry . . . . . . 41
	8.11. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 42		8.11. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 42
	8.12. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 42		8.12. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 42
	8.13. Media Type Registrations . . . . . . . . . . . . . . . . 43		8.13. Media Type Registrations . . . . . . . . . . . . . . . . 43
	8.13.1. Media Type Registration . . . . . . . . . . . . . . 43
	8.14. CoAP Content-Format Registry . . . . . . . . . . . . . . 44		8.14. CoAP Content-Format Registry . . . . . . . . . . . . . . 44
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
	10.1. Normative References . . . . . . . . . . . . . . . . . . 44		10.1. Normative References . . . . . . . . . . . . . . . . . . 44
	10.2. Informative References . . . . . . . . . . . . . . . . . 46		10.2. Informative References . . . . . . . . . . . . . . . . . 46
	Appendix A. Design Justification . . . . . . . . . . . . . . . . 49		Appendix A. Design Justification . . . . . . . . . . . . . . . . 49
	Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 52		Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 52
	Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 54		Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 54
	Appendix D. Assumptions on AS knowledge about C and RS . . . . . 55		Appendix D. Assumptions on AS knowledge about C and RS . . . . . 55
	Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 55		Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 55
	E.1. Local Token Validation . . . . . . . . . . . . . . . . . 56		E.1. Local Token Validation . . . . . . . . . . . . . . . . . 56
	E.2. Introspection Aided Token Validation . . . . . . . . . . 60		E.2. Introspection Aided Token Validation . . . . . . . . . . 60
	Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 64		Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 64
	F.1. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 64		F.1. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 64
	F.2. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 64		F.2. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 64
	F.3. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 65		F.3. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 65
	F.4. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 65		F.4. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 65
	F.5. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 65		F.5. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 65
	F.6. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 65		F.6. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 65
	F.7. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 65		F.7. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 65
	F.8. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 66		F.8. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 66
	F.9. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 66		F.9. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 66
	F.10. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 66		F.10. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 66
	F.11. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 67		F.11. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 66
	F.12. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 67		F.12. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 67
	F.13. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 67		F.13. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 67
	F.14. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 68		F.14. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 67
			F.15. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 68
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68
	1. Introduction		1. Introduction
	Authorization is the process for granting approval to an entity to		Authorization is the process for granting approval to an entity to
	access a resource [RFC4949]. The authorization task itself can best		access a resource [RFC4949]. The authorization task itself can best
	be described as granting access to a requesting client, for a		be described as granting access to a requesting client, for a
	resource hosted on a device, the resource server (RS). This exchange		resource hosted on a device, the resource server (RS). This exchange
	is mediated by one or multiple authorization servers (AS). Managing		is mediated by one or multiple authorization servers (AS). Managing
	authorization for a large number of devices and users can be a		authorization for a large number of devices and users can be a
	skipping to change at page 7, line 34 ¶		skipping to change at page 7, line 34 ¶
	Access tokens are credentials needed to access protected		Access tokens are credentials needed to access protected
	resources. An access token is a data structure representing		resources. An access token is a data structure representing
	authorization permissions issued by the AS to the client. Access		authorization permissions issued by the AS to the client. Access
	tokens are generated by the AS and consumed by the RS. The access		tokens are generated by the AS and consumed by the RS. The access
	token content is opaque to the client.		token content is opaque to the client.
	Access tokens can have different formats, and various methods of		Access tokens can have different formats, and various methods of
	utilization (e.g., cryptographic properties) based on the security		utilization (e.g., cryptographic properties) based on the security
	requirements of the given deployment.		requirements of the given deployment.
			Refresh Tokens:
			Refresh tokens are credentials used to obtain access tokens.
			Refresh tokens are issued to the client by the authorization
			server and are used to obtain a new access token when the current
			access token becomes invalid or expires, or to obtain additional
			access tokens with identical or narrower scope (access tokens may
			have a shorter lifetime and fewer permissions than authorized by
			the resource owner). Issuing a refresh token is optional at the
			discretion of the authorization server. If the authorization
			server issues a refresh token, it is included when issuing an
			access token (i.e., step (B) in Figure 1).
			A refresh token is a string representing the authorization granted
			to the client by the resource owner. The string is usually opaque
			to the client. The token denotes an identifier used to retrieve
			the authorization information. Unlike access tokens, refresh
			tokens are intended for use only with authorization servers and
			are never sent to resource servers.
	Proof of Possession Tokens:		Proof of Possession Tokens:
	An access token may be bound to a cryptographic key, which is then		An access token may be bound to a cryptographic key, which is then
	used by an RS to authenticate requests from a client. Such tokens		used by an RS to authenticate requests from a client. Such tokens
	are called proof-of-possession access tokens (or PoP access		are called proof-of-possession access tokens (or PoP access
	tokens).		tokens).
	The proof-of-possession (PoP) security concept assumes that the AS		The proof-of-possession (PoP) security concept assumes that the AS
	acts as a trusted third party that binds keys to access tokens.		acts as a trusted third party that binds keys to access tokens.
	These so called PoP keys are then used by the client to		These so called PoP keys are then used by the client to
	demonstrate the possession of the secret to the RS when accessing		demonstrate the possession of the secret to the RS when accessing
	skipping to change at page 10, line 21 ¶		skipping to change at page 10, line 44 ¶
	messages. In OSCORE, the CoAP messages are wrapped in COSE objects		messages. In OSCORE, the CoAP messages are wrapped in COSE objects
	and sent using CoAP.		and sent using CoAP.
	This framework RECOMMENDS the use of CoAP as replacement for HTTP for		This framework RECOMMENDS the use of CoAP as replacement for HTTP for
	use in constrained environments.		use in constrained environments.
	4. Protocol Interactions		4. Protocol Interactions
	The ACE framework is based on the OAuth 2.0 protocol interactions		The ACE framework is based on the OAuth 2.0 protocol interactions
	using the token endpoint and optionally the introspection endpoint.		using the token endpoint and optionally the introspection endpoint.
	A client obtains an access token from an AS using the token endpoint		A client obtains an access token, and optionally a refresh token,
	and subsequently presents the access token to a RS to gain access to		from an AS using the token endpoint and subsequently presents the
	a protected resource. In most deployments the RS can process the		access token to a RS to gain access to a protected resource. In most
	access token locally, however in some cases the RS may present it to		deployments the RS can process the access token locally, however in
	the AS via the introspection endpoint to get fresh information.		some cases the RS may present it to the AS via the introspection
	These interactions are shown in Figure 1. An overview of various		endpoint to get fresh information. These interactions are shown in
	OAuth concepts is provided in Section 3.1.		Figure 1. An overview of various OAuth concepts is provided in
			Section 3.1.
	The OAuth 2.0 framework defines a number of "protocol flows" via		The OAuth 2.0 framework defines a number of "protocol flows" via
	grant types, which have been extended further with extensions to		grant types, which have been extended further with extensions to
	OAuth 2.0 (such as RFC 7521 [RFC7521] and		OAuth 2.0 (such as RFC 7521 [RFC7521] and
	[I-D.ietf-oauth-device-flow]). What grant types works best depends		[I-D.ietf-oauth-device-flow]). What grant types works best depends
	on the usage scenario and RFC 7744 [RFC7744] describes many different		on the usage scenario and RFC 7744 [RFC7744] describes many different
	IoT use cases but there are two preferred grant types, namely the		IoT use cases but there are two preferred grant types, namely the
	Authorization Code Grant (described in Section 4.1 of [RFC7521]) and		Authorization Code Grant (described in Section 4.1 of [RFC7521]) and
	the Client Credentials Grant (described in Section 4.4 of [RFC7521]).		the Client Credentials Grant (described in Section 4.4 of [RFC7521]).
	The Authorization Code Grant is a good fit for use with apps running		The Authorization Code Grant is a good fit for use with apps running
	skipping to change at page 12, line 9 ¶		skipping to change at page 12, line 22 ¶
	In Bluetooth Low Energy, for example, advertisements are broadcasted		In Bluetooth Low Energy, for example, advertisements are broadcasted
	by a peripheral, including information about the primary services.		by a peripheral, including information about the primary services.
	In CoAP, as a second example, a client can make a request to "/.well-		In CoAP, as a second example, a client can make a request to "/.well-
	known/core" to obtain information about available resources, which		known/core" to obtain information about available resources, which
	are returned in a standardized format as described in [RFC6690].		are returned in a standardized format as described in [RFC6690].
	+--------+ +---------------+		+--------+ +---------------+
	| |---(A)-- Token Request ------->| |		| |---(A)-- Token Request ------->| |
	| | | Authorization |		| | | Authorization |
	| |<--(B)-- Access Token ---------| Server |		| |<--(B)-- Access Token ---------| Server |
	| | + Access Information | |		| | + Access Information | |
	| | +---------------+		| | + Refresh Token (optional) +---------------+
	| | ^ |		| | ^ |
	| | Introspection Request (D)| |		| | Introspection Request (D)| |
	| Client | (optional) | |		| Client | (optional) | |
	| | Response | |(E)		| | Response | |(E)
	| | (optional) | v		| | (optional) | v
	| | +--------------+		| | +--------------+
	| |---(C)-- Token + Request ----->| |		| |---(C)-- Token + Request ----->| |
	| | | Resource |		| | | Resource |
	| |<--(F)-- Protected Resource ---| Server |		| |<--(F)-- Protected Resource ---| Server |
	| | | |		| | | |
	skipping to change at page 12, line 36 ¶		skipping to change at page 12, line 49 ¶
	The client makes an access token request to the token endpoint at		The client makes an access token request to the token endpoint at
	the AS. This framework assumes the use of PoP access tokens (see		the AS. This framework assumes the use of PoP access tokens (see
	Section 3.1 for a short description) wherein the AS binds a key to		Section 3.1 for a short description) wherein the AS binds a key to
	an access token. The client may include permissions it seeks to		an access token. The client may include permissions it seeks to
	obtain, and information about the credentials it wants to use		obtain, and information about the credentials it wants to use
	(e.g., symmetric/asymmetric cryptography or a reference to a		(e.g., symmetric/asymmetric cryptography or a reference to a
	specific credential).		specific credential).
	Access Token Response (B):		Access Token Response (B):
	If the AS successfully processes the request from the client, it		If the AS successfully processes the request from the client, it
	returns an access token. It can also return additional		returns an access token and optionally a refresh token (note that
	parameters, referred to as "Access Information". In addition to		only certain grant types support refresh tokens). It can also
	the response parameters defined by OAuth 2.0 and the PoP access		return additional parameters, referred to as "Access Information".
	token extension, this framework defines parameters that can be
	used to inform the client about capabilities of the RS. More		In addition to the response parameters defined by OAuth 2.0 and
	information about these parameters can be found in Section 5.6.4.		the PoP access token extension, this framework defines parameters
			that can be used to inform the client about capabilities of the
			RS. More information about these parameters can be found in
			Section 5.6.4.
	Resource Request (C):		Resource Request (C):
	The client interacts with the RS to request access to the		The client interacts with the RS to request access to the
	protected resource and provides the access token. The protocol to		protected resource and provides the access token. The protocol to
	use between the client and the RS is not restricted to CoAP.		use between the client and the RS is not restricted to CoAP.
	HTTP, HTTP/2, QUIC, MQTT, Bluetooth Low Energy, etc., are also		HTTP, HTTP/2, QUIC, MQTT, Bluetooth Low Energy, etc., are also
	viable candidates.		viable candidates.
	Depending on the device limitations and the selected protocol,		Depending on the device limitations and the selected protocol,
	this exchange may be split up into two parts:		this exchange may be split up into two parts:
	skipping to change at page 19, line 45 ¶		skipping to change at page 20, line 5 ¶
	integer abbreviations and the binary CBOR encoding, if the CBOR		integer abbreviations and the binary CBOR encoding, if the CBOR
	encoding is used.		encoding is used.
	5.6.1. Client-to-AS Request		5.6.1. Client-to-AS Request
	The client sends a POST request to the token endpoint at the AS. The		The client sends a POST request to the token endpoint at the AS. The
	profile MUST specify how the communication is protected. The content		profile MUST specify how the communication is protected. The content
	of the request consists of the parameters specified in Section 4 of		of the request consists of the parameters specified in Section 4 of
	the OAuth 2.0 specification [RFC6749].		the OAuth 2.0 specification [RFC6749].
			In addition to these parameters the parameters from
			[I-D.ietf-ace-oauth-params] can be used for requesting an access
			token from a token endpoint.
	If CBOR is used then this parameter MUST be encoded as a CBOR map.		If CBOR is used then this parameter MUST be encoded as a CBOR map.
	The "scope" parameter can be formatted as specified in [RFC6749] and		The "scope" parameter can be formatted as specified in [RFC6749] and
	additionally as a byte array, in order to allow compact encoding of		additionally as a byte array, in order to allow compact encoding of
	complex scopes.		complex scopes.
	When HTTP is used as a transport then the client makes a request to		When HTTP is used as a transport then the client makes a request to
	the token endpoint by sending the parameters using the "application/		the token endpoint by sending the parameters using the "application/
	x-www-form-urlencoded" format with a character encoding of UTF-8 in		x-www-form-urlencoded" format with a character encoding of UTF-8 in
	the HTTP request entity-body, as defined in RFC 6749.		the HTTP request entity-body, as defined in RFC 6749.
	In addition to these parameters the parameters from
	[I-D.ietf-ace-oauth-params] can be used for requesting an access
	token from a token endpoint.
	The following examples illustrate different types of requests for		The following examples illustrate different types of requests for
	proof-of-possession tokens.		proof-of-possession tokens.
	Figure 5 shows a request for a token with a symmetric proof-of-		Figure 5 shows a request for a token with a symmetric proof-of-
	possession key. The content is displayed in CBOR diagnostic		possession key. The content is displayed in CBOR diagnostic
	notation, without abbreviations for better readability.		notation, without abbreviations for better readability.
	Header: POST (Code=0.02)		Header: POST (Code=0.02)
	Uri-Host: "as.example.com"		Uri-Host: "as.example.com"
	Uri-Path: "token"		Uri-Path: "token"
	skipping to change at page 22, line 24 ¶		skipping to change at page 22, line 24 ¶
	"aud" : "valve424",		"aud" : "valve424",
	"scope" : "read",		"scope" : "read",
	"cnf" : {		"cnf" : {
	"kid" : b64'6kg0dXJM13U'		"kid" : b64'6kg0dXJM13U'
	}		}
	}		}
	Figure 7: Example request for an access token bound to a key		Figure 7: Example request for an access token bound to a key
	reference.		reference.
			Refresh tokens are typically not stored as securely as proof-of-
			possession keys in requesting clients. Proof-of-possession based
			refresh token requests MUST NOT request different proof-of-possession
			keys or different audiences in token requests. Refresh token
			requests can only use to request access tokens bound to the same
			proof-of-possession key and the same audience as access tokens issued
			in the initial token request.
	5.6.2. AS-to-Client Response		5.6.2. AS-to-Client Response
	If the access token request has been successfully verified by the AS		If the access token request has been successfully verified by the AS
	and the client is authorized to obtain an access token corresponding		and the client is authorized to obtain an access token corresponding
	to its access token request, the AS sends a response with the		to its access token request, the AS sends a response with the
	response code equivalent to the CoAP response code 2.01 (Created).		response code equivalent to the CoAP response code 2.01 (Created).
	If client request was invalid, or not authorized, the AS returns an		If client request was invalid, or not authorized, the AS returns an
	error response as described in Section 5.6.3.		error response as described in Section 5.6.3.
	Note that the AS decides which token type and profile to use when		Note that the AS decides which token type and profile to use when
	skipping to change at page 22, line 45 ¶		skipping to change at page 23, line 4 ¶
	knowledge of the capabilities of the client and the RS (see		knowledge of the capabilities of the client and the RS (see
	Appendix D. This prior knowledge may, for example, be set by the use		Appendix D. This prior knowledge may, for example, be set by the use
	of a dynamic client registration protocol exchange [RFC7591].		of a dynamic client registration protocol exchange [RFC7591].
	The content of the successful reply is the Access Information. When		The content of the successful reply is the Access Information. When
	using CBOR payloads, the content MUST be encoded as CBOR map,		using CBOR payloads, the content MUST be encoded as CBOR map,
	containing parameters as specified in Section 5.1 of [RFC6749], with		containing parameters as specified in Section 5.1 of [RFC6749], with
	the following additions and changes:		the following additions and changes:
	profile:		profile:
	OPTIONAL. This indicates the profile that the client MUST use		OPTIONAL. This indicates the profile that the client MUST use
	towards the RS. See Section 5.6.4.3 for the formatting of this		towards the RS. See Section 5.6.4.3 for the formatting of this
	parameter. If this parameter is absent, the AS assumes that the		parameter. If this parameter is absent, the AS assumes that the
	client implicitly knows which profile to use towards the RS.		client implicitly knows which profile to use towards the RS.
	token_type:		token_type:
	This parameter is OPTIONAL, as opposed to 'required' in [RFC6749].		This parameter is OPTIONAL, as opposed to 'required' in [RFC6749].
	By default implementations of this framework SHOULD assume that		By default implementations of this framework SHOULD assume that
	the token_type is "pop". If a specific use case requires another		the token_type is "pop". If a specific use case requires another
	token_type (e.g., "Bearer") to be used then this parameter is		token_type (e.g., "Bearer") to be used then this parameter is
	REQUIRED.		REQUIRED.
	Furthermore [I-D.ietf-ace-oauth-params] defines further parameters		Furthermore [I-D.ietf-ace-oauth-params] defines further parameters
	the AS can use when responding to a request to the token endpoint.		the AS can use when responding to a request to the token endpoint.
	Figure 8 summarizes the parameters that may be part of the Access		Figure 8 summarizes the parameters that may be part of the Access
	Information.		Information. This does not include the additional parameters
			specified in [I-D.ietf-ace-oauth-params].
	/-------------------+-------------------------------\		/-------------------+-------------------------------\
	| Parameter name | Specified in |		| Parameter name | Specified in |
	|-------------------+-------------------------------|		|-------------------+-------------------------------|
	| access_token | RFC 6749 |		| access_token | RFC 6749 |
	| token_type | RFC 6749 |		| token_type | RFC 6749 |
	| expires_in | RFC 6749 |		| expires_in | RFC 6749 |
	| refresh_token | RFC 6749 |		| refresh_token | RFC 6749 |
	| scope | RFC 6749 |		| scope | RFC 6749 |
	| state | RFC 6749 |		| state | RFC 6749 |
	skipping to change at page 27, line 5 ¶		skipping to change at page 26, line 48 ¶
	5.6.5. Mapping Parameters to CBOR		5.6.5. Mapping Parameters to CBOR
	If CBOR encoding is used, all OAuth parameters in access token		If CBOR encoding is used, all OAuth parameters in access token
	requests and responses MUST be mapped to CBOR types as specified in		requests and responses MUST be mapped to CBOR types as specified in
	Figure 12, using the given integer abbreviation for the map keys.		Figure 12, using the given integer abbreviation for the map keys.
	Note that we have aligned these abbreviations with the claim		Note that we have aligned these abbreviations with the claim
	abbreviations defined in [RFC8392].		abbreviations defined in [RFC8392].
			Note also that abbreviations from -24 to 23 have a 1 byte encoding
			size in CBOR. We have thus choosen to assign abbreviations in that
			range to parameters we expect to be used most frequently in
			constrained scenarios.
	/-------------------+----------+---------------------\		/-------------------+----------+---------------------\
	| Name | CBOR Key | Value Type |		| Name | CBOR Key | Value Type |
	|-------------------+----------+---------------------|		|-------------------+----------+---------------------|
	| scope | 9 | text or byte string |		| scope | 9 | text or byte string |
	| profile | 10 | unsigned integer |		| profile | 10 | unsigned integer |
	| error | 11 | unsinged integer |		| error | 11 | unsigned integer |
	| grant_type | 12 | unsigned integer |		| grant_type | 12 | unsigned integer |
	| access_token | 13 | byte string |		| access_token | 13 | byte string |
	| token_type | 14 | unsigned integer |		| token_type | 14 | unsigned integer |
	| client_id | 24 | text string |		| client_id | 24 | text string |
	| client_secret | 25 | byte string |		| client_secret | 25 | byte string |
	| response_type | 26 | text string |		| response_type | 26 | text string |
	| state | 27 | text string |		| state | 27 | text string |
	| redirect_uri | 28 | text string |		| redirect_uri | 28 | text string |
	| error_description | 29 | text string |		| error_description | 29 | text string |
	| error_uri | 30 | text string |		| error_uri | 30 | text string |
	| code | 31 | byte string |		| code | 31 | byte string |
	| expires_in | 32 | unsigned integer |		| expires_in | 32 | unsigned integer |
	| username | 33 | text string |		| username | 33 | text string |
	| password | 34 | text string |		| password | 34 | text string |
	| refresh_token | 35 | byte string |		| refresh_token | 35 | byte string |
	\-------------------+----------+---------------------/		\-------------------+----------+---------------------/
	Figure 12: CBOR mappings used in token requests		Figure 12: CBOR mappings used in token requests
	5.7. The 'Introspect' Endpoint		5.7. The Introspection Endpoint
	Token introspection [RFC7662] can be OPTIONALLY provided by the AS,		Token introspection [RFC7662] can be OPTIONALLY provided by the AS,
	and is then used by the RS and potentially the client to query the AS		and is then used by the RS and potentially the client to query the AS
	for metadata about a given token, e.g., validity or scope. Analogous		for metadata about a given token, e.g., validity or scope. Analogous
	to the protocol defined in RFC 7662 [RFC7662] for HTTP and JSON, this		to the protocol defined in RFC 7662 [RFC7662] for HTTP and JSON, this
	section defines adaptations to more constrained environments using		section defines adaptations to more constrained environments using
	CBOR and leaving the choice of the application protocol to the		CBOR and leaving the choice of the application protocol to the
	profile.		profile.
	Communication between the RS and the introspection endpoint at the AS		Communication between the requesting entity and the introspection
	MUST be integrity protected and encrypted. Furthermore AS and RS		endpoint at the AS MUST be integrity protected and encrypted.
	MUST perform mutual authentication. Finally the AS SHOULD verify		Furthermore the two MUST perform mutual authentication. Finally the
	that the RS has the right to access introspection information about		AS SHOULD verify that the requesting entity has the right to access
	the provided token. Profiles of this framework that support		introspection information about the provided token. Profiles of this
	introspection MUST specify how authentication and communication		framework that support introspection MUST specify how authentication
	security between RS and AS is implemented.		and communication security between the requesting entity and the AS
			is implemented.
	The default name of this endpoint in an url-path is '/introspect',		The default name of this endpoint in an url-path is '/introspect',
	however implementations are not required to use this name and can		however implementations are not required to use this name and can
	define their own instead.		define their own instead.
	The figures of this section uses CBOR diagnostic notation without the		The figures of this section uses CBOR diagnostic notation without the
	integer abbreviations for the parameters or their values for better		integer abbreviations for the parameters or their values for better
	readability.		readability.
	Note that supporting introspection is OPTIONAL for implementations of		Note that supporting introspection is OPTIONAL for implementations of
	this framework.		this framework.
	5.7.1. RS-to-AS Request		5.7.1. Introspection Request
	The RS sends a POST request to the introspection endpoint at the AS,		The requesting entity sends a POST request to the introspection
	the profile MUST specify how the communication is protected. If CBOR		endpoint at the AS, the profile MUST specify how the communication is
	is used, the payload MUST be encoded as a CBOR map with a "token"		protected. If CBOR is used, the payload MUST be encoded as a CBOR
	entry containing either the access token or a reference to the token		map with a "token" entry containing either the access token or a
	(e.g., the cti). Further optional parameters representing additional		reference to the token (e.g., the cti). Further optional parameters
	context that is known by the RS to aid the AS in its response MAY be		representing additional context that is known by the requesting
	included.		entity to aid the AS in its response MAY be included.
	The same parameters are required and optional as in Section 2.1 of		The same parameters are required and optional as in Section 2.1 of
	RFC 7662 [RFC7662].		RFC 7662 [RFC7662].
	For example, Figure 13 shows a RS calling the token introspection		For example, Figure 13 shows a RS calling the token introspection
	endpoint at the AS to query about an OAuth 2.0 proof-of-possession		endpoint at the AS to query about an OAuth 2.0 proof-of-possession
	token. Note that object security based on COSE is assumed in this		token. Note that object security based on COSE is assumed in this
	example, therefore the Content-Format is "application/cose".		example, therefore the Content-Format is "application/cose".
	Figure 14 shows the decoded payload.		Figure 14 shows the decoded payload.
	skipping to change at page 28, line 47 ¶		skipping to change at page 28, line 47 ¶
	Figure 13: Example introspection request.		Figure 13: Example introspection request.
	{		{
	"token" : b64'7gj0dXJQ43U',		"token" : b64'7gj0dXJQ43U',
	"token_type_hint" : "pop"		"token_type_hint" : "pop"
	}		}
	Figure 14: Decoded token.		Figure 14: Decoded token.
	5.7.2. AS-to-RS Response		5.7.2. Introspection Response
	If the introspection request is authorized and successfully		If the introspection request is authorized and successfully
	processed, the AS sends a response with the response code equivalent		processed, the AS sends a response with the response code equivalent
	to the CoAP code 2.01 (Created). If the introspection request was		to the CoAP code 2.01 (Created). If the introspection request was
	invalid, not authorized or couldn't be processed the AS returns an		invalid, not authorized or couldn't be processed the AS returns an
	error response as described in Section 5.7.3.		error response as described in Section 5.7.3.
	In a successful response, the AS encodes the response parameters in a		In a successful response, the AS encodes the response parameters in a
	map including with the same required and optional parameters as in		map including with the same required and optional parameters as in
	Section 2.2 of RFC 7662 [RFC7662] with the following addition:		Section 2.2 of RFC 7662 [RFC7662] with the following addition:
	skipping to change at page 29, line 49 ¶		skipping to change at page 29, line 49 ¶
	5.7.3. Error Response		5.7.3. Error Response
	The error responses for CoAP-based interactions with the AS are		The error responses for CoAP-based interactions with the AS are
	equivalent to the ones for HTTP-based interactions as defined in		equivalent to the ones for HTTP-based interactions as defined in
	Section 2.3 of [RFC7662], with the following differences:		Section 2.3 of [RFC7662], with the following differences:
	o If content is sent and CBOR is used the payload MUST be encoded as		o If content is sent and CBOR is used the payload MUST be encoded as
	a CBOR map and the Content-Format "application/ace+cbor" MUST be		a CBOR map and the Content-Format "application/ace+cbor" MUST be
	used.		used.
	o If the credentials used by the RS are invalid the AS MUST respond		o If the credentials used by the requesting entity (usually the RS)
	with the response code equivalent to the CoAP code 4.01		are invalid the AS MUST respond with the response code equivalent
	(Unauthorized) and use the required and optional parameters from		to the CoAP code 4.01 (Unauthorized) and use the required and
	Section 5.2 in RFC 6749 [RFC6749].		optional parameters from Section 5.2 in RFC 6749 [RFC6749].
	o If the RS does not have the right to perform this introspection		o If the requesting entity does not have the right to perform this
	request, the AS MUST respond with a response code equivalent to		introspection request, the AS MUST respond with a response code
	the CoAP code 4.03 (Forbidden). In this case no payload is		equivalent to the CoAP code 4.03 (Forbidden). In this case no
	returned.		payload is returned.
	o The parameters "error", "error_description" and "error_uri" MUST		o The parameters "error", "error_description" and "error_uri" MUST
	be abbreviated using the codes specified in Figure 12.		be abbreviated using the codes specified in Figure 12.
	o The error codes MUST be abbreviated using the codes specified in		o The error codes MUST be abbreviated using the codes specified in
	Figure 10.		Figure 10.
	Note that a properly formed and authorized query for an inactive or		Note that a properly formed and authorized query for an inactive or
	otherwise invalid token does not warrant an error response by this		otherwise invalid token does not warrant an error response by this
	specification. In these cases, the authorization server MUST instead		specification. In these cases, the authorization server MUST instead
	respond with an introspection response with the "active" field set to		respond with an introspection response with the "active" field set to
	"false".		"false".
	skipping to change at page 31, line 32 ¶		skipping to change at page 31, line 32 ¶
	If the AS needs to convey a hint to the RS about which key it should		If the AS needs to convey a hint to the RS about which key it should
	use to authenticate towards the client, the rs_cnf claim MAY be used		use to authenticate towards the client, the rs_cnf claim MAY be used
	with the same syntax and semantics as defined in		with the same syntax and semantics as defined in
	[I-D.ietf-ace-oauth-params].		[I-D.ietf-ace-oauth-params].
	If the AS needs to convey a hint to the RS about which profile it		If the AS needs to convey a hint to the RS about which profile it
	should use to communicate with the client, the AS MAY include a		should use to communicate with the client, the AS MAY include a
	"profile" claim in the access token, with the same syntax and		"profile" claim in the access token, with the same syntax and
	semantics as defined in Section 5.6.4.3.		semantics as defined in Section 5.6.4.3.
	5.8.1. The 'Authorization Information' Endpoint		5.8.1. The Authorization Information Endpoint
	The access token, containing authorization information and		The access token, containing authorization information and
	information about the key used by the client, needs to be transported		information about the key used by the client, needs to be transported
	to the RS so that the RS can authenticate and authorize the client		to the RS so that the RS can authenticate and authorize the client
	request.		request.
	This section defines a method for transporting the access token to		This section defines a method for transporting the access token to
	the RS using a RESTful protocol such as CoAP. Profiles of this		the RS using a RESTful protocol such as CoAP. Profiles of this
	framework MAY define other methods for token transport.		framework MAY define other methods for token transport.
	skipping to change at page 32, line 27 ¶		skipping to change at page 32, line 27 ¶
	but is associated to claims that the RS cannot process (e.g., an		but is associated to claims that the RS cannot process (e.g., an
	unknown scope) the RS MUST respond with a response code equivalent to		unknown scope) the RS MUST respond with a response code equivalent to
	the CoAP code 4.00 (Bad Request). In the latter case the RS MAY		the CoAP code 4.00 (Bad Request). In the latter case the RS MAY
	provide additional information in the error response, in order to		provide additional information in the error response, in order to
	clarify what went wrong.		clarify what went wrong.
	The RS MAY make an introspection request to validate the token before		The RS MAY make an introspection request to validate the token before
	responding to the POST request to the authz-info endpoint.		responding to the POST request to the authz-info endpoint.
	Profiles MUST specify whether the authz-info endpoint is protected,		Profiles MUST specify whether the authz-info endpoint is protected,
	including wheter error responses from this endpoint are protected.		including whether error responses from this endpoint are protected.
	Note that since the token contains information that allow the client		Note that since the token contains information that allow the client
	and the RS to establish a security context in the first place, mutual		and the RS to establish a security context in the first place, mutual
	authentication may not be possible at this point.		authentication may not be possible at this point.
	The default name of this endpoint in an url-path is '/authz-info',		The default name of this endpoint in an url-path is '/authz-info',
	however implementations are not required to use this name and can		however implementations are not required to use this name and can
	define their own instead.		define their own instead.
	5.8.2. Client Requests to the RS		5.8.2. Client Requests to the RS
	skipping to change at page 35, line 7 ¶		skipping to change at page 35, line 7 ¶
	token, for example encryption of CWTs is specified in Section 5.1 of		token, for example encryption of CWTs is specified in Section 5.1 of
	[RFC8392].		[RFC8392].
	Developers MUST ensure that the ephemeral credentials (i.e., the		Developers MUST ensure that the ephemeral credentials (i.e., the
	private key or the session key) are not leaked to third parties. An		private key or the session key) are not leaked to third parties. An
	adversary in possession of the ephemeral credentials bound to the		adversary in possession of the ephemeral credentials bound to the
	access token will be able to impersonate the client. Be aware that		access token will be able to impersonate the client. Be aware that
	this is a real risk with many constrained environments, since		this is a real risk with many constrained environments, since
	adversaries can often easily get physical access to the devices.		adversaries can often easily get physical access to the devices.
	Clients can at any time request a new proof-of-possession capable		If clients are capable of doing so, they should frequently request
	access token. If clients have that capability, the AS can keep the		fresh access tokens, as this allows the AS to keep the lifetime of
	lifetime of the access token and the associated proof-of-possession		the tokens short. This allows the AS to use shorter proof-of-
	key short and therefore use shorter proof-of-possession key sizes,		possession key sizes, which translate to a performance benefit for
	which translate to a performance benefit for the client and for the		the client and for the resource server. Shorter keys also lead to
	resource server. Shorter keys also lead to shorter messages		shorter messages (particularly with asymmetric keying material).
	(particularly with asymmetric keying material).
	When authorization servers bind symmetric keys to access tokens, they		When authorization servers bind symmetric keys to access tokens, they
	SHOULD scope these access tokens to a specific permissions.		SHOULD scope these access tokens to a specific permissions.
	Furthermore access tokens using symmetric keys for proof-of-		Furthermore access tokens using symmetric keys for proof-of-
	possession SHOULD NOT be targeted at an audience that contains more		possession SHOULD NOT be targeted at an audience that contains more
	than one RS, since otherwise any RS in the audience that receives		than one RS, since otherwise any RS in the audience that receives
	that access token can impersonate the client towards the other		that access token can impersonate the client towards the other
	members of the audience.		members of the audience.
	6.1. Unprotected AS Information		6.1. Unprotected AS Information
	skipping to change at page 43, line 14 ¶		skipping to change at page 43, line 14 ¶
	o Claim Description: The public key the RS is supposed to use to		o Claim Description: The public key the RS is supposed to use to
	authenticate to the client wielding this token.		authenticate to the client wielding this token.
	o JWT Claim Name: N/A		o JWT Claim Name: N/A
	o Claim Key: 17		o Claim Key: 17
	o Claim Value Type(s): map		o Claim Value Type(s): map
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 5.8 of [this document]		o Specification Document(s): Section 5.8 of [this document]
	8.13. Media Type Registrations		8.13. Media Type Registrations
	This document registres a media type for messages of the protocols		This document registers the 'application/ace+cbor' media type for
	defined in this document carrying parameters encoded in CBOR. This		messages of the protocols defined in this document carrying
	registration follows the procedures specified in [RFC6838].		parameters encoded in CBOR. This registration follows the procedures
			specified in [RFC6838].
	8.13.1. Media Type Registration
	Type name: application		Type name: application
	Subtype name: ace+cbor		Subtype name: ace+cbor
	Required parameters: none		Required parameters: none
	Optional parameters: none		Optional parameters: none
	Encoding considerations: Must be encoded as CBOR map containg the		Encoding considerations: Must be encoded as CBOR map containing the
	protocol parameters defined in [this document].		protocol parameters defined in [this document].
	Security considerations: See Section 6 of this document.		Security considerations: See Section 6 of this document.
	Interoperability considerations: n/a		Interoperability considerations: n/a
	Published specification: [this document]		Published specification: [this document]
	Applications that use this media type: The type is used by		Applications that use this media type: The type is used by
	authorization servers, clients and resource servers that support the		authorization servers, clients and resource servers that support the
	skipping to change at page 44, line 4 ¶		skipping to change at page 43, line 50 ¶
	Additional information:		Additional information:
	Magic number(s): n/a		Magic number(s): n/a
	File extension(s): .ace		File extension(s): .ace
	Macintosh file type code(s): n/a		Macintosh file type code(s): n/a
	Person & email address to contact for further information: Ludwig		Person & email address to contact for further information: Ludwig
	Seitz <ludwig.seitz@ri.se>		Seitz <ludwig.seitz@ri.se>
	Intended usage: COMMON
			Intended usage: COMMON
	Restrictions on usage: None		Restrictions on usage: None
	Author: Ludwig Seitzs <ludwig.setiz@ri.se>		Author: Ludwig Seitz <ludwig.setiz@ri.se>
	Change controller: IESG		Change controller: IESG
	8.14. CoAP Content-Format Registry		8.14. CoAP Content-Format Registry
	This document registers the following entry to the "CoAP Content-		This document registers the following entry to the "CoAP Content-
	Formats" registry:		Formats" registry:
	Media Type: application/ace+cbor		Media Type: application/ace+cbor
	skipping to change at page 53, line 35 ¶		skipping to change at page 53, line 27 ¶
	* Process a token request using the authorization policies		* Process a token request using the authorization policies
	configured for the RS.		configured for the RS.
	* Optionally: Expose the introspection endpoint that allows RS's		* Optionally: Expose the introspection endpoint that allows RS's
	to submit token introspection requests.		to submit token introspection requests.
	* If providing an introspection endpoint: Authenticate RSs that		* If providing an introspection endpoint: Authenticate RSs that
	wish to get an introspection response.		wish to get an introspection response.
	* If providing an introspection endpoint: Process token		* If providing an introspection endpoint: Process token
	introspection requests.		introspection requests.
	* Optionally: Handle token revocation.		* Optionally: Handle token revocation.
	* Optionally: Provide discovery metadata. See [RFC8414]		* Optionally: Provide discovery metadata. See [RFC8414]
			* Optionally: Handle refresh tokens.
	Client		Client
	* Discover the AS in charge of the RS that is to be targeted with		* Discover the AS in charge of the RS that is to be targeted with
	a request.		a request.
	* Submit the token request (see step (A) of Figure 1).		* Submit the token request (see step (A) of Figure 1).
	+ Authenticate to the AS.		+ Authenticate to the AS.
	+ Optionally (if not pre-configured): Specify which RS, which		+ Optionally (if not pre-configured): Specify which RS, which
	resource(s), and which action(s) the request(s) will target.		resource(s), and which action(s) the request(s) will target.
	+ If raw public keys (rpk) or certificates are used, make sure		+ If raw public keys (rpk) or certificates are used, make sure
	the AS has the right rpk or certificate for this client.		the AS has the right rpk or certificate for this client.
	* Process the access token and Access Information (see step (B)		* Process the access token and Access Information (see step (B)
	of Figure 1).		of Figure 1).
	+ Check that the Access Information provides the necessary		+ Check that the Access Information provides the necessary
	security parameters (e.g., PoP key, information on		security parameters (e.g., PoP key, information on
	communication security protocols supported by the RS).		communication security protocols supported by the RS).
			+ Safely store the proof-of-possession key.
			+ If provided by the AS: Safely store the refresh token.
	* Send the token and request to the RS (see step (C) of		* Send the token and request to the RS (see step (C) of
	Figure 1).		Figure 1).
	+ Authenticate towards the RS (this could coincide with the		+ Authenticate towards the RS (this could coincide with the
	proof of possession process).		proof of possession process).
	+ Transmit the token as specified by the AS (default is to the		+ Transmit the token as specified by the AS (default is to the
	authz-info endpoint, alternative options are specified by		authz-info endpoint, alternative options are specified by
	profiles).		profiles).
	+ Perform the proof-of-possession procedure as specified by		+ Perform the proof-of-possession procedure as specified by
	the profile in use (this may already have been taken care of		the profile in use (this may already have been taken care of
	through the authentication procedure).		through the authentication procedure).
	* Process the RS response (see step (F) of Figure 1) of the RS.		* Process the RS response (see step (F) of Figure 1) of the RS.
	Resource Server		Resource Server
	skipping to change at page 54, line 42 ¶		skipping to change at page 54, line 37 ¶
	+ Set up communication security with the client.		+ Set up communication security with the client.
	+ Authenticate the client.		+ Authenticate the client.
	+ Match the client against existing tokens.		+ Match the client against existing tokens.
	+ Check that tokens belonging to the client actually authorize		+ Check that tokens belonging to the client actually authorize
	the requested action.		the requested action.
	+ Optionally: Check that the matching tokens are still valid,		+ Optionally: Check that the matching tokens are still valid,
	using introspection (if this is possible.)		using introspection (if this is possible.)
	* Send a response following the agreed upon communication		* Send a response following the agreed upon communication
	security.		security.
			* Safely store credentials such as raw public keys for
			authentication or proof-of-possession keys linked to access
			tokens.
	Appendix C. Requirements on Profiles		Appendix C. Requirements on Profiles
	This section lists the requirements on profiles of this framework,		This section lists the requirements on profiles of this framework,
	for the convenience of profile designers.		for the convenience of profile designers.
	o Specify the communication protocol the client and RS the must use		o Specify the communication protocol the client and RS the must use
	(e.g., CoAP). Section 5 and Section 5.6.4.3		(e.g., CoAP). Section 5 and Section 5.6.4.3
	o Specify the security protocol the client and RS must use to		o Specify the security protocol the client and RS must use to
	protect their communication (e.g., OSCORE or DTLS over CoAP).		protect their communication (e.g., OSCORE or DTLS over CoAP).
	skipping to change at page 58, line 26 ¶		skipping to change at page 58, line 26 ¶
	"x" : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',		"x" : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
	"y" : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'		"y" : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
	}		}
	}		}
	}		}
	Response-Payload :		Response-Payload :
	{		{
	"access_token" : b64'SlAV32hkKG ...',		"access_token" : b64'SlAV32hkKG ...',
	"token_type" : "pop",		"token_type" : "pop",
	"csp" : "DTLS",
	"rs_cnf" : {		"rs_cnf" : {
	"COSE_Key" : {		"COSE_Key" : {
	"kid" : b64'c29tZSBwdWJsaWMga2V5IGlk',		"kid" : b64'c29tZSBwdWJsaWMga2V5IGlk',
	"kty" : "EC",		"kty" : "EC",
	"crv" : "P-256",		"crv" : "P-256",
	"x" : b64'MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4',		"x" : b64'MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4',
	"y" : b64'4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM'		"y" : b64'4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM'
	}		}
	}		}
	}		}
	skipping to change at page 62, line 16 ¶		skipping to change at page 62, line 16 ¶
	{		{
	"grant_type" : "client_credentials",		"grant_type" : "client_credentials",
	"client_id" : "keyfob",		"client_id" : "keyfob",
	"client_secret" : "qwerty"		"client_secret" : "qwerty"
	}		}
	Response-Payload:		Response-Payload:
	{		{
	"access_token" : b64'VGVzdCB0b2tlbg==',		"access_token" : b64'VGVzdCB0b2tlbg==',
	"token_type" : "pop",		"token_type" : "pop",
	"csp" : "DTLS",
	"cnf" : {		"cnf" : {
	"COSE_Key" : {		"COSE_Key" : {
	"kid" : b64'c29tZSBwdWJsaWMga2V5IGlk',		"kid" : b64'c29tZSBwdWJsaWMga2V5IGlk',
	"kty" : "oct",		"kty" : "oct",
	"alg" : "HS256",		"alg" : "HS256",
	"k": b64'ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE'		"k": b64'ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE'
	}		}
	}		}
	}		}
	skipping to change at page 64, line 32 ¶		skipping to change at page 64, line 32 ¶
	F: |<--------+ Header: 2.04 Changed		F: |<--------+ Header: 2.04 Changed
	| 2.04 | Payload: <new state for the lock>		| 2.04 | Payload: <new state for the lock>
	| |		| |
	Figure 26: Resource request and response protected by OSCORE		Figure 26: Resource request and response protected by OSCORE
	Appendix F. Document Updates		Appendix F. Document Updates
	RFC EDITOR: PLEASE REMOVE THIS SECTION.		RFC EDITOR: PLEASE REMOVE THIS SECTION.
	F.1. Version -13 to -14		F.1. Version -14 to -15
			o Added text about refresh tokens.
			o Added text about protection of credentials.
			o Rephrased introspection so that other entities than RS can do it.
			o Editorial improvements.
			F.2. Version -13 to -14
	o Split out the 'aud', 'cnf' and 'rs_cnf' parameters to		o Split out the 'aud', 'cnf' and 'rs_cnf' parameters to
	[I-D.ietf-ace-oauth-params]		[I-D.ietf-ace-oauth-params]
	o Introduced the "application/ace+cbor" Content-Type.		o Introduced the "application/ace+cbor" Content-Type.
	o Added claim registrations from 'profile' and 'rs_cnf'.		o Added claim registrations from 'profile' and 'rs_cnf'.
	o Added note on schema part of AS Information Section 5.1.2		o Added note on schema part of AS Information Section 5.1.2
	o Realigned the parameter abbreviations to push rarely used ones to		o Realigned the parameter abbreviations to push rarely used ones to
	the 2-byte encoding size of CBOR integers.		the 2-byte encoding size of CBOR integers.
	F.2. Version -12 to -13		F.3. Version -12 to -13
	o Changed "Resource Information" to "Access Information" to avoid		o Changed "Resource Information" to "Access Information" to avoid
	confusion.		confusion.
	o Clarified section about AS discovery.		o Clarified section about AS discovery.
	o Editorial changes		o Editorial changes
	F.3. Version -11 to -12		F.4. Version -11 to -12
	o Moved the Request error handling to a section of its own.		o Moved the Request error handling to a section of its own.
	o Require the use of the abbreviation for profile identifiers.		o Require the use of the abbreviation for profile identifiers.
	o Added rs_cnf parameter in the introspection response, to inform		o Added rs_cnf parameter in the introspection response, to inform
	RS' with several RPKs on which key to use.		RS' with several RPKs on which key to use.
	o Allowed use of rs_cnf as claim in the access token in order to		o Allowed use of rs_cnf as claim in the access token in order to
	inform an RS with several RPKs on which key to use.		inform an RS with several RPKs on which key to use.
	o Clarified that profiles must specify if/how error responses are		o Clarified that profiles must specify if/how error responses are
	protected.		protected.
	o Fixed label number range to align with COSE/CWT.		o Fixed label number range to align with COSE/CWT.
	o Clarified the requirements language in order to allow profiles to		o Clarified the requirements language in order to allow profiles to
	specify other payload formats than CBOR if they do not use CoAP.		specify other payload formats than CBOR if they do not use CoAP.
	F.4. Version -10 to -11		F.5. Version -10 to -11
	o Fixed some CBOR data type errors.		o Fixed some CBOR data type errors.
	o Updated boilerplate text		o Updated boilerplate text
	F.5. Version -09 to -10		F.6. Version -09 to -10
	o Removed CBOR major type numbers.		o Removed CBOR major type numbers.
	o Removed the client token design.		o Removed the client token design.
	o Rephrased to clarify that other protocols than CoAP can be used.		o Rephrased to clarify that other protocols than CoAP can be used.
	o Clarifications regarding the use of HTTP		o Clarifications regarding the use of HTTP
	F.6. Version -08 to -09		F.7. Version -08 to -09
	o Allowed scope to be byte arrays.		o Allowed scope to be byte arrays.
	o Defined default names for endpoints.		o Defined default names for endpoints.
	o Refactored the IANA section for briefness and consistency.		o Refactored the IANA section for briefness and consistency.
	o Refactored tables that define IANA registry contents for		o Refactored tables that define IANA registry contents for
	consistency.		consistency.
	o Created IANA registry for CBOR mappings of error codes, grant		o Created IANA registry for CBOR mappings of error codes, grant
	types and Authorization Server Information.		types and Authorization Server Information.
	o Added references to other document sections defining IANA entries		o Added references to other document sections defining IANA entries
	in the IANA section.		in the IANA section.
	F.7. Version -07 to -08		F.8. Version -07 to -08
	o Moved AS discovery from the DTLS profile to the framework, see		o Moved AS discovery from the DTLS profile to the framework, see
	Section 5.1.		Section 5.1.
	o Made the use of CBOR mandatory. If you use JSON you can use		o Made the use of CBOR mandatory. If you use JSON you can use
	vanilla OAuth.		vanilla OAuth.
	o Made it mandatory for profiles to specify C-AS security and RS-AS		o Made it mandatory for profiles to specify C-AS security and RS-AS
	security (the latter only if introspection is supported).		security (the latter only if introspection is supported).
	o Made the use of CBOR abbreviations mandatory.		o Made the use of CBOR abbreviations mandatory.
	o Added text to clarify the use of token references as an		o Added text to clarify the use of token references as an
	alternative to CWTs.		alternative to CWTs.
	o Added text to clarify that introspection must not be delayed, in		o Added text to clarify that introspection must not be delayed, in
	case the RS has to return a client token.		case the RS has to return a client token.
	o Added security considerations about leakage through unprotected AS		o Added security considerations about leakage through unprotected AS
	discovery information, combining profiles and leakage through		discovery information, combining profiles and leakage through
	error responses.		error responses.
	o Added privacy considerations about leakage through unprotected AS		o Added privacy considerations about leakage through unprotected AS
	discovery.		discovery.
	o Added text that clarifies that introspection is optional.		o Added text that clarifies that introspection is optional.
	o Made profile parameter optional since it can be implicit.		o Made profile parameter optional since it can be implicit.
	o Clarified that CoAP is not mandatory and other protocols can be		o Clarified that CoAP is not mandatory and other protocols can be
	used.		used.
	o Clarified the design justification for specific features of the		o Clarified the design justification for specific features of the
	framework in appendix A.		framework in appendix A.
	o Clarified appendix E.2.		o Clarified appendix E.2.
	o Removed specification of the "cnf" claim for CBOR/COSE, and		o Removed specification of the "cnf" claim for CBOR/COSE, and
	replaced with references to [I-D.ietf-ace-cwt-proof-of-possession]		replaced with references to [I-D.ietf-ace-cwt-proof-of-possession]
	F.8. Version -06 to -07		F.9. Version -06 to -07
	o Various clarifications added.		o Various clarifications added.
	o Fixed erroneous author email.		o Fixed erroneous author email.
	F.9. Version -05 to -06		F.10. Version -05 to -06
	o Moved sections that define the ACE framework into a subsection of		o Moved sections that define the ACE framework into a subsection of
	the framework Section 5.		the framework Section 5.
	o Split section on client credentials and grant into two separate		o Split section on client credentials and grant into two separate
	sections, Section 5.2, and Section 5.3.		sections, Section 5.2, and Section 5.3.
	o Added Section 5.4 on AS authentication.		o Added Section 5.4 on AS authentication.
	o Added Section 5.5 on the Authorization endpoint.		o Added Section 5.5 on the Authorization endpoint.
	F.10. Version -04 to -05		F.11. Version -04 to -05
	o Added RFC 2119 language to the specification of the required		o Added RFC 2119 language to the specification of the required
	behavior of profile specifications.		behavior of profile specifications.
	o Added Section 5.3 on the relation to the OAuth2 grant types.		o Added Section 5.3 on the relation to the OAuth2 grant types.
	o Added CBOR abbreviations for error and the error codes defined in		o Added CBOR abbreviations for error and the error codes defined in
	OAuth2.		OAuth2.
	o Added clarification about token expiration and long-running		o Added clarification about token expiration and long-running
	requests in Section 5.8.3		requests in Section 5.8.3
	o Added security considerations about tokens with symmetric pop keys		o Added security considerations about tokens with symmetric pop keys
	valid for more than one RS.		valid for more than one RS.
	o Added privacy considerations section.		o Added privacy considerations section.
	o Added IANA registry mapping the confirmation types from RFC 7800		o Added IANA registry mapping the confirmation types from RFC 7800
	to equivalent COSE types.		to equivalent COSE types.
	o Added appendix D, describing assumptions about what the AS knows		o Added appendix D, describing assumptions about what the AS knows
	about the client and the RS.		about the client and the RS.
	F.11. Version -03 to -04		F.12. Version -03 to -04
	o Added a description of the terms "framework" and "profiles" as		o Added a description of the terms "framework" and "profiles" as
	used in this document.		used in this document.
	o Clarified protection of access tokens in section 3.1.		o Clarified protection of access tokens in section 3.1.
	o Clarified uses of the "cnf" parameter in section 6.4.5.		o Clarified uses of the "cnf" parameter in section 6.4.5.
	o Clarified intended use of Client Token in section 7.4.		o Clarified intended use of Client Token in section 7.4.
	F.12. Version -02 to -03		F.13. Version -02 to -03
	o Removed references to draft-ietf-oauth-pop-key-distribution since		o Removed references to draft-ietf-oauth-pop-key-distribution since
	the status of this draft is unclear.		the status of this draft is unclear.
	o Copied and adapted security considerations from draft-ietf-oauth-		o Copied and adapted security considerations from draft-ietf-oauth-
	pop-key-distribution.		pop-key-distribution.
	o Renamed "client information" to "RS information" since it is		o Renamed "client information" to "RS information" since it is
	information about the RS.		information about the RS.
	o Clarified the requirements on profiles of this framework.		o Clarified the requirements on profiles of this framework.
	o Clarified the token endpoint protocol and removed negotiation of		o Clarified the token endpoint protocol and removed negotiation of
	"profile" and "alg" (section 6).		"profile" and "alg" (section 6).
	o Renumbered the abbreviations for claims and parameters to get a		o Renumbered the abbreviations for claims and parameters to get a
	consistent numbering across different endpoints.		consistent numbering across different endpoints.
	o Clarified the introspection endpoint.		o Clarified the introspection endpoint.
	o Renamed token, introspection and authz-info to "endpoint" instead		o Renamed token, introspection and authz-info to "endpoint" instead
	of "resource" to mirror the OAuth 2.0 terminology.		of "resource" to mirror the OAuth 2.0 terminology.
	o Updated the examples in the appendices.		o Updated the examples in the appendices.
	F.13. Version -01 to -02		F.14. Version -01 to -02
	o Restructured to remove communication security parts. These shall		o Restructured to remove communication security parts. These shall
	now be defined in profiles.		now be defined in profiles.
	o Restructured section 5 to create new sections on the OAuth		o Restructured section 5 to create new sections on the OAuth
	endpoints token, introspection and authz-info.		endpoints token, introspection and authz-info.
	o Pulled in material from draft-ietf-oauth-pop-key-distribution in		o Pulled in material from draft-ietf-oauth-pop-key-distribution in
	order to define proof-of-possession key distribution.		order to define proof-of-possession key distribution.
	o Introduced the "cnf" parameter as defined in RFC7800 to reference		o Introduced the "cnf" parameter as defined in RFC7800 to reference
	or transport keys used for proof of possession.		or transport keys used for proof of possession.
	o Introduced the "client-token" to transport client information from		o Introduced the "client-token" to transport client information from
	the AS to the client via the RS in conjunction with introspection.		the AS to the client via the RS in conjunction with introspection.
	o Expanded the IANA section to define parameters for token request,		o Expanded the IANA section to define parameters for token request,
	introspection and CWT claims.		introspection and CWT claims.
	o Moved deployment scenarios to the appendix as examples.		o Moved deployment scenarios to the appendix as examples.
	F.14. Version -00 to -01		F.15. Version -00 to -01
	o Changed 5.1. from "Communication Security Protocol" to "Client		o Changed 5.1. from "Communication Security Protocol" to "Client
	Information".		Information".
	o Major rewrite of 5.1 to clarify the information exchanged between		o Major rewrite of 5.1 to clarify the information exchanged between
	C and AS in the PoP access token request profile for IoT.		C and AS in the PoP access token request profile for IoT.
	* Allow the client to indicate preferences for the communication		* Allow the client to indicate preferences for the communication
	security protocol.		security protocol.
	* Defined the term "Client Information" for the additional		* Defined the term "Client Information" for the additional
	information returned to the client in addition to the access		information returned to the client in addition to the access
	skipping to change at page 68, line 41 ¶		skipping to change at page 68, line 47 ¶
	o 5.3.2. Defined success and error responses from the RS when		o 5.3.2. Defined success and error responses from the RS when
	receiving an access token.		receiving an access token.
	o 5.6.:Added section giving guidance on how to handle token		o 5.6.:Added section giving guidance on how to handle token
	expiration in the absence of reliable time.		expiration in the absence of reliable time.
	o Appendix B Added list of roles and responsibilities for C, AS and		o Appendix B Added list of roles and responsibilities for C, AS and
	RS.		RS.
	Authors' Addresses		Authors' Addresses
	Ludwig Seitz		Ludwig Seitz
	RISE SICS		RISE
	Scheelevaegen 17		Scheelevaegen 17
	Lund 223 70		Lund 223 70
	Sweden		Sweden
	Email: ludwig.seitz@ri.se		Email: ludwig.seitz@ri.se
	Goeran Selander		Goeran Selander
	Ericsson		Ericsson
	Faroegatan 6		Faroegatan 6
	Kista 164 80		Kista 164 80
	Sweden		Sweden
End of changes. 60 change blocks.
	108 lines changed or deleted		155 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/