< draft-ietf-ace-oauth-authz-37.txt		draft-ietf-ace-oauth-authz-38.txt >
	ACE Working Group L. Seitz		ACE Working Group L. Seitz
	Internet-Draft Combitech		Internet-Draft Combitech
	Intended status: Standards Track G. Selander		Intended status: Standards Track G. Selander
	Expires: August 8, 2021 Ericsson		Expires: September 9, 2021 Ericsson
	E. Wahlstroem		E. Wahlstroem
	S. Erdtman		S. Erdtman
	Spotify AB		Spotify AB
	H. Tschofenig		H. Tschofenig
	Arm Ltd.		Arm Ltd.
	February 4, 2021		March 8, 2021
	Authentication and Authorization for Constrained Environments (ACE)		Authentication and Authorization for Constrained Environments (ACE)
	using the OAuth 2.0 Framework (ACE-OAuth)		using the OAuth 2.0 Framework (ACE-OAuth)
	draft-ietf-ace-oauth-authz-37		draft-ietf-ace-oauth-authz-38
	Abstract		Abstract
	This specification defines a framework for authentication and		This specification defines a framework for authentication and
	authorization in Internet of Things (IoT) environments called ACE-		authorization in Internet of Things (IoT) environments called ACE-
	OAuth. The framework is based on a set of building blocks including		OAuth. The framework is based on a set of building blocks including
	OAuth 2.0 and the Constrained Application Protocol (CoAP), thus		OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
	transforming a well-known and widely used authorization solution into		transforming a well-known and widely used authorization solution into
	a form suitable for IoT devices. Existing specifications are used		a form suitable for IoT devices. Existing specifications are used
	where possible, but extensions are added and profiles are defined to		where possible, but extensions are added and profiles are defined to
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 8, 2021.		This Internet-Draft will expire on September 9, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 37 ¶		skipping to change at page 2, line 37 ¶
	4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11		4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11
	5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15		5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Discovering Authorization Servers . . . . . . . . . . . . 16		5.1. Discovering Authorization Servers . . . . . . . . . . . . 16
	5.2. Unauthorized Resource Request Message . . . . . . . . . . 17		5.2. Unauthorized Resource Request Message . . . . . . . . . . 17
	5.3. AS Request Creation Hints . . . . . . . . . . . . . . . . 17		5.3. AS Request Creation Hints . . . . . . . . . . . . . . . . 17
	5.3.1. The Client-Nonce Parameter . . . . . . . . . . . . . 19		5.3.1. The Client-Nonce Parameter . . . . . . . . . . . . . 19
	5.4. Authorization Grants . . . . . . . . . . . . . . . . . . 20		5.4. Authorization Grants . . . . . . . . . . . . . . . . . . 20
	5.5. Client Credentials . . . . . . . . . . . . . . . . . . . 21		5.5. Client Credentials . . . . . . . . . . . . . . . . . . . 21
	5.6. AS Authentication . . . . . . . . . . . . . . . . . . . . 21		5.6. AS Authentication . . . . . . . . . . . . . . . . . . . . 21
	5.7. The Authorization Endpoint . . . . . . . . . . . . . . . 21		5.7. The Authorization Endpoint . . . . . . . . . . . . . . . 21
	5.8. The Token Endpoint . . . . . . . . . . . . . . . . . . . 21		5.8. The Token Endpoint . . . . . . . . . . . . . . . . . . . 22
	5.8.1. Client-to-AS Request . . . . . . . . . . . . . . . . 22		5.8.1. Client-to-AS Request . . . . . . . . . . . . . . . . 22
	5.8.2. AS-to-Client Response . . . . . . . . . . . . . . . . 25		5.8.2. AS-to-Client Response . . . . . . . . . . . . . . . . 25
	5.8.3. Error Response . . . . . . . . . . . . . . . . . . . 27		5.8.3. Error Response . . . . . . . . . . . . . . . . . . . 27
	5.8.4. Request and Response Parameters . . . . . . . . . . . 28		5.8.4. Request and Response Parameters . . . . . . . . . . . 28
	5.8.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 28		5.8.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 29
	5.8.4.2. Token Type . . . . . . . . . . . . . . . . . . . 29		5.8.4.2. Token Type . . . . . . . . . . . . . . . . . . . 29
	5.8.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 29		5.8.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 29
	5.8.4.4. Client-Nonce . . . . . . . . . . . . . . . . . . 30		5.8.4.4. Client-Nonce . . . . . . . . . . . . . . . . . . 30
	5.8.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 30		5.8.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 30
	5.9. The Introspection Endpoint . . . . . . . . . . . . . . . 31		5.9. The Introspection Endpoint . . . . . . . . . . . . . . . 31
	5.9.1. Introspection Request . . . . . . . . . . . . . . . . 32		5.9.1. Introspection Request . . . . . . . . . . . . . . . . 32
	5.9.2. Introspection Response . . . . . . . . . . . . . . . 33		5.9.2. Introspection Response . . . . . . . . . . . . . . . 33
	5.9.3. Error Response . . . . . . . . . . . . . . . . . . . 34		5.9.3. Error Response . . . . . . . . . . . . . . . . . . . 34
	5.9.4. Mapping Introspection parameters to CBOR . . . . . . 35		5.9.4. Mapping Introspection parameters to CBOR . . . . . . 35
	5.10. The Access Token . . . . . . . . . . . . . . . . . . . . 35		5.10. The Access Token . . . . . . . . . . . . . . . . . . . . 35
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 46 ¶
	8.12. OAuth Token Introspection Response CBOR Mappings Registry 55		8.12. OAuth Token Introspection Response CBOR Mappings Registry 55
	8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55		8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55
	8.14. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56		8.14. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56
	8.15. Media Type Registrations . . . . . . . . . . . . . . . . 57		8.15. Media Type Registrations . . . . . . . . . . . . . . . . 57
	8.16. CoAP Content-Format Registry . . . . . . . . . . . . . . 57		8.16. CoAP Content-Format Registry . . . . . . . . . . . . . . 57
	8.17. Expert Review Instructions . . . . . . . . . . . . . . . 58		8.17. Expert Review Instructions . . . . . . . . . . . . . . . 58
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
	10.1. Normative References . . . . . . . . . . . . . . . . . . 59		10.1. Normative References . . . . . . . . . . . . . . . . . . 59
	10.2. Informative References . . . . . . . . . . . . . . . . . 62		10.2. Informative References . . . . . . . . . . . . . . . . . 62
	Appendix A. Design Justification . . . . . . . . . . . . . . . . 64		Appendix A. Design Justification . . . . . . . . . . . . . . . . 65
	Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68		Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68
	Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70		Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 71
	Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71		Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71
	Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 72		Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 72
	E.1. Local Token Validation . . . . . . . . . . . . . . . . . 72		E.1. Local Token Validation . . . . . . . . . . . . . . . . . 72
	E.2. Introspection Aided Token Validation . . . . . . . . . . 76		E.2. Introspection Aided Token Validation . . . . . . . . . . 76
	Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 80		Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 80
	F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 81		F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 81
	F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 81		F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 81
	F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 81		F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 81
	F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 81		F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 81
	F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 81		F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 81
	skipping to change at page 6, line 47 ¶		skipping to change at page 6, line 47 ¶
	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 [RFC7540], Message Queuing Telemetry Transport (MQTT)		as HTTP/2 [RFC7540], Message Queuing Telemetry Transport (MQTT)
	[MQTT5.0], Bluetooth Low Energy (BLE) [BLE] and QUIC		[MQTT5.0], Bluetooth Low Energy (BLE) [BLE] and QUIC
	[I-D.ietf-quic-transport]. Note that this document specifies		[I-D.ietf-quic-transport]. Note that this document specifies
	protocol exchanges in terms of RESTful verbs such as GET and POST.		protocol exchanges in terms of RESTful verbs such as GET and POST.
	Future profiles using protocols that do not support these verbs MUST		Future profiles using protocols that do not support these verbs MUST
	specify how the corresponding protocol messages are transmitted		specify how the corresponding protocol messages are transmitted
	instead.		instead.
	A third building block is the Concise Binary Object Representation		A third building block is the Concise Binary Object Representation
	(CBOR) [RFC7049], for encodings where JSON [RFC8259] is not		(CBOR) [RFC8949], for encodings where JSON [RFC8259] is not
	sufficiently compact. CBOR is a binary encoding designed for small		sufficiently compact. CBOR is a binary encoding designed for small
	code and message size, which may be used for encoding of self		code and message size, which may be used for encoding of self
	contained tokens, and also for encoding payloads transferred in		contained tokens, and also for encoding payloads transferred in
	protocol messages.		protocol messages.
	A fourth building block is CBOR Object Signing and Encryption (COSE)		A fourth building block is CBOR Object Signing and Encryption (COSE)
	[RFC8152], which enables object-level layer security as an		[RFC8152], which enables object-level layer security as an
	alternative or complement to transport layer security (DTLS [RFC6347]		alternative or complement to transport layer security (DTLS [RFC6347]
	or TLS [RFC8446]). COSE is used to secure self-contained tokens such		or TLS [RFC8446]). COSE is used to secure self-contained tokens such
	as proof-of-possession (PoP) tokens, which are an extension to the		as proof-of-possession (PoP) tokens, which are an extension to the
	skipping to change at page 16, line 13 ¶		skipping to change at page 16, line 13 ¶
	communications named above are encrypted, integrity protected and		communications named above are encrypted, integrity protected and
	protected against message replay. It is also REQUIRED that the		protected against message replay. It is also REQUIRED that the
	communicating endpoints perform mutual authentication. Furthermore		communicating endpoints perform mutual authentication. Furthermore
	it MUST be assured that responses are bound to the requests in the		it MUST be assured that responses are bound to the requests in the
	sense that the receiver of a response can be certain that the		sense that the receiver of a response can be certain that the
	response actually belongs to a certain request. Note that setting up		response actually belongs to a certain request. Note that setting up
	such a secure communication may require some unprotected messages to		such a secure communication may require some unprotected messages to
	be exchanged first (e.g. sending the token from the client to the		be exchanged first (e.g. sending the token from the client to the
	RS).		RS).
	Profiles MUST specify a communication security protocol that provides		Profiles MUST specify a communication security protocol between
	the features required above.		client and RS that provides the features required above. Profiles
			MUST specify a communication security protocol RECOMMENDED to be used
			between client and AS that provides the features required above.
			Profiles MUST specify for introspection a communication security
			protocol RECOMMENDED to be used between RS and AS that provides the
			features required above. These recommendations enable
			interoperability between different implementations without the need
			to define a new profile if the communication between C and AS, or
			between RS and AS, is protected with a different security protocol
			complying with the security requirements above.
	In OAuth 2.0 the communication with the Token and the Introspection		In OAuth 2.0 the communication with the Token and the Introspection
	endpoints at the AS is assumed to be via HTTP and may use Uri-query		endpoints at the AS is assumed to be via HTTP and may use Uri-query
	parameters. When profiles of this framework use CoAP instead, it is		parameters. When profiles of this framework use CoAP instead, it is
	REQUIRED to use of the following alternative instead of Uri-query		REQUIRED to use of the following alternative instead of Uri-query
	parameters: The sender (client or RS) encodes the parameters of its		parameters: The sender (client or RS) encodes the parameters of its
	request as a CBOR map and submits that map as the payload of the POST		request as a CBOR map and submits that map as the payload of the POST
	request.		request.
	Profiles that use CBOR encoding of protocol message parameters at the		Profiles that use CBOR encoding of protocol message parameters at the
	outermost encoding layer MUST use the media format 'application/		outermost encoding layer MUST use the media format 'application/
	ace+cbor'. If CoAP is used for communication, the Content-Format		ace+cbor'. If CoAP is used for communication, the Content-Format
	MUST be abbreviated with the ID: 19 (see Section 8.16).		MUST be abbreviated with the ID: 19 (see Section 8.16).
	The OAuth 2.0 AS uses a JSON structure in the payload of its		The OAuth 2.0 AS uses a JSON structure in the payload of its
	responses both to client and RS. If CoAP is used, it is REQUIRED to		responses both to client and RS. If CoAP is used, it is REQUIRED to
	use CBOR [RFC7049] instead of JSON. Depending on the profile, the		use CBOR [RFC8949] instead of JSON. Depending on the profile, the
	CBOR payload MAY be enclosed in a non-CBOR cryptographic wrapper.		CBOR payload MAY be enclosed in a non-CBOR cryptographic wrapper.
	5.1. Discovering Authorization Servers		5.1. Discovering Authorization Servers
	C must discover the AS in charge of RS to determine where to request		C must discover the AS in charge of RS to determine where to request
	the access token. To do so, C must 1. find out the AS URI to which		the access token. To do so, C must 1. find out the AS URI to which
	the token request message must be sent and 2. MUST validate that the		the token request message must be sent and 2. MUST validate that the
	AS with this URI is authorized to provide access tokens for this RS.		AS with this URI is authorized to provide access tokens for this RS.
	In order to determine the AS URI, C MAY send an initial Unauthorized		In order to determine the AS URI, C MAY send an initial Unauthorized
	skipping to change at page 18, line 39 ¶		skipping to change at page 18, line 44 ¶
	Figure 2: AS Request Creation Hints		Figure 2: AS Request Creation Hints
	Note that the schema part of the AS parameter may need to be adapted		Note that the schema part of the AS parameter may need to be adapted
	to the security protocol that is used between the client and the AS.		to the security protocol that is used between the client and the AS.
	Thus the example AS value "coap://as.example.com/token" might need to		Thus the example AS value "coap://as.example.com/token" might need to
	be transformed to "coaps://as.example.com/token". It is assumed that		be transformed to "coaps://as.example.com/token". It is assumed that
	the client can determine the correct schema part on its own depending		the client can determine the correct schema part on its own depending
	on the way it communicates with the AS.		on the way it communicates with the AS.
	Figure 3 shows an example for an AS Request Creation Hints message		Figure 3 shows an example for an AS Request Creation Hints message
	payload using CBOR [RFC7049] diagnostic notation, using the parameter		payload using CBOR [RFC8949] diagnostic notation, using the parameter
	names instead of the CBOR keys for better human readability.		names instead of the CBOR keys for better human readability.
	4.01 Unauthorized		4.01 Unauthorized
	Content-Format: application/ace+cbor		Content-Format: application/ace+cbor
	Payload :		Payload :
	{		{
	"AS" : "coaps://as.example.com/token",		"AS" : "coaps://as.example.com/token",
	"audience" : "coaps://rs.example.com"		"audience" : "coaps://rs.example.com"
	"scope" : "rTempC",		"scope" : "rTempC",
	"cnonce" : h'e0a156bb3f'		"cnonce" : h'e0a156bb3f'
	skipping to change at page 43, line 43 ¶		skipping to change at page 43, line 43 ¶
	further standardization work that is out of scope for this document.		further standardization work that is out of scope for this document.
	6.2. Communication Security		6.2. Communication Security
	Communication with the authorization server MUST use confidentiality		Communication with the authorization server MUST use confidentiality
	protection. This step is extremely important since the client or the		protection. This step is extremely important since the client or the
	RS may obtain the proof-of-possession key from the authorization		RS may obtain the proof-of-possession key from the authorization
	server for use with a specific access token. Not using		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 communication security according		security. The requirements for communication security of profiles
	to the requirements in Section 5 is provided.		are specified in Section 5.
	Additional protection for the access token can be applied by		Additional protection for the access token can be applied by
	encrypting it, for example encryption of CWTs is specified in		encrypting it, for example encryption of CWTs is specified in
	Section 5.1 of [RFC8392]. Such additional protection can be		Section 5.1 of [RFC8392]. Such additional protection can be
	necessary if the token is later transferred over an insecure		necessary if the token is later transferred over an insecure
	connection (e.g. when it is sent to the authz-info endpoint).		connection (e.g. when it is sent to the authz-info endpoint).
	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
	skipping to change at page 60, line 39 ¶		skipping to change at page 60, line 39 ¶
	[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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-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>.
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
	FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
	<https://www.rfc-editor.org/info/rfc4949>.
	[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, <https://www.rfc-editor.org/info/rfc6347>.		January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",		[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
	RFC 6749, DOI 10.17487/RFC6749, October 2012,		RFC 6749, DOI 10.17487/RFC6749, October 2012,
	<https://www.rfc-editor.org/info/rfc6749>.		<https://www.rfc-editor.org/info/rfc6749>.
	[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization		[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
	Framework: Bearer Token Usage", RFC 6750,		Framework: Bearer Token Usage", RFC 6750,
	skipping to change at page 61, line 20 ¶		skipping to change at page 61, line 15 ¶
	[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type		[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
	Specifications and Registration Procedures", BCP 13,		Specifications and Registration Procedures", BCP 13,
	RFC 6838, DOI 10.17487/RFC6838, January 2013,		RFC 6838, DOI 10.17487/RFC6838, January 2013,
	<https://www.rfc-editor.org/info/rfc6838>.		<https://www.rfc-editor.org/info/rfc6838>.
	[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,		[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
	Keranen, A., and P. Hallam-Baker, "Naming Things with		Keranen, A., and P. Hallam-Baker, "Naming Things with
	Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,		Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
	<https://www.rfc-editor.org/info/rfc6920>.		<https://www.rfc-editor.org/info/rfc6920>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,		DOI 10.17487/RFC7252, June 2014,
	<https://www.rfc-editor.org/info/rfc7252>.		<https://www.rfc-editor.org/info/rfc7252>.
	[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<https://www.rfc-editor.org/info/rfc7519>.		<https://www.rfc-editor.org/info/rfc7519>.
	[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",		[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
	skipping to change at page 62, line 15 ¶		skipping to change at page 62, line 10 ¶
	[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,		[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
	and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,		and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
	DOI 10.17487/RFC8693, January 2020,		DOI 10.17487/RFC8693, January 2020,
	<https://www.rfc-editor.org/info/rfc8693>.		<https://www.rfc-editor.org/info/rfc8693>.
	[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.		[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
	Tschofenig, "Proof-of-Possession Key Semantics for CBOR		Tschofenig, "Proof-of-Possession Key Semantics for CBOR
	Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March		Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
	2020, <https://www.rfc-editor.org/info/rfc8747>.		2020, <https://www.rfc-editor.org/info/rfc8747>.
			[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
			Representation (CBOR)", STD 94, RFC 8949,
			DOI 10.17487/RFC8949, December 2020,
			<https://www.rfc-editor.org/info/rfc8949>.
	10.2. Informative References		10.2. Informative References
	[BLE] Bluetooth SIG, "Bluetooth Core Specification v5.1",		[BLE] Bluetooth SIG, "Bluetooth Core Specification v5.1",
	Section 4.4, January 2019,		Section 4.4, January 2019,
	<https://www.bluetooth.com/specifications/bluetooth-core-		<https://www.bluetooth.com/specifications/bluetooth-core-
	specification/>.		specification/>.
	[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-
	skipping to change at page 63, line 5 ¶		skipping to change at page 63, line 5 ¶
	"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), August 2010.		Communications and Networks (ICCCN), August 2010.
	[MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT		[MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT
	Version 5.0", OASIS Standard, March 2019,		Version 5.0", OASIS Standard, March 2019,
	<https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-		<https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-
	v5.0.html>.		v5.0.html>.
			[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
			FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
			<https://www.rfc-editor.org/info/rfc4949>.
	[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link		[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
	Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,		Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
	<https://www.rfc-editor.org/info/rfc6690>.		<https://www.rfc-editor.org/info/rfc6690>.
	[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,		DOI 10.17487/RFC6819, January 2013,
	<https://www.rfc-editor.org/info/rfc6819>.		<https://www.rfc-editor.org/info/rfc6819>.
	[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth		[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
	skipping to change at page 66, line 36 ¶		skipping to change at page 66, line 46 ¶
	not limited to them. Other protocols such as HTTP, or even		not limited to them. Other protocols such as HTTP, or even
	protocols such as Bluetooth Smart communication that do not		protocols such as Bluetooth Smart communication that do not
	necessarily use IP, could also be used. The latter raises the		necessarily use IP, could also be used. The latter raises the
	need for application layer security over the various interfaces.		need for application layer security over the various interfaces.
	In the light of these constraints we have made the following design		In the light of these constraints we have made the following design
	decisions:		decisions:
	CBOR, COSE, CWT:		CBOR, COSE, CWT:
	This framework RECOMMENDS the use of CBOR [RFC7049] as data		This framework RECOMMENDS the use of CBOR [RFC8949] as data
	format. Where CBOR data needs to be protected, the use of COSE		format. Where CBOR data needs to be protected, the use of COSE
	[RFC8152] is RECOMMENDED. Furthermore, where self-contained		[RFC8152] is RECOMMENDED. Furthermore, where self-contained
	tokens are needed, this framework RECOMMENDS the use of CWT		tokens are needed, this framework RECOMMENDS the use of CWT
	[RFC8392]. These measures aim at reducing the size of messages		[RFC8392]. These measures aim at reducing the size of messages
	sent over the wire, the RAM size of data objects that need to be		sent over the wire, the RAM size of data objects that need to be
	kept in memory and the size of libraries that devices need to		kept in memory and the size of libraries that devices need to
	support.		support.
	CoAP:		CoAP:
End of changes. 18 change blocks.
	24 lines changed or deleted		34 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/