< draft-ietf-ace-oauth-authz-06.txt		draft-ietf-ace-oauth-authz-07.txt >
	ACE Working Group L. Seitz		ACE Working Group L. Seitz
	Internet-Draft RISE SICS		Internet-Draft RISE SICS
	Intended status: Standards Track G. Selander		Intended status: Standards Track G. Selander
	Expires: September 14, 2017 Ericsson		Expires: February 9, 2018 Ericsson
	E. Wahlstroem		E. Wahlstroem
	(no affiliation)		(no affiliation)
	S. Erdtman		S. Erdtman
	Spotify AB		Spotify AB
	H. Tschofenig		H. Tschofenig
	ARM Ltd.		ARM Ltd.
	March 13, 2017		August 8, 2017
	Authentication and Authorization for Constrained Environments (ACE)		Authentication and Authorization for Constrained Environments (ACE)
	draft-ietf-ace-oauth-authz-06		draft-ietf-ace-oauth-authz-07
	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. The		authorization in Internet of Things (IoT) environments. The
	framework is based on a set of building blocks including OAuth 2.0		framework is based on a set of building blocks including OAuth 2.0
	and CoAP, thus making a well-known and widely used authorization		and CoAP, thus making a well-known and widely used authorization
	solution suitable for IoT devices. Existing specifications are used		solution suitable for IoT devices. Existing specifications are used
	where possible, but where the constraints of IoT devices require it,		where possible, but where the constraints of IoT devices require it,
	extensions are added and profiles are defined.		extensions are added and profiles are defined.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at 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 September 14, 2017.		This Internet-Draft will expire on February 9, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 27 ¶		skipping to change at page 2, line 27 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 9		4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 9
	5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 13		5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.1. Authorization Grants . . . . . . . . . . . . . . . . . . 14		5.1. Authorization Grants . . . . . . . . . . . . . . . . . . 14
	5.2. Client Credentials . . . . . . . . . . . . . . . . . . . 15		5.2. Client Credentials . . . . . . . . . . . . . . . . . . . 15
	5.3. AS Authentication . . . . . . . . . . . . . . . . . . . . 15		5.3. AS Authentication . . . . . . . . . . . . . . . . . . . . 15
	5.4. The 'Authorize' Endpoint . . . . . . . . . . . . . . . . 15		5.4. The 'Authorize' Endpoint . . . . . . . . . . . . . . . . 16
	5.5. The 'Token' Endpoint . . . . . . . . . . . . . . . . . . 16		5.5. The 'Token' Endpoint . . . . . . . . . . . . . . . . . . 16
	5.5.1. Client-to-AS Request . . . . . . . . . . . . . . . . 16		5.5.1. Client-to-AS Request . . . . . . . . . . . . . . . . 16
	5.5.2. AS-to-Client Response . . . . . . . . . . . . . . . . 19		5.5.2. AS-to-Client Response . . . . . . . . . . . . . . . . 19
	5.5.3. Error Response . . . . . . . . . . . . . . . . . . . 21		5.5.3. Error Response . . . . . . . . . . . . . . . . . . . 21
	5.5.4. Request and Response Parameters . . . . . . . . . . . 21		5.5.4. Request and Response Parameters . . . . . . . . . . . 22
	5.5.4.1. Audience . . . . . . . . . . . . . . . . . . . . 21		5.5.4.1. Audience . . . . . . . . . . . . . . . . . . . . 22
	5.5.4.2. Grant Type . . . . . . . . . . . . . . . . . . . 22		5.5.4.2. Grant Type . . . . . . . . . . . . . . . . . . . 22
	5.5.4.3. Token Type . . . . . . . . . . . . . . . . . . . 22		5.5.4.3. Token Type . . . . . . . . . . . . . . . . . . . 23
	5.5.4.4. Profile . . . . . . . . . . . . . . . . . . . . . 22		5.5.4.4. Profile . . . . . . . . . . . . . . . . . . . . . 23
	5.5.4.5. Confirmation . . . . . . . . . . . . . . . . . . 23		5.5.4.5. Confirmation . . . . . . . . . . . . . . . . . . 23
	5.5.5. Mapping parameters to CBOR . . . . . . . . . . . . . 25		5.5.5. Mapping parameters to CBOR . . . . . . . . . . . . . 26
	5.6. The 'Introspect' Endpoint . . . . . . . . . . . . . . . . 25		5.6. The 'Introspect' Endpoint . . . . . . . . . . . . . . . . 26
	5.6.1. RS-to-AS Request . . . . . . . . . . . . . . . . . . 26		5.6.1. RS-to-AS Request . . . . . . . . . . . . . . . . . . 27
	5.6.2. AS-to-RS Response . . . . . . . . . . . . . . . . . . 26		5.6.2. AS-to-RS Response . . . . . . . . . . . . . . . . . . 27
	5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 28		5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 28
	5.6.4. Client Token . . . . . . . . . . . . . . . . . . . . 28		5.6.4. Client Token . . . . . . . . . . . . . . . . . . . . 29
	5.6.5. Mapping Introspection parameters to CBOR . . . . . . 30		5.6.5. Mapping Introspection parameters to CBOR . . . . . . 31
	5.7. The Access Token . . . . . . . . . . . . . . . . . . . . 30		5.7. The Access Token . . . . . . . . . . . . . . . . . . . . 31
	5.7.1. The 'Authorization Information' Endpoint . . . . . . 31		5.7.1. The 'Authorization Information' Endpoint . . . . . . 32
	5.7.2. Token Expiration . . . . . . . . . . . . . . . . . . 31		5.7.2. Token Expiration . . . . . . . . . . . . . . . . . . 32
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 32		6. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	8.1. OAuth Introspection Response Parameter Registration . . . 34		8.1. OAuth Introspection Response Parameter Registration . . . 35
	8.2. OAuth Parameter Registration . . . . . . . . . . . . . . 35		8.2. OAuth Parameter Registration . . . . . . . . . . . . . . 36
	8.3. OAuth Access Token Types . . . . . . . . . . . . . . . . 35		8.3. OAuth Access Token Types . . . . . . . . . . . . . . . . 36
	8.4. Token Type Mappings . . . . . . . . . . . . . . . . . . . 36		8.4. Token Type Mappings . . . . . . . . . . . . . . . . . . . 36
	8.4.1. Registration Template . . . . . . . . . . . . . . . . 36		8.4.1. Registration Template . . . . . . . . . . . . . . . . 37
	8.4.2. Initial Registry Contents . . . . . . . . . . . . . . 36		8.4.2. Initial Registry Contents . . . . . . . . . . . . . . 37
	8.5. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 36		8.5. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 37
	8.6. ACE Profile Registry . . . . . . . . . . . . . . . . . . 37		8.6. ACE Profile Registry . . . . . . . . . . . . . . . . . . 38
	8.6.1. Registration Template . . . . . . . . . . . . . . . . 37		8.6.1. Registration Template . . . . . . . . . . . . . . . . 38
	8.7. OAuth Parameter Mappings Registry . . . . . . . . . . . . 37		8.7. OAuth Parameter Mappings Registry . . . . . . . . . . . . 38
	8.7.1. Registration Template . . . . . . . . . . . . . . . . 37		8.7.1. Registration Template . . . . . . . . . . . . . . . . 38
	8.7.2. Initial Registry Contents . . . . . . . . . . . . . . 38		8.7.2. Initial Registry Contents . . . . . . . . . . . . . . 39
	8.8. Introspection Endpoint CBOR Mappings Registry . . . . . . 40		8.8. Introspection Endpoint CBOR Mappings Registry . . . . . . 41
	8.8.1. Registration Template . . . . . . . . . . . . . . . . 40		8.8.1. Registration Template . . . . . . . . . . . . . . . . 41
	8.8.2. Initial Registry Contents . . . . . . . . . . . . . . 40		8.8.2. Initial Registry Contents . . . . . . . . . . . . . . 41
	8.9. CoAP Option Number Registration . . . . . . . . . . . . . 42		8.9. CoAP Option Number Registration . . . . . . . . . . . . . 43
	8.10. CWT Confirmation Methods Registry . . . . . . . . . . . . 43		8.10. CWT Confirmation Methods Registry . . . . . . . . . . . . 44
	8.10.1. Registration Template . . . . . . . . . . . . . . . 43		8.10.1. Registration Template . . . . . . . . . . . . . . . 44
	8.10.2. Initial Registry Contents . . . . . . . . . . . . . 44		8.10.2. Initial Registry Contents . . . . . . . . . . . . . 45
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
	10.1. Normative References . . . . . . . . . . . . . . . . . . 45		10.1. Normative References . . . . . . . . . . . . . . . . . . 45
	10.2. Informative References . . . . . . . . . . . . . . . . . 45		10.2. Informative References . . . . . . . . . . . . . . . . . 46
	Appendix A. Design Justification . . . . . . . . . . . . . . . . 47		Appendix A. Design Justification . . . . . . . . . . . . . . . . 48
	Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 49		Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 50
	Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 51		Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 52
	Appendix D. Assumptions on AS knowledge about C and RS . . . . . 52		Appendix D. Assumptions on AS knowledge about C and RS . . . . . 53
	Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 52		Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 53
	E.1. Local Token Validation . . . . . . . . . . . . . . . . . 53		E.1. Local Token Validation . . . . . . . . . . . . . . . . . 53
	E.2. Introspection Aided Token Validation . . . . . . . . . . 56		E.2. Introspection Aided Token Validation . . . . . . . . . . 57
	Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 60		Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 61
	F.1. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 60		F.1. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 61
	F.2. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 60		F.2. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 61
	F.3. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 61		F.3. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 61
	F.4. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 61		F.4. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 62
	F.5. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 61		F.5. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 62
	F.6. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 62		F.6. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 62
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62		F.7. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 63
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
	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 is a complex		authorization for a large number of devices and users is a complex
	task.		task.
	skipping to change at page 4, line 34 ¶		skipping to change at page 4, line 34 ¶
	OAuth 2.0 [RFC6749], thereby extending authorization to Internet of		OAuth 2.0 [RFC6749], thereby extending authorization to Internet of
	Things devices. This specification contains the necessary building		Things devices. This specification contains the necessary building
	blocks for adjusting OAuth 2.0 to IoT environments.		blocks for adjusting OAuth 2.0 to IoT environments.
	More detailed, interoperable specifications can be found in profiles.		More detailed, interoperable specifications can be found in profiles.
	Implementations may claim conformance with a specific profile,		Implementations may claim conformance with a specific profile,
	whereby implementations utilizing the same profile interoperate while		whereby implementations utilizing the same profile interoperate while
	implementations of different profiles are not expected to be		implementations of different profiles are not expected to be
	interoperable. Some devices, such as mobile phones and tablets, may		interoperable. Some devices, such as mobile phones and tablets, may
	implement multiple profiles and will therefore be able to interact		implement multiple profiles and will therefore be able to interact
	with a wider range of low end devices.		with a wider range of low end devices. Requirements on profiles are
			described at contextually appropriate places througout this memo, and
			also summarized in Appendix C.
	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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	Certain security-related terms such as "authentication",		Certain security-related terms such as "authentication",
	"authorization", "confidentiality", "(data) integrity", "message		"authorization", "confidentiality", "(data) integrity", "message
	skipping to change at page 5, line 49 ¶		skipping to change at page 6, line 6 ¶
	underlying protocols to be supported in the future, such as HTTP/2,		underlying protocols to be supported in the future, such as HTTP/2,
	MQTT and QUIC.		MQTT and QUIC.
	A third building block is CBOR [RFC7049] for encodings where JSON		A third building block is CBOR [RFC7049] for encodings where JSON
	[RFC7159] is not sufficiently compact. CBOR is a binary encoding		[RFC7159] is not sufficiently compact. CBOR is a binary encoding
	designed for small code and message size, which may be used for		designed for small code and message size, which may be used for
	encoding of self contained tokens, and also for encoding CoAP POST		encoding of self contained tokens, and also for encoding CoAP POST
	parameters and CoAP responses.		parameters and CoAP responses.
	A fourth building block is the compact CBOR-based secure message		A fourth building block is the compact CBOR-based secure message
	format COSE [I-D.ietf-cose-msg], which enables application layer		format COSE [RFC8152], which enables application layer security as an
	security as an alternative or complement to transport layer security		alternative or complement to transport layer security (DTLS [RFC6347]
	(DTLS [RFC6347] or TLS [RFC5246]). COSE is used to secure self		or TLS [RFC5246]). COSE is used to secure self contained tokens such
	contained tokens such as proof-of-possession (PoP) tokens, which is		as proof-of-possession (PoP) tokens, which is an extension to the
	an extension to the OAuth access tokens, and "client tokens" which		OAuth access tokens, and "client tokens" which are defined in this
	are defined in this framework (see Section 5.6.4). The default		framework (see Section 5.6.4). The default access token format is
	access token format is defined in CBOR web token (CWT)		defined in CBOR web token (CWT) [I-D.ietf-ace-cbor-web-token].
	[I-D.ietf-ace-cbor-web-token]. Application layer security for CoAP		Application layer security for CoAP using COSE can be provided with
	using COSE can be provided with OSCOAP		OSCOAP [I-D.ietf-core-object-security].
	[I-D.ietf-core-object-security].
	With the building blocks listed above, solutions satisfying various		With the building blocks listed above, solutions satisfying various
	IoT device and network constraints are possible. A list of		IoT device and network constraints are possible. A list of
	constraints is described in detail in RFC 7228 [RFC7228] and a		constraints is described in detail in RFC 7228 [RFC7228] and a
	description of how the building blocks mentioned above relate to the		description of how the building blocks mentioned above relate to the
	various constraints can be found in Appendix A.		various constraints can be found in Appendix A.
	Luckily, not every IoT device suffers from all constraints. The ACE		Luckily, not every IoT device suffers from all constraints. The ACE
	framework nevertheless takes all these aspects into account and		framework nevertheless takes all these aspects into account and
	allows several different deployment variants to co-exist rather than		allows several different deployment variants to co-exist rather than
	skipping to change at page 8, line 4 ¶		skipping to change at page 8, line 8 ¶
	Symmetric PoP key: The AS generates a random symmetric PoP key.		Symmetric PoP key: The AS generates a random symmetric PoP key.
	The key is either stored to be returned on introspection calls		The key is either stored to be returned on introspection calls
	or encrypted and included in the access token. The PoP key is		or encrypted and included in the access token. The PoP key is
	also encrypted for the client and sent together with the access		also encrypted for the client and sent together with the access
	token to the client.		token to the client.
	Asymmetric PoP key: An asymmetric key pair is generated on the		Asymmetric PoP key: An asymmetric key pair is generated on the
	client and the public key is sent to the AS (if it does not		client and the public key is sent to the AS (if it does not
	already have knowledge of the client's public key).		already have knowledge of the client's public key).
	Information about the public key, which is the PoP key in this		Information about the public key, which is the PoP key in this
	case, is either stored to be returned on introspection calls or		case, is either stored to be returned on introspection calls or
	included inside the access token and sent back to the		included inside the access token and sent back to the
	requesting client. The RS can identify the client's public key		requesting client. The RS can identify the client's public key
	from the information in the token, which allows the client to		from the information in the token, which allows the client to
	use the corresponding private key for the proof of possession.		use the corresponding private key for the proof of possession.
	The access token is either a simple reference, or a structured		The access token is either a simple reference, or a structured
	information object (e.g. CWT [I-D.ietf-ace-cbor-web-token]),		information object (e.g. CWT [I-D.ietf-ace-cbor-web-token]),
	protected by a cryptographic wrapper (e.g. COSE		protected by a cryptographic wrapper (e.g. COSE [RFC8152]). The
	[I-D.ietf-cose-msg]). The choice of PoP key does not necessarily		choice of PoP key does not necessarily imply a specific credential
	imply a specific credential type for the integrity protection of		type for the integrity protection of the token.
	the token.
	Scopes and Permissions:		Scopes and Permissions:
	In OAuth 2.0, the client specifies the type of permissions it is		In OAuth 2.0, the client specifies the type of permissions it is
	seeking to obtain (via the scope parameter) in the access token		seeking to obtain (via the scope parameter) in the access token
	request. In turn, the AS may use the scope response parameter to		request. In turn, the AS may use the scope response parameter to
	inform the client of the scope of the access token issued. As the		inform the client of the scope of the access token issued. As the
	client could be a constrained device as well, this specification		client could be a constrained device as well, this specification
	uses CBOR encoded messages for CoAP, defined in Section 5, to		uses CBOR encoded messages for CoAP, defined in Section 5, to
	request scopes and to be informed what scopes the access token was		request scopes and to be informed what scopes the access token
	actually authorized for by the AS.		actually authorizes.
	The values of the scope parameter are expressed as a list of		The values of the scope parameter are expressed as a list of
	space- delimited, case-sensitive strings, with a semantic that is		space- delimited, case-sensitive strings, with a semantic that is
	well-known to the AS and the RS. More details about the concept		well-known to the AS and the RS. More details about the concept
	of scopes is found under Section 3.3 in [RFC6749].		of scopes is found under Section 3.3 in [RFC6749].
	Claims:		Claims:
	Information carried in the access token or returned from		Information carried in the access token or returned from
	introspection, called claims, is in the form of type-value pairs.		introspection, called claims, is in the form of type-value pairs.
	skipping to change at page 9, line 37 ¶		skipping to change at page 9, line 39 ¶
	does not increase the size limits of CoAP options, therefore data		does not increase the size limits of CoAP options, therefore data
	encoded in options has to be kept small.		encoded in options has to be kept small.
	Transport layer security for CoAP can be provided by DTLS 1.2		Transport layer security for CoAP can be provided by DTLS 1.2
	[RFC6347] or TLS 1.2 [RFC5246]. CoAP defines a number of proxy		[RFC6347] or TLS 1.2 [RFC5246]. CoAP defines a number of proxy
	operations which requires transport layer security to be terminated		operations which requires transport layer security to be terminated
	at the proxy. One approach for protecting CoAP communication end-to-		at the proxy. One approach for protecting CoAP communication end-to-
	end through proxies, and also to support security for CoAP over a		end through proxies, and also to support security for CoAP over a
	different transport in a uniform way, is to provide security on		different transport in a uniform way, is to provide security on
	application layer using an object-based security mechanism such as		application layer using an object-based security mechanism such as
	COSE [I-D.ietf-cose-msg].		COSE [RFC8152].
	One application of COSE is OSCOAP [I-D.ietf-core-object-security],		One application of COSE is OSCOAP [I-D.ietf-core-object-security],
	which provides end-to-end confidentiality, integrity and replay		which provides end-to-end confidentiality, integrity and replay
	protection, and a secure binding between CoAP request and response		protection, and a secure binding between CoAP request and response
	messages. In OSCOAP, the CoAP messages are wrapped in COSE objects		messages. In OSCOAP, the CoAP messages are wrapped in COSE objects
	and sent using CoAP.		and sent using CoAP.
	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
	skipping to change at page 10, line 15 ¶		skipping to change at page 10, line 17 ¶
	token locally without the need to contact an AS. These interactions		token locally without the need to contact an AS. These interactions
	are shown in Figure 1. An overview of various OAuth concepts is		are shown in Figure 1. An overview of various OAuth concepts is
	provided in Section 3.1.		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 RFC 7521) and		Authorization Code Grant (described in Section 4.1 of [RFC7521]) and
	the Client Credentials Grant (described in Section 4.4 of RFC 7521).		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
	on smart phones and tablets that request access to IoT devices, a		on smart phones and tablets that request access to IoT devices, a
	common scenario in the smart home environment, where users need to go		common scenario in the smart home environment, where users need to go
	through an authentication and authorization phase (at least during		through an authentication and authorization phase (at least during
	the initial setup phase). The native apps guidelines described in		the initial setup phase). The native apps guidelines described in
	[I-D.ietf-oauth-native-apps] are applicable to this use case. The		[I-D.ietf-oauth-native-apps] are applicable to this use case. The
	Client Credential Grant is a good fit for use with IoT devices where		Client Credential Grant is a good fit for use with IoT devices where
	the OAuth client itself is constrained. In such a case the resource		the OAuth client itself is constrained. In such a case the resource
	owner or another person on his or her behalf have arranged with the		owner or another person on his or her behalf have arranged with the
	authorization server out-of-band, which is often accomplished using a		authorization server out-of-band, which is often accomplished using a
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 10 ¶
	To request an access token, the client obtains authorization from the		To request an access token, the client obtains authorization from the
	resource owner or uses its client credentials as grant. The		resource owner or uses its client credentials as grant. The
	authorization is expressed in the form of an authorization grant.		authorization is expressed in the form of an authorization grant.
	The OAuth framework defines four grant types. The grant types can be		The OAuth framework defines four grant types. The grant types can be
	split up into two groups, those granted on behalf of the resource		split up into two groups, those granted on behalf of the resource
	owner (password, authorization code, implicit) and those for the		owner (password, authorization code, implicit) and those for the
	client (client credentials).		client (client credentials).
	The grant type selected depending based on the use case. In cases		The grant type is selected depending on the use case. In cases where
	where the client will act on behalf of the resource owner,		the client acts on behalf of the resource owner, authorization code
	authorization code grant is recommended. If the client should to act		grant is recommended. If the client acts on behalf of the resource
	on be half of the user but does not have any display or very limited		owner, but does not have any display or very limited interaction
	interaction possibilities it is recommended to use the device code		possibilities it is recommended to use the device code grant defined
	grant defined in [I-D.ietf-oauth-device-flow]. In cases where the		in [I-D.ietf-oauth-device-flow]. In cases where the client does not
	client will not act on be half of the resource owner, client		act on behalf of the resource owner, client credentials grant is
	credentials grant is recommended.		recommended.
	For details on the different grant types see the OAuth 2.0 framework.		For details on the different grant types see the OAuth 2.0 framework.
	The OAuth 2.0 framework provides an extension mechanism for defining		The OAuth 2.0 framework provides an extension mechanism for defining
	additional grant types so profiles of this framework MAY define		additional grant types so profiles of this framework MAY define
	additional grant types if needed.		additional grant types if needed.
	5.2. Client Credentials		5.2. Client Credentials
	Authentication of the client is mandatory independent of the grant		Authentication of the client is mandatory independent of the grant
	type when requesting the access token from the token endpoint. In		type when requesting the access token from the token endpoint. In
	skipping to change at page 15, line 47 ¶		skipping to change at page 16, line 8 ¶
	client connects to. In classic OAuth the AS is authenticated with a		client connects to. In classic OAuth the AS is authenticated with a
	TLS server certificate.		TLS server certificate.
	Profiles of this framework SHOULD specify how clients authenticate		Profiles of this framework SHOULD specify how clients authenticate
	the AS and how communication security is implemented, otherwise		the AS and how communication security is implemented, otherwise
	server side TLS certificates as defined by OAuth 2.0 is required.		server side TLS certificates as defined by OAuth 2.0 is required.
	5.4. The 'Authorize' Endpoint		5.4. The 'Authorize' Endpoint
	The authorization endpoint is used to interact with the resource		The authorization endpoint is used to interact with the resource
	owner and obtain an authorization grant. It is used for		owner and obtain an authorization grant in certain grant flows.
	authorization code and implicit grant, flows that requires online		Since it requires the use of a user agent (i.e. browser), it is not
	user consent. In the most common implementation a users-agent is		expected that these types of grant flow will be used by constrained
	used and redirected from the client to the AS. The AS shows a		clients. This endpoint is therefore out of scope for this
	consent dialog and directs back to the client, with the approved		specification. Implementations should use the definition and
	grant or an error message.		recommendations of [RFC6749] and [RFC6819].
	The grant types defined in OAuth 2.0, that use the authorization
	endpoint, require the use of a user agent (i.e. a browser). This
	endpoint is therefore out of scope for this specification.
	Implementations should use the definition and recommendations of
	[RFC6749] and [RFC6819].
	If clients involved cannot support HTTP and TLS profiles MAY define		If clients involved cannot support HTTP and TLS profiles MAY define
	mappings for the authorization endpoint.		mappings for the authorization endpoint.
	5.5. The 'Token' Endpoint		5.5. The 'Token' Endpoint
	In plain OAuth 2.0 the AS provides the /token endpoint for submitting		In plain OAuth 2.0 the AS provides the /token endpoint for submitting
	access token requests. This framework extends the functionality of		access token requests. This framework extends the functionality of
	the /token endpoint, giving the AS the possibility to help client and		the /token endpoint, giving the AS the possibility to help client and
	RS to establish shared keys or to exchange their public keys.		RS to establish shared keys or to exchange their public keys.
	skipping to change at page 17, line 6 ¶		skipping to change at page 17, line 10 ¶
	assumed that the client and the AS have a pre-established		assumed that the client and the AS have a pre-established
	understanding of the audience that an access token should address.		understanding of the audience that an access token should address.
	If a client submits a request for an access token without		If a client submits a request for an access token without
	specifying an "aud" parameter, and the AS does not have a default		specifying an "aud" parameter, and the AS does not have a default
	"aud" value for this client, then the AS MUST respond with an		"aud" value for this client, then the AS MUST respond with an
	error message with the CoAP response code 4.00 (Bad Request).		error message with the CoAP response code 4.00 (Bad Request).
	cnf		cnf
	OPTIONAL. This field contains information about the key the		OPTIONAL. This field contains information about the key the
	client would like to bind to the access token for proof-of-		client would like to bind to the access token for proof-of-
	possession. It is NOT RECOMMENDED that a client submits a		possession. It is RECOMMENDED that an AS reject a request
	symmetric key value to the AS using this parameter. See		containing a symmetric key value in the 'cnf' field. See
	Section 5.5.4.5 for more details on the formatting of the 'cnf'		Section 5.5.4.5 for more details on the formatting of the 'cnf'
	parameter.		parameter.
	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 2 shows a request for a token with a symmetric proof-of-		Figure 2 shows a request for a token with a symmetric proof-of-
	possession key. Note that in this example we assume a DTLS-based		possession key. Note that in this example we assume a DTLS-based
	communication security profile, therefore the Content-Type is		communication security profile, therefore the Content-Type is
	"application/cbor". The content is displayed in CBOR diagnostic		"application/cbor". The content is displayed in CBOR diagnostic
	skipping to change at page 17, line 36 ¶		skipping to change at page 17, line 40 ¶
	"grant_type" : "client_credentials",		"grant_type" : "client_credentials",
	"aud" : "tempSensor4711",		"aud" : "tempSensor4711",
	}		}
	Figure 2: Example request for an access token bound to a symmetric		Figure 2: Example request for an access token bound to a symmetric
	key.		key.
	Figure 3 shows a request for a token with an asymmetric proof-of-		Figure 3 shows a request for a token with an asymmetric proof-of-
	possession key. Note that in this example we assume an object		possession key. Note that in this example we assume an object
	security-based profile, therefore the Content-Type is "application/		security-based profile, therefore the Content-Type is "application/
	cose+cbor".		cose".
	Header: POST (Code=0.02)		Header: POST (Code=0.02)
	Uri-Host: "server.example.com"		Uri-Host: "server.example.com"
	Uri-Path: "token"		Uri-Path: "token"
	Content-Type: "application/cose+cbor"		Content-Type: "application/cose"
	Payload:		Payload:
			"COSE_Encrypted" : {
			16(
			[ h'a1010a', # protected header: {"alg" : "AES-CCM-16-64-128"}
			{5 : b64'ifUvZaHFgJM7UmGnjA'}, # unprotected header, IV
			b64'WXThuZo6TMCaZZqi6ef/8WHTjOdGk8kNzaIhIQ' # ciphertext
			]
			)
			}
			Decrypted payload:
	{		{
	"grant_type" : "client_credentials",		"grant_type" : "client_credentials",
	"client_id" : "myclient",
	"client_secret" : "mysecret234",
	"cnf" : {		"cnf" : {
	"COSE_Key" : {		"COSE_Key" : {
	"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 3: Example request for an access token bound to an asymmetric		Figure 3: Example token request bound to an asymmetric key.
	key.
	Figure 4 shows a request for a token where a previously communicated		Figure 4 shows a request for a token where a previously communicated
	proof-of-possession key is only referenced. Note that we assume a		proof-of-possession key is only referenced. Note that we assume a
	DTLS-based communication security profile for this example, therefore		DTLS-based communication security profile for this example, therefore
	the Content-Type is "application/cbor". Also note that the client		the Content-Type is "application/cbor". Also note that the client
	performs a password based authentication in this example by		performs a password based authentication in this example by
	submitting its client_secret (see section 2.3.1. of [RFC6749]).		submitting its client_secret (see section 2.3.1. of [RFC6749]).
	Header: POST (Code=0.02)		Header: POST (Code=0.02)
	Uri-Host: "server.example.com"		Uri-Host: "server.example.com"
	skipping to change at page 20, line 20 ¶		skipping to change at page 20, line 38 ¶
	| 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 |
	| profile | [[ this specification ]] |		| profile | [[ this specification ]] |
	| cnf | [[ this specification ]] |		| cnf | [[ this specification ]] |
	\-------------------+--------------------------/		\-------------------+--------------------------/
	Figure 5: RS Information parameters		Figure 5: RS Information parameters
	The following examples illustrate different types of responses for
	proof-of-possession tokens.
	Figure 6 shows a response containing a token and a 'cnf' parameter		Figure 6 shows a response containing a token and a 'cnf' parameter
	with a symmetric proof-of-possession key. Note that we assume a		with a symmetric proof-of-possession key. Note that we assume a
	DTLS-based communication security profile for this example, therefore		DTLS-based communication security profile for this example, therefore
	the Content-Type is "application/cbor".		the Content-Type is "application/cbor".
	Header: Created (Code=2.01)		Header: Created (Code=2.01)
	Content-Type: "application/cbor"		Content-Type: "application/cbor"
	Payload:		Payload:
	{		{
	"access_token" : b64'SlAV32hkKG ...		"access_token" : b64'SlAV32hkKG ...
	skipping to change at page 21, line 33 ¶		skipping to change at page 22, line 14 ¶
	/------------------------+----------+--------------\		/------------------------+----------+--------------\
	| error code | CBOR Key | Major Type |		| error code | CBOR Key | Major Type |
	|------------------------+----------+--------------|		|------------------------+----------+--------------|
	| invalid_request | 0 | 0 (uint) |		| invalid_request | 0 | 0 (uint) |
	| invalid_client | 1 | 0 |		| invalid_client | 1 | 0 |
	| invalid_grant | 2 | 0 |		| invalid_grant | 2 | 0 |
	| unauthorized_client | 3 | 0 |		| unauthorized_client | 3 | 0 |
	| unsupported_grant_type | 4 | 0 |		| unsupported_grant_type | 4 | 0 |
	| invalid_scope | 5 | 0 |		| invalid_scope | 5 | 0 |
			| unsupported_pop_key | 6 | 0 |
	\------------------------+----------+--------------/		\------------------------+----------+--------------/
	Figure 7: CBOR abbreviations for common error codes		Figure 7: CBOR abbreviations for common error codes
			In addition to the error responses defined in OAuth 2.0, the
			follwoing behaviour MUST be implemented by the AS: If the client
			submits an asymmetric key in the token request that the RS cannot
			process, the AS MUST reject that request with the CoAP response code
			4.00 (Bad Request) with the error code "unsupported_pop_key" defined
			in figure Figure 7.
	5.5.4. Request and Response Parameters		5.5.4. Request and Response Parameters
	This section provides more detail about the new parameters that can		This section provides more detail about the new parameters that can
	be used in access token requests and responses, as well as		be used in access token requests and responses, as well as
	abbreviations for more compact encoding of existing parameters and		abbreviations for more compact encoding of existing parameters and
	common parameter values.		common parameter values.
	5.5.4.1. Audience		5.5.4.1. Audience
	This parameter specifies for which audience the client is requesting		This parameter specifies for which audience the client is requesting
	skipping to change at page 29, line 51 ¶		skipping to change at page 30, line 51 ¶
	OPTIONAL. Contains information about the key that the RS uses to		OPTIONAL. Contains information about the key that the RS uses to
	authenticate towards the client. If the key is symmetric then		authenticate towards the client. If the key is symmetric then
	this claim MUST NOT be part of the Client Token, since this is the		this claim MUST NOT be part of the Client Token, since this is the
	same key as the one specified through the 'cnf' claim. This claim		same key as the one specified through the 'cnf' claim. This claim
	uses the same encoding as the 'cnf' parameter. See		uses the same encoding as the 'cnf' parameter. See
	Section 5.5.4.4.		Section 5.5.4.4.
	The AS encrypts this token using a key shared between the AS and the		The AS encrypts this token using a key shared between the AS and the
	client, so that only the client can decrypt it and access its		client, so that only the client can decrypt it and access its
	payload. How this key is established is out of scope of this		payload. How this key is established is out of scope of this
	framework.		framework, however it can be established at the same time at which
			the client's long term token is created.
	5.6.5. Mapping Introspection parameters to CBOR		5.6.5. Mapping Introspection parameters to CBOR
	The introspection request and response parameters are mapped to CBOR		The introspection request and response parameters are mapped to CBOR
	types as follows and are given an integer key value to save space.		types as follows and are given an integer key value to save space.
	/-----------------+----------+-----------------\		/-----------------+----------+-----------------\
	| Parameter name | CBOR Key | Major Type |		| Parameter name | CBOR Key | Major Type |
	|-----------------+----------+-----------------|		|-----------------+----------+-----------------|
	| iss | 1 | 3 (text string) |		| iss | 1 | 3 (text string) |
	skipping to change at page 30, line 49 ¶		skipping to change at page 31, line 49 ¶
	In order to facilitate offline processing of access tokens, this		In order to facilitate offline processing of access tokens, this
	draft specifies the "cnf" and "scope" claims for CBOR web tokens.		draft specifies the "cnf" and "scope" claims for CBOR web tokens.
	The "scope" claim explicitly encodes the scope of a given access		The "scope" claim explicitly encodes the scope of a given access
	token. This claim follows the same encoding rules as defined in		token. This claim follows the same encoding rules as defined in
	section 3.3 of [RFC6749]. The meaning of a specific scope value is		section 3.3 of [RFC6749]. The meaning of a specific scope value is
	application specific and expected to be known to the RS running that		application specific and expected to be known to the RS running that
	application.		application.
	The "cnf" claim follows the same rules as specified for JSON web		The "cnf" claim follows the same rules as specified for JOSE web
	token in RFC7800 [RFC7800], except that it is encoded in CBOR in the		token in RFC7800 [RFC7800], except that it is encoded in COSE in the
	same way as specified for the "cnf" parameter in Section 5.5.4.5.		same way as specified for the "cnf" parameter in Section 5.5.4.5.
	5.7.1. The 'Authorization Information' Endpoint		5.7.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
	skipping to change at page 32, line 37 ¶		skipping to change at page 33, line 37 ¶
	For a constrained RS with no network connectivity and no means of		For a constrained RS with no network connectivity and no means of
	reliably measuring time, this is the best that can be achieved.		reliably measuring time, this is the best that can be achieved.
	If a token, that authorizes a long running request such as e.g. a		If a token, that authorizes a long running request such as e.g. a
	CoAP Observe [RFC7641], expires, the RS MUST send an error response		CoAP Observe [RFC7641], expires, the RS MUST send an error response
	with the response code 4.01 Unauthorized to the client and then		with the response code 4.01 Unauthorized to the client and then
	terminate processing the long running request.		terminate processing the long running request.
	6. Security Considerations		6. Security Considerations
	The entire document is about security. Security considerations		Security considerations applicable to authentication and
	applicable to authentication and authorization in RESTful		authorization in RESTful environments provided in OAuth 2.0 [RFC6749]
	environments provided in OAuth 2.0 [RFC6749] apply to this work, as		apply to this work, as well as the security considerations from
	well as the security considerations from [I-D.ietf-ace-actors].		[I-D.ietf-ace-actors]. Furthermore [RFC6819] provides additional
	Furthermore [RFC6819] provides additional security considerations for		security considerations for OAuth which apply to IoT deployments as
	OAuth which apply to IoT deployments as well.		well.
	A large range of threats can be mitigated by protecting the contents		A large range of threats can be mitigated by protecting the contents
	of the access token by using a digital signature or a keyed message		of the access token by using a digital signature or a keyed message
	digest. Consequently, the token integrity protection MUST be applied		digest (MAC) or an AEAD algorithm. Consequently, the token integrity
	to prevent the token from being modified, particularly since it		protection MUST be applied to prevent the token from being modified,
	contains a reference to the symmetric key or the asymmetric key. If		particularly since it contains a reference to the symmetric key or
	the access token contains the symmetric key, this symmetric key MUST		the asymmetric key. If the access token contains the symmetric key,
	be encrypted by the authorization server with a long-term key shared		this symmetric key MUST be encrypted by the authorization server so
	with the resource server.		that only the resource server can decrypt it. Note that using an
			AEAD algorithm is preferrable over using a MAC unless the message
			needs to be publicly readable.
	It is important for the authorization server to include the identity		It is important for the authorization server to include the identity
	of the intended recipient (the audience), typically a single resource		of the intended recipient (the audience), typically a single resource
	server (or a list of resource servers), in the token. Using a single		server (or a list of resource servers), in the token. Using a single
	shared secret with multiple resource servers to simplify key		shared secret with multiple resource servers to simplify key
	management is NOT RECOMMENDED since the benefit from using the proof-		management is NOT RECOMMENDED since the benefit from using the proof-
	of-possession concept is significantly reduced.		of-possession concept is significantly reduced.
	Token replay is also more difficult since an eavesdropper will have
	to obtain the token and the corresponding private key or shared
	secret that is bound to the access token. Nevertheless, it is good
	practice to limit the lifetime of the access token and therefore the
	lifetime of associated key.
	The authorization server MUST offer confidentiality protection for		The authorization server MUST offer confidentiality protection for
	any interactions with the client. This step is extremely important		any interactions with the client. This step is extremely important
	since the client will obtain the session key from the authorization		since the client may obtion the proof-of-possession key from the
	server for use with a specific access token. Not using		authorization server for use with a specific access token. Not using
	confidentiality protection exposes this secret (and the access token)		confidentiality protection exposes this secret (and the access token)
	to an eavesdropper thereby completely negating proof-of-possession		to an eavesdropper thereby completely negating proof-of-possession
	security. Profiles MUST specify how confidentiality protection is		security. Profiles MUST specify how confidentiality protection is
	provided, and additional protection can be applied by encrypting the		provided, and additional protection can be applied by encrypting the
	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
	[I-D.ietf-ace-cbor-web-token].		[I-D.ietf-ace-cbor-web-token].
	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		Clients can at any time request a new proof-of-possession capable
	access token. Using a refresh token to regularly request new access		access token. If clients have that capability, the AS can keep the
	tokens that are bound to fresh and unique keys is important if the		lifetime of the access token and the associated proof-of-possesion
	client has this capability. Keeping the lifetime of the access token		key short and therefore use shorter proof-of-possession key sizes,
	short allows the authorization server to use shorter key sizes, which		which translate to a performance benefit for the client and for the
	translate to a performance benefit for the client and for the
	resource server. Shorter keys also lead to shorter messages		resource server. Shorter keys also lead to 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 SHOULD NOT apply to an audience that		Furthermore access tokens using symmetric keys for proof-of-
	comprises more than one RS, since otherwise any RS in the audience		possession SHOULD NOT be targeted at an audience that contains more
	can impersonate the client towards the other members of the audience.		than one RS, since otherwise any RS in the audience that receives
			that access token can impersonate the client towards the other
	Clients using an asymmetric key pair for proof-of-possession towards		members of the audience.
	several different RS should be aware that they will need to rotate
	that key pair more frequently than if it was only used towards a
	single RS.
	7. Privacy Considerations		7. Privacy Considerations
	Implementers and users should be aware of the privacy implications of		Implementers and users should be aware of the privacy implications of
	the different possible deployments of this framework.		the different possible deployments of this framework.
	The AS is in a very central position can potentially learn sensitive		The AS is in a very central position can potentially learn sensitive
	information about the clients requesting access tokens. If the		information about the clients requesting access tokens. If the
	client credentials grant is used, the AS can track what kind of		client credentials grant is used, the AS can track what kind of
	access the client intends to perform. With other grants, the		access the client intends to perform. With other grants this can be
	Resource Owner can bind the grants to anonymous (rotating)		prevented by the Resource Owner. To do so the resource owner needs
	credentials, that do not allow the AS to link different access token		to bind the grants it issues to anonymous, ephemeral credentials,
	requests by the same client.		that do not allow the AS to link different grants and thus different
			access token requests by the same client.
	If access tokens are only integrity protected and not encrypted, they		If access tokens are only integrity protected and not encrypted, they
	may reveal information to attackers listening on the wire, or able to		may reveal information to attackers listening on the wire, or able to
	acquire the access tokens in some other way. In the case of CWTs or		acquire the access tokens in some other way. In the case of CWTs or
	JWTs the token may e.g. reveal the audience, the scope and the		JWTs the token may e.g. reveal the audience, the scope and the
	confirmation method used by the client. The latter may reveal the		confirmation method used by the client. The latter may reveal the
	client's identity.		client's identity.
	Clients using asymmetric keys for proof-of-possession should be aware		Clients using asymmetric keys for proof-of-possession should be aware
	of the consequences of using the same key pair for proof-of-		of the consequences of using the same key pair for proof-of-
	skipping to change at page 45, line 4 ¶		skipping to change at page 45, line 43 ¶
	general for their feedback.		general for their feedback.
	We would like to thank the authors of draft-ietf-oauth-pop-key-		We would like to thank the authors of draft-ietf-oauth-pop-key-
	distribution, from where we copied large parts of our security		distribution, from where we copied large parts of our security
	considerations.		considerations.
	Ludwig Seitz and Goeran Selander worked on this document as part of		Ludwig Seitz and Goeran Selander worked on this document as part of
	the CelticPlus project CyberWI, with funding from Vinnova.		the CelticPlus project CyberWI, with funding from Vinnova.
	10. References		10. References
	10.1. Normative References
	[I-D.ietf-cose-msg]		10.1. Normative References
	Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	draft-ietf-cose-msg-24 (work in progress), November 2016.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <http://www.rfc-editor.org/info/rfc6347>.		January 2012, <http://www.rfc-editor.org/info/rfc6347>.
	skipping to change at page 45, line 33 ¶		skipping to change at page 46, line 23 ¶
	[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",		[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
	RFC 7662, DOI 10.17487/RFC7662, October 2015,		RFC 7662, DOI 10.17487/RFC7662, October 2015,
	<http://www.rfc-editor.org/info/rfc7662>.		<http://www.rfc-editor.org/info/rfc7662>.
	[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-		[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
	Possession Key Semantics for JSON Web Tokens (JWTs)",		Possession Key Semantics for JSON Web Tokens (JWTs)",
	RFC 7800, DOI 10.17487/RFC7800, April 2016,		RFC 7800, DOI 10.17487/RFC7800, April 2016,
	<http://www.rfc-editor.org/info/rfc7800>.		<http://www.rfc-editor.org/info/rfc7800>.
			[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
			RFC 8152, DOI 10.17487/RFC8152, July 2017,
			<http://www.rfc-editor.org/info/rfc8152>.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-ace-actors]		[I-D.ietf-ace-actors]
	Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An		Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An
	architecture for authorization in constrained		architecture for authorization in constrained
	environments", draft-ietf-ace-actors-05 (work in		environments", draft-ietf-ace-actors-05 (work in
	progress), March 2017.		progress), March 2017.
	[I-D.ietf-ace-cbor-web-token]		[I-D.ietf-ace-cbor-web-token]
	Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,		Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
	"CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-03		"CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-07
	(work in progress), March 2017.		(work in progress), July 2017.
	[I-D.ietf-core-object-security]		[I-D.ietf-core-object-security]
	Selander, G., Mattsson, J., Palombini, F., and L. Seitz,		Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security of CoAP (OSCOAP)", draft-ietf-core-		"Object Security of CoAP (OSCOAP)", draft-ietf-core-
	object-security-01 (work in progress), December 2016.		object-security-04 (work in progress), July 2017.
	[I-D.ietf-oauth-device-flow]		[I-D.ietf-oauth-device-flow]
	Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,		Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
	"OAuth 2.0 Device Flow for Browserless and Input		"OAuth 2.0 Device Flow for Browserless and Input
	Constrained Devices", draft-ietf-oauth-device-flow-04		Constrained Devices", draft-ietf-oauth-device-flow-06
	(work in progress), February 2017.		(work in progress), May 2017.
	[I-D.ietf-oauth-native-apps]		[I-D.ietf-oauth-native-apps]
	Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",		Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
	draft-ietf-oauth-native-apps-09 (work in progress), March		draft-ietf-oauth-native-apps-12 (work in progress), June
	2017.		2017.
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
	FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,		FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
	<http://www.rfc-editor.org/info/rfc4949>.		<http://www.rfc-editor.org/info/rfc4949>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<http://www.rfc-editor.org/info/rfc5246>.		<http://www.rfc-editor.org/info/rfc5246>.
	skipping to change at page 60, line 30 ¶		skipping to change at page 61, line 30 ¶
	| | Payload: <new state for the lock>		| | Payload: <new state for the lock>
	| |		| |
	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 27: Resource request and response protected by OSCOAP		Figure 27: Resource request and response protected by OSCOAP
	Appendix F. Document Updates		Appendix F. Document Updates
	F.1. Version -05 to -06		F.1. Version -06 to -07
			o Various clarifications added.
			o Fixed erroneous author email.
			F.2. 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.1, and Section 5.2.		sections, Section 5.1, and Section 5.2.
	o Added Section 5.3 on AS authentication.		o Added Section 5.3 on AS authentication.
	o Added Section 5.4 on the Authorize endpoint.		o Added Section 5.4 on the Authorize endpoint.
	F.2. Version -04 to -05		F.3. 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.2 on the relation to the OAuth2 grant types.		o Added Section 5.2 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.7.2		requests in Section 5.7.2
	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.3. Version -03 to -04		F.4. 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.4. Version -02 to -03		F.5. 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.5. Version -01 to -02		F.6. 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, /introspect and /authz-info.		endpoints /token, /introspect 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
	skipping to change at page 61, line 48 ¶		skipping to change at page 63, line 4 ¶
	o Restructured section 5 to create new sections on the OAuth		o Restructured section 5 to create new sections on the OAuth
	endpoints /token, /introspect and /authz-info.		endpoints /token, /introspect 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.6. Version -00 to -01		F.7. 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 token request profile for IoT.		C and AS in the PoP 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 62, line 46 ¶		skipping to change at page 63, line 48 ¶
	RS.		RS.
	Authors' Addresses		Authors' Addresses
	Ludwig Seitz		Ludwig Seitz
	RISE SICS		RISE SICS
	Scheelevaegen 17		Scheelevaegen 17
	Lund 223 70		Lund 223 70
	SWEDEN		SWEDEN
	Email: ludwig@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
	Email: goran.selander@ericsson.com		Email: goran.selander@ericsson.com
	Erik Wahlstroem		Erik Wahlstroem
	(no affiliation)		(no affiliation)
End of changes. 56 change blocks.
	166 lines changed or deleted		173 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/