draft-ietf-ace-oauth-authz-30.txt		draft-ietf-ace-oauth-authz-31.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: July 14, 2020 Ericsson		Expires: July 21, 2020 Ericsson
	E. Wahlstroem		E. Wahlstroem
	S. Erdtman		S. Erdtman
	Spotify AB		Spotify AB
	H. Tschofenig		H. Tschofenig
	Arm Ltd.		Arm Ltd.
	January 11, 2020		January 18, 2020
	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-30		draft-ietf-ace-oauth-authz-31
	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 July 14, 2020.		This Internet-Draft will expire on July 21, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	5.8.1. The Authorization Information Endpoint . . . . . . . 36		5.8.1. The Authorization Information Endpoint . . . . . . . 36
	5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 37		5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 37
	5.8.1.2. Protecting the Authorization Information		5.8.1.2. Protecting the Authorization Information
	Endpoint . . . . . . . . . . . . . . . . . . . . 39		Endpoint . . . . . . . . . . . . . . . . . . . . 39
	5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 39		5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 39
	5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 40		5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 40
	5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 41		5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 41
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 42		6. Security Considerations . . . . . . . . . . . . . . . . . . . 42
	6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 42		6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 42
	6.2. Communication Security . . . . . . . . . . . . . . . . . 43		6.2. Communication Security . . . . . . . . . . . . . . . . . 43
	6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 43		6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 44
	6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 44		6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 44
	6.5. Minimal security requirements for communication . 45		6.5. Minimal security requirements for communication . 45
	6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46		6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46
	6.7. Combining profiles . . . . . . . . . . . . . . . . . . . 47		6.7. Combining profiles . . . . . . . . . . . . . . . . . . . 47
	6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47		6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47
	6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 48		6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 48
	6.10. Denial of service against or with Introspection . . 48		6.10. Denial of service against or with Introspection . . 48
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
	8.1. ACE Authorization Server Request Creation Hints . . . . . 50		8.1. ACE Authorization Server Request Creation Hints . . . . . 50
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 46 ¶
	8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55		8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55
	8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 55		8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 55
	8.14. Media Type Registrations . . . . . . . . . . . . . . . . 56		8.14. Media Type Registrations . . . . . . . . . . . . . . . . 56
	8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 57		8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 57
	8.16. Expert Review Instructions . . . . . . . . . . . . . . . 57		8.16. Expert Review Instructions . . . . . . . . . . . . . . . 57
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
	10.1. Normative References . . . . . . . . . . . . . . . . . . 59		10.1. Normative References . . . . . . . . . . . . . . . . . . 59
	10.2. Informative References . . . . . . . . . . . . . . . . . 61		10.2. Informative References . . . . . . . . . . . . . . . . . 61
	Appendix A. Design Justification . . . . . . . . . . . . . . . . 64		Appendix A. Design Justification . . . . . . . . . . . . . . . . 64
	Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68		Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 67
	Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70		Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70
	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 . . . . . . . . . . . . . . . . 71		Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 71
	E.1. Local Token Validation . . . . . . . . . . . . . . . . . 72		E.1. Local Token Validation . . . . . . . . . . . . . . . . . 71
	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
	F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 81		F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 81
	F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 82		F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 82
	skipping to change at page 22, line 37 ¶		skipping to change at page 22, line 37 ¶
	profile MUST specify how the communication is protected. The content		profile MUST specify how the communication is protected. The content
	of the request consists of the parameters specified in the relevant		of the request consists of the parameters specified in the relevant
	subsection of section 4 of the OAuth 2.0 specification [RFC6749],		subsection of section 4 of the OAuth 2.0 specification [RFC6749],
	depending on the grant type, with the following exceptions and		depending on the grant type, with the following exceptions and
	additions:		additions:
	o The parameter "grant_type" is OPTIONAL in the context of this		o The parameter "grant_type" is OPTIONAL in the context of this
	framework (as opposed to REQUIRED in RFC6749). If that parameter		framework (as opposed to REQUIRED in RFC6749). If that parameter
	is missing, the default value "client_credentials" is implied.		is missing, the default value "client_credentials" is implied.
	o The "audience" parameter from [I-D.ietf-oauth-token-exchange] is		o The "audience" parameter from [RFC8693] is OPTIONAL to request an
	OPTIONAL to request an access token bound to a specific audience.		access token bound to a specific audience.
	o The "cnonce" parameter defined in Section 5.6.4.4 is REQUIRED if		o The "cnonce" parameter defined in Section 5.6.4.4 is REQUIRED if
	the RS provided a client-nonce in the "AS Request Creation Hints"		the RS provided a client-nonce in the "AS Request Creation Hints"
	message Section 5.1.2		message Section 5.1.2
	o The "scope" parameter MAY be encoded as a byte string instead of		o The "scope" parameter MAY be encoded as a byte string instead of
	the string encoding specified in section 3.3 of [RFC6749], in		the string encoding specified in section 3.3 of [RFC6749], in
	order allow compact encoding of complex scopes. The syntax of		order allow compact encoding of complex scopes. The syntax of
	such a binary encoding is explicitly not specified here and left		such a binary encoding is explicitly not specified here and left
	to profiles or applications, specifically note that a binary		to profiles or applications, specifically note that a binary
	skipping to change at page 36, line 8 ¶		skipping to change at page 36, line 8 ¶
	Figure 16: CBOR Mappings to Token Introspection Parameters.		Figure 16: 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 [RFC8392].		specified in [RFC8392].
	In order to facilitate offline processing of access tokens, this		In order to facilitate offline processing of access tokens, this
	document uses the "cnf" claim from		document uses the "cnf" claim from
	[I-D.ietf-ace-cwt-proof-of-possession] and the "scope" claim from		[I-D.ietf-ace-cwt-proof-of-possession] and the "scope" claim from
	[I-D.ietf-oauth-token-exchange] for JWT- and CWT-encoded tokens. In		[RFC8693] for JWT- and CWT-encoded tokens. In addition to string
	addition to string encoding specified for the "scope" claim, a binary		encoding specified for the "scope" claim, a binary encoding MAY be
	encoding MAY be used. The syntax of such an encoding is explicitly		used. The syntax of such an encoding is explicitly not specified
	not specified here and left to profiles or applications, specifically		here and left to profiles or applications, specifically note that a
	note that a binary encoded scope does not necessarily use the space		binary encoded scope does not necessarily use the space character
	character '0x20' to delimit scope-tokens.		'0x20' to delimit scope-tokens.
	If the AS needs to convey a hint to the RS about which profile it		If the AS needs to convey a hint to the RS about which profile it
	should use to communicate with the client, the AS MAY include an		should use to communicate with the client, the AS MAY include an
	"ace_profile" claim in the access token, with the same syntax and		"ace_profile" claim in the access token, with the same syntax and
	semantics as defined in Section 5.6.4.3.		semantics as defined in Section 5.6.4.3.
	If the client submitted a client-nonce parameter in the access token		If the client submitted a client-nonce parameter in the access token
	request Section 5.6.4.4, the AS MUST include the value of this		request Section 5.6.4.4, the AS MUST include the value of this
	parameter in the "cnonce" claim specified here. The "cnonce" claim		parameter in the "cnonce" claim specified here. The "cnonce" claim
	uses binary encoding.		uses binary encoding.
	skipping to change at page 41, line 22 ¶		skipping to change at page 41, line 22 ¶
	JSON number.		JSON number.
	o Processing this claim requires that the RS does the following:		o Processing this claim requires that the RS does the following:
	* For each token the RS receives, that contains an "exi" claim:		* For each token the RS receives, that contains an "exi" claim:
	Keep track of the time it received that token and revisit that		Keep track of the time it received that token and revisit that
	list regularly to expunge expired tokens.		list regularly to expunge expired tokens.
	* Keep track of the identifiers of tokens containing the "exi"		* Keep track of the identifiers of tokens containing the "exi"
	claim that have expired (in order to avoid accepting them		claim that have expired (in order to avoid accepting them
	again).		again). In order to avoid an unbounded memory usage growth,
			this MUST be implemented in the following way when the "exi"
			claim is used:
			+ When creating the token, the AS MUST add a 'cti' claim ( or
			'jti' for JWTs) to the access token. The value of this
			claim MUST be created as the binary representation of the
			concatenation of the identifier of the RS with a sequence
			number counting the tokens containing an 'exi' claim, issued
			by this AS for the RS.
			+ The RS MUST store the highest sequence number of an expired
			token containing the "exi" claim that it has seen, and treat
			tokens with lower sequence numbers as expired.
	If a token that authorizes a long running request such as a CoAP		If a token that authorizes a long running request such as a CoAP
	Observe [RFC7641] expires, the RS MUST send an error response with		Observe [RFC7641] expires, the RS MUST send an error response with
	the response code equivalent to the CoAP code 4.01 (Unauthorized) to		the response code equivalent to the CoAP code 4.01 (Unauthorized) to
	the client and then terminate processing the long running request.		the client and then terminate processing the long running request.
	5.8.4. Key Expiration		5.8.4. Key Expiration
	The AS provides the client with key material that the RS uses. This		The AS provides the client with key material that the RS uses. This
	can either be a common symmetric PoP-key, or an asymmetric key used		can either be a common symmetric PoP-key, or an asymmetric key used
	skipping to change at page 46, line 35 ¶		skipping to change at page 46, line 47 ¶
	predictable alternative. The "exi" approach has some drawbacks that		predictable alternative. The "exi" approach has some drawbacks that
	need to be considered:		need to be considered:
	A malicious client may hold back tokens with the "exi" claim in		A malicious client may hold back tokens with the "exi" claim in
	order to prolong their lifespan.		order to prolong their lifespan.
	If an RS loses state (e.g. due to an unscheduled reboot), it may		If an RS loses state (e.g. due to an unscheduled reboot), it may
	loose the current values of counters tracking the "exi" claims of		loose the current values of counters tracking the "exi" claims of
	tokens it is storing.		tokens it is storing.
	The RS needs to keep state about expired tokens that used "exi" in
	order to be sure not to accept it again. Attacker may use this to
	deplete the RS's storage resources.
	The first drawback is inherent to the deployment scenario and the		The first drawback is inherent to the deployment scenario and the
	"exi" solution. It can therefore not be mitigated without requiring		"exi" solution. It can therefore not be mitigated without requiring
	the the RS be online at times. The second drawback can be mitigated		the the RS be online at times. The second drawback can be mitigated
	by regularly storing the value of "exi" counters to persistent		by regularly storing the value of "exi" counters to persistent
	memory. The third problem can be mitigated by the AS, by assigning		memory.
	identifiers (e.g. 'cti') to the tokens, that include an RS identifier
	and a sequence number. The RS would then just have to store the
	highest sequence number of an expired token it has seen, thus
	limiting the necessary state.
	6.7. Combining profiles		6.7. Combining profiles
	There may be use cases were different profiles of this framework are		There may be use cases were different profiles of this framework are
	combined. For example, an MQTT-TLS profile is used between the		combined. For example, an MQTT-TLS profile is used between the
	client and the RS in combination with a CoAP-DTLS profile for		client and the RS in combination with a CoAP-DTLS profile for
	interactions between the client and the AS. The security of a		interactions between the client and the AS. The security of a
	profile MUST NOT depend on the assumption that the profile is used		profile MUST NOT depend on the assumption that the profile is used
	for all the different types of interactions in this framework.		for all the different types of interactions in this framework.
	skipping to change at page 48, line 8 ¶		skipping to change at page 48, line 8 ¶
	obsolete profile that in turn specifies a vulnerable security		obsolete profile that in turn specifies a vulnerable security
	mechanism via the authz-info endpoint. Such an attack would require		mechanism via the authz-info endpoint. Such an attack would require
	a valid access token containing an "ace_profile" claim requesting the		a valid access token containing an "ace_profile" claim requesting the
	use of said obsolete profile. Resource Owners should update the		use of said obsolete profile. Resource Owners should update the
	configuration of their RS's to prevent them from using such obsolete		configuration of their RS's to prevent them from using such obsolete
	profiles.		profiles.
	6.9. Identifying audiences		6.9. Identifying audiences
	The audience claim as defined in [RFC7519] and the equivalent		The audience claim as defined in [RFC7519] and the equivalent
	"audience" parameter from [I-D.ietf-oauth-token-exchange] are		"audience" parameter from [RFC8693] are intentionally vague on how to
	intentionally vague on how to match the audience value to a specific		match the audience value to a specific RS. This is intended to allow
	RS. This is intended to allow application specific semantics to be		application specific semantics to be used. This section attempts to
	used. This section attempts to give some general guidance for the		give some general guidance for the use of audiences in constrained
	use of audiences in constrained environments.		environments.
	URLs are not a good way of identifying mobile devices that can switch		URLs are not a good way of identifying mobile devices that can switch
	networks and thus be associated with new URLs. If the audience		networks and thus be associated with new URLs. If the audience
	represents a single RS, and asymmetric keys are used, the RS can be		represents a single RS, and asymmetric keys are used, the RS can be
	uniquely identified by a hash of its public key. If this approach is		uniquely identified by a hash of its public key. If this approach is
	used this framework RECOMMENDS to apply the procedure from section 3		used this framework RECOMMENDS to apply the procedure from section 3
	of [RFC6920].		of [RFC6920].
	If the audience addresses a group of resource servers, the mapping of		If the audience addresses a group of resource servers, the mapping of
	group identifier to individual RS has to be provisioned to each RS		group identifier to individual RS has to be provisioned to each RS
	skipping to change at page 55, line 48 ¶		skipping to change at page 55, line 48 ¶
	This specification registers the following new claims in the "CBOR		This specification registers the following new claims in the "CBOR
	Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims].		Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims].
	o Claim Name: "scope"		o Claim Name: "scope"
	o Claim Description: The scope of an access token as defined in		o Claim Description: The scope of an access token as defined in
	[RFC6749].		[RFC6749].
	o JWT Claim Name: scope		o JWT Claim Name: scope
	o Claim Key: TBD (suggested: 9)		o Claim Key: TBD (suggested: 9)
	o Claim Value Type(s): byte string or text string		o Claim Value Type(s): byte string or text string
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 4.2 of		o Specification Document(s): Section 4.2 of [RFC8693]
	[I-D.ietf-oauth-token-exchange]
	o Claim Name: "ace_profile"		o Claim Name: "ace_profile"
	o Claim Description: The ACE profile a token is supposed to be used		o Claim Description: The ACE profile a token is supposed to be used
	with.		with.
	o JWT Claim Name: ace_profile		o JWT Claim Name: ace_profile
	o Claim Key: TBD (suggested: 38)		o Claim Key: TBD (suggested: 38)
	o Claim Value Type(s): integer		o Claim Value Type(s): integer
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 5.8 of [this document]		o Specification Document(s): Section 5.8 of [this document]
	o Claim Name: "exi"		o Claim Name: "exi"
	o Claim Description: The expiration time of a token measured from		o Claim Description: The expiration time of a token measured from
	when it was received at the RS in seconds.		when it was received at the RS in seconds.
	o JWT Claim Name: exi		o JWT Claim Name: exi
	skipping to change at page 57, line 4 ¶		skipping to change at page 56, line 50 ¶
	Required parameters: none		Required parameters: none
	Optional parameters: none		Optional parameters: none
	Encoding considerations: Must be encoded as CBOR map containing the		Encoding considerations: Must be encoded as CBOR map containing the
	protocol parameters defined in [this document].		protocol parameters defined in [this document].
	Security considerations: See Section 6 of this document.		Security considerations: See Section 6 of this document.
	Interoperability considerations: n/a		Interoperability considerations: n/a
	Published specification: [this document]
			Published specification: [this document]
	Applications that use this media type: The type is used by		Applications that use this media type: The type is used by
	authorization servers, clients and resource servers that support the		authorization servers, clients and resource servers that support the
	ACE framework as specified in [this document].		ACE framework as specified in [this document].
	Additional information:		Additional information:
	Magic number(s): n/a		Magic number(s): n/a
	File extension(s): .ace		File extension(s): .ace
	skipping to change at page 59, line 25 ¶		skipping to change at page 59, line 23 ¶
	[I-D.ietf-ace-cwt-proof-of-possession]		[I-D.ietf-ace-cwt-proof-of-possession]
	Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.		Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
	Tschofenig, "Proof-of-Possession Key Semantics for CBOR		Tschofenig, "Proof-of-Possession Key Semantics for CBOR
	Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-		Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
	possession-11 (work in progress), October 2019.		possession-11 (work in progress), October 2019.
	[I-D.ietf-ace-oauth-params]		[I-D.ietf-ace-oauth-params]
	Seitz, L., "Additional OAuth Parameters for Authorization		Seitz, L., "Additional OAuth Parameters for Authorization
	in Constrained Environments (ACE)", draft-ietf-ace-oauth-		in Constrained Environments (ACE)", draft-ietf-ace-oauth-
	params-10 (work in progress), January 2020.		params-11 (work in progress), January 2020.
	[I-D.ietf-oauth-token-exchange]
	Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
	Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth-
	token-exchange-19 (work in progress), July 2019.
	[IANA.CborWebTokenClaims]		[IANA.CborWebTokenClaims]
	IANA, "CBOR Web Token (CWT) Claims",		IANA, "CBOR Web Token (CWT) Claims",
	<https://www.iana.org/assignments/cwt/cwt.xhtml#claims-		<https://www.iana.org/assignments/cwt/cwt.xhtml#claims-
	registry>.		registry>.
	[IANA.JsonWebTokenClaims]		[IANA.JsonWebTokenClaims]
	IANA, "JSON Web Token Claims",		IANA, "JSON Web Token Claims",
	<https://www.iana.org/assignments/jwt/jwt.xhtml#claims>.		<https://www.iana.org/assignments/jwt/jwt.xhtml#claims>.
	skipping to change at page 61, line 39 ¶		skipping to change at page 61, line 30 ¶
	<https://www.rfc-editor.org/info/rfc8152>.		<https://www.rfc-editor.org/info/rfc8152>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,		[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
	"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,		"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
	May 2018, <https://www.rfc-editor.org/info/rfc8392>.		May 2018, <https://www.rfc-editor.org/info/rfc8392>.
			[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
			and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
			DOI 10.17487/RFC8693, January 2020,
			<https://www.rfc-editor.org/info/rfc8693>.
	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-
End of changes. 19 change blocks.
	39 lines changed or deleted		44 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/