draft-ietf-ace-oauth-authz-10.txt		draft-ietf-ace-oauth-authz-11.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: August 17, 2018 Ericsson		Expires: September 20, 2018 Ericsson
	E. Wahlstroem		E. Wahlstroem
	S. Erdtman		S. Erdtman
	Spotify AB		Spotify AB
	H. Tschofenig		H. Tschofenig
	ARM Ltd.		ARM Ltd.
	February 13, 2018		March 19, 2018
	Authentication and Authorization for Constrained Environments (ACE)		Authentication and Authorization for Constrained Environments (ACE)
	draft-ietf-ace-oauth-authz-10		using the OAuth 2.0 Framework (ACE-OAuth)
			draft-ietf-ace-oauth-authz-11
	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 called ACE-
	framework is based on a set of building blocks including OAuth 2.0		OAuth. The framework is based on a set of building blocks including
	and CoAP, thus making a well-known and widely used authorization		OAuth 2.0 and CoAP, thus making a well-known and widely used
	solution suitable for IoT devices. Existing specifications are used		authorization solution suitable for IoT devices. Existing
	where possible, but where the constraints of IoT devices require it,		specifications are used where possible, but where the constraints of
	extensions are added and profiles are defined.		IoT devices require it, extensions are added and profiles are
			defined.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at 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 August 17, 2018.		This Internet-Draft will expire on September 20, 2018.
	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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10		4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10
	5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 13		5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.1. Discovering Authorization Servers . . . . . . . . . . . . 14		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 . . . . . . . . . . . . . . . . . . . 15		5.1.2. AS Information . . . . . . . . . . . . . . . . . . . 16
	5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 17		5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 17
	5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 17		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 . . . . . . . . . . . . . . . . . . . 18		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 . . . . . . . . . . . . . . . . . . . 25
	5.6.4. Request and Response Parameters . . . . . . . . . . . 25		5.6.4. Request and Response Parameters . . . . . . . . . . . 25
	5.6.4.1. Audience . . . . . . . . . . . . . . . . . . . . 25		5.6.4.1. Audience . . . . . . . . . . . . . . . . . . . . 26
	5.6.4.2. Grant Type . . . . . . . . . . . . . . . . . . . 25		5.6.4.2. Grant Type . . . . . . . . . . . . . . . . . . . 26
	5.6.4.3. Token Type . . . . . . . . . . . . . . . . . . . 26		5.6.4.3. Token Type . . . . . . . . . . . . . . . . . . . 26
	5.6.4.4. Profile . . . . . . . . . . . . . . . . . . . . . 26		5.6.4.4. Profile . . . . . . . . . . . . . . . . . . . . . 27
	5.6.4.5. Confirmation . . . . . . . . . . . . . . . . . . 26		5.6.4.5. Confirmation . . . . . . . . . . . . . . . . . . 27
	5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 27		5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 27
	5.7. The 'Introspect' Endpoint . . . . . . . . . . . . . . . . 28		5.7. The 'Introspect' Endpoint . . . . . . . . . . . . . . . . 28
	5.7.1. RS-to-AS Request . . . . . . . . . . . . . . . . . . 29		5.7.1. RS-to-AS Request . . . . . . . . . . . . . . . . . . 29
	5.7.2. AS-to-RS Response . . . . . . . . . . . . . . . . . . 29		5.7.2. AS-to-RS Response . . . . . . . . . . . . . . . . . . 29
	5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 30		5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 30
	5.7.4. Mapping Introspection parameters to CBOR . . . . . . 31		5.7.4. Mapping Introspection parameters to CBOR . . . . . . 31
	5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 32		5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 32
	5.8.1. The 'Authorization Information' Endpoint . . . . . . 32		5.8.1. The 'Authorization Information' Endpoint . . . . . . 32
	5.8.2. Token Expiration . . . . . . . . . . . . . . . . . . 33		5.8.2. Token Expiration . . . . . . . . . . . . . . . . . . 33
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 34		6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 24 ¶
	8.2. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 37		8.2. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 37
	8.3. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 38		8.3. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 38
	8.4. OAuth Access Token Types . . . . . . . . . . . . . . . . 38		8.4. OAuth Access Token Types . . . . . . . . . . . . . . . . 38
	8.5. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 38		8.5. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 38
	8.5.1. Initial Registry Contents . . . . . . . . . . . . . . 39		8.5.1. Initial Registry Contents . . . . . . . . . . . . . . 39
	8.6. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 39		8.6. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 39
	8.7. OAuth Parameter Registration . . . . . . . . . . . . . . 39		8.7. OAuth Parameter Registration . . . . . . . . . . . . . . 39
	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 . . . . . . . . . . . . . . . . . . 41
	8.12. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 42		8.12. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 42
	8.13. CoAP Option Number Registration . . . . . . . . . . . . . 42		8.13. CoAP Option Number Registration . . . . . . . . . . . . . 42
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
	10.1. Normative References . . . . . . . . . . . . . . . . . . 43		10.1. Normative References . . . . . . . . . . . . . . . . . . 43
	10.2. Informative References . . . . . . . . . . . . . . . . . 44		10.2. Informative References . . . . . . . . . . . . . . . . . 44
	Appendix A. Design Justification . . . . . . . . . . . . . . . . 46		Appendix A. Design Justification . . . . . . . . . . . . . . . . 46
	Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 50		Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 50
	Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 52		Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 52
	Appendix D. Assumptions on AS knowledge about C and RS . . . . . 53		Appendix D. Assumptions on AS knowledge about C and RS . . . . . 53
	Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 53		Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 53
	E.1. Local Token Validation . . . . . . . . . . . . . . . . . 53		E.1. Local Token Validation . . . . . . . . . . . . . . . . . 53
	E.2. Introspection Aided Token Validation . . . . . . . . . . 57		E.2. Introspection Aided Token Validation . . . . . . . . . . 57
	Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 61		Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 61
	F.1. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 61		F.1. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 61
	F.2. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 61		F.2. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 61
	F.3. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 62		F.3. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 61
	F.4. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 62		F.4. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 62
	F.5. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 62		F.5. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 62
	F.6. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 62		F.6. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 62
	F.7. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 63		F.7. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 63
	F.8. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 63		F.8. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 63
	F.9. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 63		F.9. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 63
	F.10. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 64		F.10. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 63
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64		F.11. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 64
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
	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
	complex task.		complex task.
	skipping to change at page 4, line 46 ¶		skipping to change at page 5, line 9 ¶
	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. Requirements on profiles are		with a wider range of low end devices. Requirements on profiles are
	described at contextually appropriate places throughout this		described at contextually appropriate places throughout this
	specification, and also summarized in Appendix C.		specification, 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 BCP
	[RFC2119].		14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	Certain security-related terms such as "authentication",		Certain security-related terms such as "authentication",
	"authorization", "confidentiality", "(data) integrity", "message		"authorization", "confidentiality", "(data) integrity", "message
	authentication code", and "verify" are taken from [RFC4949].		authentication code", and "verify" are taken from [RFC4949].
	Since exchanges in this specification are described as RESTful		Since exchanges in this specification are described as RESTful
	protocol interactions, HTTP [RFC7231] offers useful terminology.		protocol interactions, HTTP [RFC7231] offers useful terminology.
	Terminology for entities in the architecture is defined in OAuth 2.0		Terminology for entities in the architecture is defined in OAuth 2.0
	[RFC6749] and [I-D.ietf-ace-actors], such as client (C), resource		[RFC6749] and [I-D.ietf-ace-actors], such as client (C), resource
	skipping to change at page 6, line 6 ¶		skipping to change at page 6, line 19 ¶
	Another building block is the lightweight web transfer protocol CoAP		Another building block is the lightweight web transfer protocol CoAP
	[RFC7252], for those communication environments where HTTP is not		[RFC7252], for those communication environments where HTTP is not
	appropriate. CoAP typically runs on top of UDP, which further		appropriate. CoAP typically runs on top of UDP, which further
	reduces overhead and message exchanges. While this specification		reduces overhead and message exchanges. While this specification
	defines extensions for the use of OAuth over CoAP, other underlying		defines extensions for the use of OAuth over CoAP, other underlying
	protocols are not prohibited from being supported in the future, such		protocols are not prohibited from being supported in the future, such
	as HTTP/2, MQTT, BLE and QUIC.		as HTTP/2, MQTT, BLE 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		[RFC8259] 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 payload		encoding of self contained tokens, and also for encoding payload
	transferred in protocol messages.		transferred in protocol messages.
	A fourth building block is the compact CBOR-based secure message		A fourth building block is the compact CBOR-based secure message
	format COSE [RFC8152], which enables application layer security as an		format COSE [RFC8152], which enables application layer security as an
	alternative or complement to transport layer security (DTLS [RFC6347]		alternative or complement to transport layer security (DTLS [RFC6347]
	or TLS [RFC5246]). COSE is used to secure self-contained tokens such		or TLS [RFC5246]). COSE is used to secure self-contained tokens such
	as proof-of-possession (PoP) tokens, which is an extension to the		as proof-of-possession (PoP) tokens, which is an extension to the
	OAuth tokens. The default token format is defined in CBOR web token		OAuth tokens. The default token format is defined in CBOR web token
	skipping to change at page 25, line 5 ¶		skipping to change at page 25, line 27 ¶
	where a response code equivalent to the CoAP code 4.01		where a response code equivalent to the CoAP code 4.01
	(Unauthorized) MAY be used under the same conditions as specified		(Unauthorized) MAY be used under the same conditions as specified
	in Section 5.2 of [RFC6749].		in Section 5.2 of [RFC6749].
	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, when a CBOR		be abbreviated using the codes specified in Figure 12, when a CBOR
	encoding is used.		encoding is used.
	o The error code (i.e., value of the "error" parameter) MUST be		o The error code (i.e., value of the "error" parameter) MUST be
	abbreviated as specified in Figure 10, when a CBOR encoding is		abbreviated as specified in Figure 10, when a CBOR encoding is
	used.		used.
	/------------------------+----------\		/------------------------+-------------\
	| Name | CBOR Key |		| Name | CBOR Values |
	|------------------------+----------|		|------------------------+-------------|
	| invalid_request | 0 |		| invalid_request | 0 |
	| invalid_client | 1 |		| invalid_client | 1 |
	| invalid_grant | 2 |		| invalid_grant | 2 |
	| unauthorized_client | 3 |		| unauthorized_client | 3 |
	| unsupported_grant_type | 4 |		| unsupported_grant_type | 4 |
	| invalid_scope | 5 |		| invalid_scope | 5 |
	| unsupported_pop_key | 6 |		| unsupported_pop_key | 6 |
	\------------------------+----------/		\------------------------+-------------/
	Figure 10: CBOR abbreviations for common error codes		Figure 10: CBOR abbreviations for common error codes
	In addition to the error responses defined in OAuth 2.0, the		In addition to the error responses defined in OAuth 2.0, the
	following behavior MUST be implemented by the AS: If the client		following behavior MUST be implemented by the AS: If the client
	submits an asymmetric key in the token request that the RS cannot		submits an asymmetric key in the token request that the RS cannot
	process, the AS MUST reject that request with a response code		process, the AS MUST reject that request with a response code
	equivalent to the CoAP code 4.00 (Bad Request) including the error		equivalent to the CoAP code 4.00 (Bad Request) including the error
	code "unsupported_pop_key" defined in Figure 10.		code "unsupported_pop_key" defined in Figure 10.
	skipping to change at page 26, line 5 ¶		skipping to change at page 26, line 21 ¶
	application specific.		application specific.
	When encoded as a CBOR payload it is represented as a CBOR text		When encoded as a CBOR payload it is represented as a CBOR text
	string.		string.
	5.6.4.2. Grant Type		5.6.4.2. Grant Type
	The abbreviations in Figure 11 MUST be used in CBOR encodings instead		The abbreviations in Figure 11 MUST be used in CBOR encodings instead
	of the string values defined in [RFC6749], if CBOR payloads are used.		of the string values defined in [RFC6749], if CBOR payloads are used.
	/--------------------+----------+------------------------\		/--------------------+------------+------------------------\
	| Name | CBOR Key | Original Specification |		| Name | CBOR Value | Original Specification |
	|--------------------+----------+------------------------|		|--------------------+------------+------------------------|
	| password | 0 | RFC6749 |		| password | 0 | RFC6749 |
	| authorization_code | 1 | RFC6749 |		| authorization_code | 1 | RFC6749 |
	| client_credentials | 2 | RFC6749 |		| client_credentials | 2 | RFC6749 |
	| refresh_token | 3 | RFC6749 |		| refresh_token | 3 | RFC6749 |
	\--------------------+----------+------------------------/		\--------------------+------------+------------------------/
	Figure 11: CBOR abbreviations for common grant types		Figure 11: CBOR abbreviations for common grant types
	5.6.4.3. Token Type		5.6.4.3. Token Type
	The token_type parameter is defined in [RFC6749], allowing the AS to		The token_type parameter is defined in [RFC6749], allowing the AS to
	indicate to the client which type of access token it is receiving		indicate to the client which type of access token it is receiving
	(e.g., a bearer token).		(e.g., a bearer token).
	This document registers the new value "pop" for the OAuth Access		This document registers the new value "pop" for the OAuth Access
	skipping to change at page 28, line 16 ¶		skipping to change at page 28, line 19 ¶
	| Name | CBOR Key | Value Type |		| Name | CBOR Key | Value Type |
	|-------------------+----------+---------------------|		|-------------------+----------+---------------------|
	| aud | 3 | text string |		| aud | 3 | text string |
	| client_id | 8 | text string |		| client_id | 8 | text string |
	| client_secret | 9 | byte string |		| client_secret | 9 | byte string |
	| response_type | 10 | text string |		| response_type | 10 | text string |
	| redirect_uri | 11 | text string |		| redirect_uri | 11 | text string |
	| scope | 12 | text or byte string |		| scope | 12 | text or byte string |
	| state | 13 | text string |		| state | 13 | text string |
	| code | 14 | byte string |		| code | 14 | byte string |
	| error | 15 | text string |		| error | 15 | unsinged integer |
	| error_description | 16 | text string |		| error_description | 16 | text string |
	| error_uri | 17 | text string |		| error_uri | 17 | text string |
	| grant_type | 18 | unsigned integer |		| grant_type | 18 | unsigned integer |
	| access_token | 19 | text string |		| access_token | 19 | byte string |
	| token_type | 20 | unsigned integer |		| token_type | 20 | unsigned integer |
	| expires_in | 21 | unsigned integer |		| expires_in | 21 | unsigned integer |
	| username | 22 | text string |		| username | 22 | text string |
	| password | 23 | text string |		| password | 23 | text string |
	| refresh_token | 24 | text string |		| refresh_token | 24 | byte string |
	| cnf | 25 | map |		| cnf | 25 | map |
	| profile | 26 | text string |		| profile | 26 | unsigned integer |
	| rs_cnf | 31 | map |		| rs_cnf | 31 | map |
	\-------------------+----------+---------------------/		\-------------------+----------+---------------------/
	Figure 12: CBOR mappings used in token requests		Figure 12: CBOR mappings used in token requests
	5.7. The 'Introspect' Endpoint		5.7. The 'Introspect' 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
	skipping to change at page 31, line 29 ¶		skipping to change at page 31, line 29 ¶
	5.7.4. Mapping Introspection parameters to CBOR		5.7.4. Mapping Introspection parameters to CBOR
	The introspection request and response parameters MUST be mapped to		The introspection request and response parameters MUST be mapped to
	CBOR types as specified in Figure 15, using the given integer		CBOR types as specified in Figure 15, using the given integer
	abbreviation for the key.		abbreviation for the key.
	Note that we have aligned these abbreviations with the claim		Note that we have aligned these abbreviations with the claim
	abbreviations defined in [I-D.ietf-ace-cbor-web-token].		abbreviations defined in [I-D.ietf-ace-cbor-web-token].
	/-----------------+----------+-----------------------\		/-----------------+----------+----------------------------------\
	| Parameter name | CBOR Key | Value Type |		| Parameter name | CBOR Key | Value Type |
	|-----------------+----------+-----------------------|		|-----------------+----------+----------------------------------|
	| iss | 1 | text string |		| iss | 1 | text string |
	| sub | 2 | text string |		| sub | 2 | text string |
	| aud | 3 | text string |		| aud | 3 | text string |
	| exp | 4 | Epoch-based date/time |		| exp | 4 | integer or floating-point number |
	| nbf | 5 | Epoch-based date/time |		| nbf | 5 | integer or floating-point number |
	| iat | 6 | Epoch-based date/time |		| iat | 6 | integer or floating-point number |
	| cti | 7 | byte string |		| cti | 7 | byte string |
	| client_id | 8 | text string |		| client_id | 8 | text string |
	| scope | 12 | text OR byte string |		| scope | 12 | text OR byte string |
	| token_type | 20 | text string |		| token_type | 20 | text string |
	| username | 22 | text string |		| username | 22 | text string |
	| cnf | 25 | map |		| cnf | 25 | map |
	| profile | 26 | unsigned integer |		| profile | 26 | unsigned integer |
	| token | 27 | text string |		| token | 27 | byte string |
	| token_type_hint | 28 | text string |		| token_type_hint | 28 | text string |
	| active | 29 | unsigned integer |		| active | 29 | True or False |
	| client_token | 30 | byte string |		| rs_cnf | 30 | map |
	| rs_cnf | 31 | map |		\-----------------+----------+----------------------------------/
	\-----------------+----------+-----------------------/
	Figure 15: CBOR Mappings to Token Introspection Parameters.		Figure 15: CBOR Mappings to Token Introspection Parameters.
	5.8. The Access Token		5.8. The Access Token
	This framework RECOMMENDS the use of CBOR web token (CWT) as		This framework RECOMMENDS the use of CBOR web token (CWT) as
	specified in [I-D.ietf-ace-cbor-web-token].		specified in [I-D.ietf-ace-cbor-web-token].
	In order to facilitate offline processing of access tokens, this		In order to facilitate offline processing of access tokens, this
	draft uses the "cnf" claim from		draft uses the "cnf" claim from
	skipping to change at page 37, line 45 ¶		skipping to change at page 37, line 45 ¶
	8.2. OAuth Error Code CBOR Mappings Registry		8.2. OAuth Error Code CBOR Mappings Registry
	A new registry will be requested from IANA, entitled "OAuth Error		A new registry will be requested from IANA, entitled "OAuth Error
	Code CBOR Mappings Registry". The registry is to be created as		Code CBOR Mappings Registry". The registry is to be created as
	Expert Review Required.		Expert Review Required.
	The columns of this table are:		The columns of this table are:
	Name The OAuth Error Code name, refers to the name in Section 5.2.		Name The OAuth Error Code name, refers to the name in Section 5.2.
	of [RFC6749] e.g., "invalid_request".		of [RFC6749] e.g., "invalid_request".
	CBOR Key The unsigned integer value abbreviating this error code.		CBOR Value The unsigned integer value abbreviating this error code.
	Registration in the table is based on the value of the mapping		Registration in the table is based on the value of the mapping
	requested. Integer values between 1 and 255 are designated as		requested. Integer values between 1 and 255 are designated as
	Standards Track Document required. Integer values from 256 to		Standards Track Document required. Integer values from 256 to
	65535 are designated as Specification Required. Integer values		65535 are designated as Specification Required. Integer values
	greater than 65535 are designated as private use.		greater than 65535 are designated as private use.
	Reference This contains a pointer to the public specification of the		Reference This contains a pointer to the public specification of the
	grant type abbreviation, if one exists.		grant type abbreviation, if one exists.
	This registry will be initially populated by the values in Figure 10.		This registry will be initially populated by the values in Figure 10.
	skipping to change at page 38, line 21 ¶		skipping to change at page 38, line 21 ¶
	8.3. OAuth Grant Type CBOR Mappings		8.3. OAuth Grant Type CBOR Mappings
	A new registry will be requested from IANA, entitled "OAuth Grant		A new registry will be requested from IANA, entitled "OAuth Grant
	Type CBOR Mappings". The registry is to be created as Expert Review		Type CBOR Mappings". The registry is to be created as Expert Review
	Required.		Required.
	The columns of this table are:		The columns of this table are:
	Name The name of the grant type as specified in Section 1.3 of		Name The name of the grant type as specified in Section 1.3 of
	[RFC6749].		[RFC6749].
	CBOR Key The unsigned integer value abbreviating this grant type.		CBOR Value The unsigned integer value abbreviating this grant type.
	Registration in the table is based on the value of the mapping		Registration in the table is based on the value of the mapping
	requested. Integer values between 1 and 255 are designated as		requested. Integer values between 1 and 255 are designated as
	Standards Track Document required. Integer values from 256 to		Standards Track Document required. Integer values from 256 to
	65535 are designated as Specification Required. Integer values		65535 are designated as Specification Required. Integer values
	greater than 65535 are designated as private use.		greater than 65535 are designated as private use.
	Reference This contains a pointer to the public specification of the		Reference This contains a pointer to the public specification of the
	grant type abbreviation, if one exists.		grant type abbreviation, if one exists.
	Original Specification This contains a pointer to the public		Original Specification This contains a pointer to the public
	specification of the grant type, if one exists.		specification of the grant type, if one exists.
	skipping to change at page 39, line 5 ¶		skipping to change at page 39, line 5 ¶
	8.5. OAuth Token Type CBOR Mappings		8.5. OAuth Token Type CBOR Mappings
	A new registry will be requested from IANA, entitled "Token Type CBOR		A new registry will be requested from IANA, entitled "Token Type CBOR
	Mappings". The registry is to be created as Expert Review Required.		Mappings". The registry is to be created as Expert Review Required.
	The columns of this table are:		The columns of this table are:
	Name The name of token type as registered in the OAuth Access Token		Name The name of token type as registered in the OAuth Access Token
	Types registry e.g., "Bearer".		Types registry e.g., "Bearer".
	CBOR Key The unsigned integer value abbreviating this access token		CBOR Value The unsigned integer value abbreviating this access token
	type. Registration in the table is based on the value of the		type. Registration in the table is based on the value of the
	mapping requested. Integer values between 1 and 255 are		mapping requested. Integer values between 1 and 255 are
	designated as Standards Track Document required. Integer values		designated as Standards Track Document required. Integer values
	from 256 to 65535 are designated as Specification Required.		from 256 to 65535 are designated as Specification Required.
	Integer values greater than 65535 are designated as private use.		Integer values greater than 65535 are designated as private use.
	Reference This contains a pointer to the public specification of the		Reference This contains a pointer to the public specification of the
	OAuth token type abbreviation, if one exists.		OAuth token type abbreviation, if one exists.
	Original Specification This contains a pointer to the public		Original Specification This contains a pointer to the public
	specification of the grant type, if one exists.		specification of the grant type, if one exists.
	skipping to change at page 39, line 39 ¶		skipping to change at page 39, line 39 ¶
	A new registry will be requested from IANA, entitled "ACE Profile		A new registry will be requested from IANA, entitled "ACE Profile
	Registry". The registry is to be created as Expert Review Required.		Registry". The registry is to be created as Expert Review Required.
	The columns of this table are:		The columns of this table are:
	Name The name of the profile, to be used as value of the profile		Name The name of the profile, to be used as value of the profile
	attribute.		attribute.
	Description Text giving an overview of the profile and the context		Description Text giving an overview of the profile and the context
	it is developed for.		it is developed for.
	CBOR Key The unsigned integer value abbreviating this profile name.		CBOR Value The unsigned integer value abbreviating this profile
	Registration in the table is based on the value of the mapping		name. Registration in the table is based on the value of the
	requested. Integer values between 1 and 255 are designated as		mapping requested. Integer values between 1 and 255 are
	Standards Track Document required. Integer values from 256 to		designated as Standards Track Document required. Integer values
	65535 are designated as Specification Required. Integer values		from 256 to 65535 are designated as Specification Required.
	greater than 65535 are designated as private use.		Integer values greater than 65535 are designated as private use.
	Reference This contains a pointer to the public specification of the		Reference This contains a pointer to the public specification of the
	profile abbreviation, if one exists.		profile abbreviation, if one exists.
	8.7. OAuth Parameter Registration		8.7. OAuth Parameter Registration
	This specification registers the following parameters in the OAuth		This specification registers the following parameters in the OAuth
	Parameters Registry:		Parameters Registry:
	o Name: "aud"		o Name: "aud"
	o Parameter Usage Location: authorization request, token request		o Parameter Usage Location: authorization request, token request
	skipping to change at page 41, line 21 ¶		skipping to change at page 41, line 21 ¶
	o Description: Key to prove the right to use a PoP token.		o Description: Key to prove the right to use a PoP token.
	o Change Controller: IESG		o Change Controller: IESG
	o Reference: Section 5.7.2 of [this document]		o Reference: Section 5.7.2 of [this document]
	o Name: "profile"		o Name: "profile"
	o Description: The communication and communication security profile		o Description: The communication and communication security profile
	used between client and RS, as defined in ACE profiles.		used between client and RS, as defined in ACE profiles.
	o Change Controller: IESG		o Change Controller: IESG
	o Reference: Section 5.7.2 of [this document]		o Reference: Section 5.7.2 of [this document]
	o Name: "client_token"
	o Description: Information that the RS MUST pass to the client e.g.,
	about the proof-of-possession keys.
	o Change Controller: IESG
	o Reference: Section 5.7.2 of [this document]
	8.10. Introspection Endpoint CBOR Mappings Registry		8.10. Introspection Endpoint CBOR Mappings Registry
	A new registry will be requested from IANA, entitled "Introspection		A new registry will be requested from IANA, entitled "Introspection
	Endpoint CBOR Mappings Registry". The registry is to be created as		Endpoint CBOR Mappings Registry". The registry is to be created as
	Expert Review Required.		Expert Review Required.
	The columns of this table are:		The columns of this table are:
	Name The OAuth Parameter name, refers to the name in the OAuth		Name The OAuth Parameter name, refers to the name in the OAuth
	parameter registry e.g., "client_id".		parameter registry e.g., "client_id".
	skipping to change at page 43, line 25 ¶		skipping to change at page 43, line 14 ¶
	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		10.1. Normative References
	[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-12		"CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-14
	(work in progress), February 2018.		(work in progress), March 2018.
	[I-D.ietf-ace-cwt-proof-of-possession]		[I-D.ietf-ace-cwt-proof-of-possession]
	Jones, M., Seitz, L., Selander, G., Wahlstroem, E.,		Jones, M., Seitz, L., Selander, G., Wahlstroem, E.,
	Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key		Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key
	Semantics for CBOR Web Tokens (CWTs)", draft-ietf-ace-cwt-		Semantics for CBOR Web Tokens (CWTs)", draft-ietf-ace-cwt-
	proof-of-possession-01 (work in progress), October 2017.		proof-of-possession-02 (work in progress), March 2018.
	[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, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	skipping to change at page 44, line 18 ¶		skipping to change at page 44, line 9 ¶
	[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-		[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
	Possession Key Semantics for JSON Web Tokens (JWTs)",		Possession Key Semantics for JSON Web Tokens (JWTs)",
	RFC 7800, DOI 10.17487/RFC7800, April 2016,		RFC 7800, DOI 10.17487/RFC7800, April 2016,
	<https://www.rfc-editor.org/info/rfc7800>.		<https://www.rfc-editor.org/info/rfc7800>.
	[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",		[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	RFC 8152, DOI 10.17487/RFC8152, July 2017,		RFC 8152, DOI 10.17487/RFC8152, July 2017,
	<https://www.rfc-editor.org/info/rfc8152>.		<https://www.rfc-editor.org/info/rfc8152>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	10.2. Informative References		10.2. Informative References
	[I-D.erdtman-ace-rpcc]		[I-D.erdtman-ace-rpcc]
	Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared-		Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared-
	Key as OAuth client credentials", draft-erdtman-ace-		Key as OAuth client credentials", draft-erdtman-ace-
	rpcc-02 (work in progress), October 2017.		rpcc-02 (work in progress), October 2017.
	[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-06 (work in		environments", draft-ietf-ace-actors-06 (work in
	progress), November 2017.		progress), November 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 for Constrained RESTful Environments		"Object Security for Constrained RESTful Environments
	(OSCORE)", draft-ietf-core-object-security-08 (work in		(OSCORE)", draft-ietf-core-object-security-10 (work in
	progress), January 2018.		progress), March 2018.
	[I-D.ietf-core-resource-directory]		[I-D.ietf-core-resource-directory]
	Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.		Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
	Amsuess, "CoRE Resource Directory", draft-ietf-core-		Amsuess, "CoRE Resource Directory", draft-ietf-core-
	resource-directory-12 (work in progress), October 2017.		resource-directory-13 (work in progress), March 2018.
	[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-07		Constrained Devices", draft-ietf-oauth-device-flow-07
	(work in progress), October 2017.		(work in progress), October 2017.
	[I-D.ietf-oauth-discovery]		[I-D.ietf-oauth-discovery]
	Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0		Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
	Authorization Server Metadata", draft-ietf-oauth-		Authorization Server Metadata", draft-ietf-oauth-
	discovery-08 (work in progress), November 2017.		discovery-10 (work in progress), March 2018.
	[Margi10impact]		[Margi10impact]
	Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr,		Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr,
	M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold,		M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold,
	"Impact of Operating Systems on Wireless Sensor Networks		"Impact of Operating Systems on Wireless Sensor Networks
	(Security) Applications and Testbeds", Proceedings of		(Security) Applications and Testbeds", Proceedings of
	the 19th International Conference on Computer		the 19th International Conference on Computer
	Communications and Networks (ICCCN), 2010 August.		Communications and Networks (ICCCN), 2010 August.
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
	skipping to change at page 45, line 39 ¶		skipping to change at page 45, line 39 ¶
	[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0		[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
	Threat Model and Security Considerations", RFC 6819,		Threat Model and Security Considerations", RFC 6819,
	DOI 10.17487/RFC6819, January 2013, <https://www.rfc-		DOI 10.17487/RFC6819, January 2013, <https://www.rfc-
	editor.org/info/rfc6819>.		editor.org/info/rfc6819>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,		Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	October 2013, <https://www.rfc-editor.org/info/rfc7049>.		October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
	2014, <https://www.rfc-editor.org/info/rfc7159>.
	[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for		[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
	Constrained-Node Networks", RFC 7228,		Constrained-Node Networks", RFC 7228,
	DOI 10.17487/RFC7228, May 2014, <https://www.rfc-		DOI 10.17487/RFC7228, May 2014, <https://www.rfc-
	editor.org/info/rfc7228>.		editor.org/info/rfc7228>.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,		Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014, <https://www.rfc-		DOI 10.17487/RFC7231, June 2014, <https://www.rfc-
	editor.org/info/rfc7231>.		editor.org/info/rfc7231>.
	skipping to change at page 46, line 39 ¶		skipping to change at page 46, line 35 ¶
	[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in		[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
	the Constrained Application Protocol (CoAP)", RFC 7959,		the Constrained Application Protocol (CoAP)", RFC 7959,
	DOI 10.17487/RFC7959, August 2016, <https://www.rfc-		DOI 10.17487/RFC7959, August 2016, <https://www.rfc-
	editor.org/info/rfc7959>.		editor.org/info/rfc7959>.
	[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",		[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
	BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,		BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
	<https://www.rfc-editor.org/info/rfc8252>.		<https://www.rfc-editor.org/info/rfc8252>.
			[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
			Interchange Format", STD 90, RFC 8259,
			DOI 10.17487/RFC8259, December 2017, <https://www.rfc-
			editor.org/info/rfc8259>.
	Appendix A. Design Justification		Appendix A. Design Justification
	This section provides further insight into the design decisions of		This section provides further insight into the design decisions of
	the solution documented in this document. Section 3 lists several		the solution documented in this document. Section 3 lists several
	building blocks and briefly summarizes their importance. The		building blocks and briefly summarizes their importance. The
	justification for offering some of those building blocks, as opposed		justification for offering some of those building blocks, as opposed
	to using OAuth 2.0 as is, is given below.		to using OAuth 2.0 as is, is given below.
	Common IoT constraints are:		Common IoT constraints are:
	skipping to change at page 61, 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 25: Resource request and response protected by OSCOAP		Figure 25: Resource request and response protected by OSCOAP
	Appendix F. Document Updates		Appendix F. Document Updates
	F.1. Version -09 to -10		RFC EDITOR: PLEASE REMOVE THIS SECTION.
			F.1. Version -10 to -11
			o Fixed some CBOR data type errors.
			o Updated boilerplate text
			F.2. 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.2. Version -08 to -09		F.3. 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.3. Version -07 to -08		F.4. 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.
	skipping to change at page 62, line 33 ¶		skipping to change at page 62, line 36 ¶
	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.4. Version -06 to -07		F.5. Version -06 to -07
	o Various clarifications added.		o Various clarifications added.
	o Fixed erroneous author email.		o Fixed erroneous author email.
	F.5. Version -05 to -06		F.6. 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.6. Version -04 to -05		F.7. 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.2		requests in Section 5.8.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
	skipping to change at page 63, line 17 ¶		skipping to change at page 63, line 22 ¶
	o Added clarification about token expiration and long-running		o Added clarification about token expiration and long-running
	requests in Section 5.8.2		requests in Section 5.8.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.7. Version -03 to -04		F.8. 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.8. Version -02 to -03		F.9. 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.9. Version -01 to -02		F.10. 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.10. Version -00 to -01		F.11. 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
End of changes. 52 change blocks.
	121 lines changed or deleted		130 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/