rfc9201.original		rfc9201.txt
	ACE Working Group L. Seitz		Internet Engineering Task Force (IETF) L. Seitz
	Internet-Draft Combitech		Request for Comments: 9201 Combitech
	Intended status: Standards Track May 5, 2021		Category: Standards Track August 2022
	Expires: November 6, 2021		ISSN: 2070-1721
	Additional OAuth Parameters for Authorization in Constrained		Additional OAuth Parameters for Authentication and Authorization for
	Environments (ACE)		Constrained Environments (ACE)
	draft-ietf-ace-oauth-params-15
	Abstract		Abstract
	This specification defines new parameters and encodings for the OAuth		This specification defines new parameters and encodings for the OAuth
	2.0 token and introspection endpoints when used with the framework		2.0 token and introspection endpoints when used with the framework
	for authentication and authorization for constrained environments		for Authentication and Authorization for Constrained Environments
	(ACE). These are used to express the proof-of-possession key the		(ACE). These are used to express the proof-of-possession (PoP) key
	client wishes to use, the proof-of-possession key that the		the client wishes to use, the PoP key that the authorization server
	Authorization Server has selected, and the key the Resource Server		has selected, and the PoP key the resource server uses to
	uses to authenticate to the client.		authenticate to the client.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on November 6, 2021.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9201.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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
	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 Revised BSD License text as described in Section 4.e of the
	the Trust Legal Provisions and are provided without warranty as		Trust Legal Provisions and are provided without warranty as described
	described in the Simplified BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology
	3. Parameters for the Token Endpoint . . . . . . . . . . . . . . 3		3. Parameters for the Token Endpoint
	3.1. Client-to-AS Request . . . . . . . . . . . . . . . . . . 3		3.1. Client-to-AS Request
	3.2. AS-to-Client Response . . . . . . . . . . . . . . . . . . 4		3.2. AS-to-Client Response
	4. Parameters for the Introspection Endpoint . . . . . . . . . . 6		4. Parameters for the Introspection Endpoint
	5. Confirmation Method Parameters . . . . . . . . . . . . . . . 7		5. Confirmation Method Parameters
	6. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . . . 8		6. CBOR Mappings
	7. Requirements when using asymmetric keys . . . . . . . . . . . 8		7. Requirements When Using Asymmetric Keys
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 8		8. Security Considerations
	9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9		9. Privacy Considerations
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		10. IANA Considerations
	10.1. OAuth Parameter Registration . . . . . . . . . . . . . . 9		10.1. OAuth Parameter Registration
	10.2. OAuth Parameters CBOR Mappings Registration . . . . . . 9		10.2. OAuth Parameters CBOR Mappings Registration
	10.3. OAuth Token Introspection Response CBOR Mappings		10.3. OAuth Token Introspection Response CBOR Mappings
	Registration . . . . . . . . . . . . . . . . . . . . . . 10		Registration
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		11. References
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		11.1. Normative References
	12.1. Normative References . . . . . . . . . . . . . . . . . . 10		11.2. Informative References
	12.2. Informative References . . . . . . . . . . . . . . . . . 11		Acknowledgments
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11		Author's Address
	1. Introduction		1. Introduction
	The Authentication and Authorization for Constrained Environments		The Authentication and Authorization for Constrained Environments
	(ACE) specification [I-D.ietf-ace-oauth-authz] requires some new		(ACE) specification [RFC9200] requires some new parameters for
	parameters for interactions with the OAuth 2.0 [RFC6749] token and		interactions with the OAuth 2.0 [RFC6749] token and introspection
	introspection endpoints, as well as some new claims to be used in		endpoints, as well as some new claims to be used in access tokens.
	access tokens. These parameters and claims can also be used in other		These parameters and claims can also be used in other contexts and
	contexts and have therefore been put into a dedicated document, to		have therefore been put into a dedicated document to facilitate their
	facilitate their use in a manner independent of		use in a manner independent of [RFC9200].
	[I-D.ietf-ace-oauth-authz].
	Note that although all examples are shown in Concise Binary Object		Note that although all examples are shown in Concise Binary Object
	Representation (CBOR) [RFC8949], JSON [RFC8259] MAY be used as an		Representation (CBOR) [RFC8949], JSON [RFC8259] MAY be used as an
	alternative for HTTP-based communications, as specified in		alternative for HTTP-based communications, as specified in [RFC9200].
	[I-D.ietf-ace-oauth-authz].
	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 BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Readers are assumed to be familiar with the terminology from		Readers are assumed to be familiar with the terminology from
	[I-D.ietf-ace-oauth-authz], especially the terminology for entities		[RFC9200], especially the terminology for entities in the
	in the architecture such as client (C), resource server (RS) and		architecture such as client (C), resource server (RS), and
	authorization server (AS).		authorization server (AS).
	Terminology from [RFC8152] is used in the examples, especially		Terminology from [RFC8152] is used in the examples, especially
	COSE_Key defined in section 7 of [RFC8152].		COSE_Key, which is defined in Section 7 of [RFC8152].
	Note that the term "endpoint" is used here following its OAuth 2.0		Note that the term "endpoint" is used here following its OAuth 2.0
	[RFC6749] definition, which is to denote resources such as token and		[RFC6749] definition, which is to denote resources such as token and
	introspection at the AS and authz-info at the RS. The Constrained		introspection at the AS and authz-info at the RS. The Constrained
	Application Protocol (CoAP) [RFC7252] definition, which is "An entity		Application Protocol (CoAP) [RFC7252] definition, which is "[a]n
	participating in the CoAP protocol" is not used in this		entity participating in the CoAP protocol", is not used in this
	specification.		specification.
	3. Parameters for the Token Endpoint		3. Parameters for the Token Endpoint
	This section defines additional parameters for the interactions with		This section defines additional parameters for the interactions with
	the token endpoint in the ACE framework [I-D.ietf-ace-oauth-authz].		the token endpoint in the ACE framework [RFC9200].
	3.1. Client-to-AS Request		3.1. Client-to-AS Request
	This section defines the "req_cnf" parameter allowing clients to		This section defines the req_cnf parameter allowing clients to
	request a specific proof-of-possession key in an access token from a		request a specific PoP key in an access token from a token endpoint
	token endpoint in the ACE framework [I-D.ietf-ace-oauth-authz]:		in the ACE framework [RFC9200]:
	req_cnf		req_cnf
	OPTIONAL. This field contains information about the key the		OPTIONAL. This field contains information about the key the
	client would like to bind to the access token for proof-of-		client would like to bind to the access token for proof of
	possession. It is RECOMMENDED that an AS rejects a request		possession. It is RECOMMENDED that an AS rejects a request
	containing a symmetric key value in the 'req_cnf' field		containing a symmetric key value in the req_cnf field
	(kty=Symmetric), since the AS is expected to be able to generate		(kty=Symmetric), since the AS is expected to be able to generate
	better symmetric keys than a constrained client (Note: this does		better symmetric keys than a constrained client. (Note: this does
	not apply to key identifiers referencing a symmetric key). The AS		not apply to key identifiers referencing a symmetric key.) The AS
	MUST verify that the client really is in possession of the		MUST verify that the client really is in possession of the
	corresponding key. Profiles of [I-D.ietf-ace-oauth-authz] using		corresponding key. Profiles of [RFC9200] using this specification
	this specification MUST define the proof-of-possession method used		MUST define the PoP method used by the AS if they allow clients to
	by the AS, if they allow clients to use this request parameter.		use this request parameter. Values of this parameter follow the
	Values of this parameter follow the syntax and semantics of the		syntax and semantics of the cnf claim either from Section 3.1 of
	"cnf" claim either from section 3.1 of [RFC8747] for CBOR-based		[RFC8747] for CBOR-based interactions or from Section 3.1 of
	interactions or from section 3.1 of [RFC7800] for JSON-based		[RFC7800] for JSON-based interactions.
	interactions.
	Figure 1 shows a request for an access token using the "req_cnf"		Figure 1 shows a request for an access token using the req_cnf
	parameter to request a specific public key as proof-of-possession		parameter to request a specific public key as a PoP key. The content
	key. The content is displayed in CBOR diagnostic notation, without		is displayed in CBOR diagnostic notation with line breaks for better
	abbreviations and with line-breaks for better readability.		readability.
	Header: POST (Code=0.02)		Header: POST (Code=0.02)
	Uri-Host: "as.example.com"		Uri-Host: "as.example.com"
	Uri-Path: "token"		Uri-Path: "token"
	Content-Format: "application/ace+cbor"		Content-Format: application/ace+cbor
	Payload:		Payload:
	{		{
	"req_cnf" : {		/ req_cnf / 4 : {
	"COSE_Key" : {		/ COSE_Key / 1 : {
	"kty" : "EC2",		/ kty / 1 : 2 /EC2/,
	"kid" : h'11',		/ kid / 2 : h'11',
	"crv" : "P-256",		/ crv / -1 : 1 /P-256/,
	"x" : h'BAC5B11CAD8F99F9C72B05CF4B9E26D24		/ x / -2 : h'BAC5B11CAD8F99F9C72B05CF4B9E26D24
	4DC189F745228255A219A86D6A09EFF',		4DC189F745228255A219A86D6A09EFF',
	"y" : h'20138BF82DC1B6D562BE0FA54AB7804A3		/ y / -3 : h'20138BF82DC1B6D562BE0FA54AB7804A3
	A64B6D72CCFED6B6FB6ED28BBFC117E'		A64B6D72CCFED6B6FB6ED28BBFC117E'
	}		}
	}		}
	}		}
	Figure 1: Example request for an access token bound to an asymmetric		Figure 1: Example Request for an Access Token Bound to an
	key.		Asymmetric Key
	3.2. AS-to-Client Response		3.2. AS-to-Client Response
	This section defines the following additional parameters for an AS		This section defines the following additional parameters for an AS
	response to a request to the token endpoint:		response to a request to the token endpoint:
	cnf		cnf
	REQUIRED if the token type is "pop" and a symmetric key is used.		REQUIRED if the token type is "pop" and a symmetric key is used.
	MAY be present for asymmetric proof-of-possession keys. This		MAY be present for asymmetric PoP keys. This field contains the
	field contains the proof-of-possession key that the AS selected		PoP key that the AS selected for the token. Values of this
	for the token. Values of this parameter follow the syntax and		parameter follow the syntax and semantics of the cnf claim either
	semantics of the "cnf" claim either from section 3.1 of [RFC8747]		from Section 3.1 of [RFC8747] for CBOR-based interactions or from
	for CBOR-based interactions or from section 3.1 of [RFC7800] for		Section 3.1 of [RFC7800] for JSON-based interactions. See
	JSON-based interactions. See Section 5 for additional discussion		Section 5 for additional discussion of the usage of this
	of the usage of this parameter.		parameter.
	rs_cnf		rs_cnf
	OPTIONAL if the token type is "pop" and asymmetric keys are used.		OPTIONAL if the token type is "pop" and asymmetric keys are used.
	MUST NOT be present otherwise. This field contains information		MUST NOT be present otherwise. This field contains information
	about the public key used by the RS to authenticate. If this		about the public key used by the RS to authenticate. If this
	parameter is absent, either the RS does not use a public key or		parameter is absent, either the RS does not use a public key or
	the AS knows that the RS can authenticate itself to the client		the AS knows that the RS can authenticate itself to the client
	without additional information. Values of this parameter follow		without additional information. Values of this parameter follow
	the syntax and semantics of the "cnf" claim either from section		the syntax and semantics of the cnf claim either from Section 3.1
	3.1 of [RFC8747] for CBOR-based interactions or from section 3.1		of [RFC8747] for CBOR-based interactions or from Section 3.1 of
	of [RFC7800] for JSON-based interactions. See Section 5 for		[RFC7800] for JSON-based interactions. See Section 5 for
	additional discussion of the usage of this parameter.		additional discussion of the usage of this parameter.
	Figure 2 shows an AS response containing a token and a "cnf"		Figure 2 shows an AS response containing a token and a cnf parameter
	parameter with a symmetric proof-of-possession key.		with a symmetric PoP key.
	Header: Created (Code=2.01)		Header: Created (Code=2.01)
	Content-Format: "application/ace+cbor"		Content-Format: application/ace+cbor
	Payload:		Payload:
	{		{
	"access_token" : h'4A5015DF686428 ...		/ access_token / 1 : h'4A5015DF686428/...
	(remainder of CWT omitted for brevity;		(remainder of CWT omitted for brevity;
	CWT contains COSE_Key in the "cnf" claim)',		CWT contains COSE_Key in the "cnf" claim)/',
	"cnf" : {		/ cnf / 8 : {
	"COSE_Key" : {		/ COSE_Key / 1 : {
	"kty" : "Symmetric",		/ kty / 1 : 4 / Symmetric /,
	"kid" : h'DFD1AA97',		/ kid / 2 : h'DFD1AA97',
	"k" : h'849B5786457C1491BE3A76DCEA6C427108'		/ k / -1 : h'849B5786457C1491BE3A76DCEA6C427108'
	}		}
	}		}
	}		}
	Figure 2: Example AS response with an access token bound to a		Figure 2: Example AS Response with an Access Token Bound to a
	symmetric key.		Symmetric Key
	Figure 3 shows an AS response containing a token bound to a		Figure 3 shows an AS response containing a token bound to a
	previously requested asymmetric proof-of-possession key (not shown)		previously requested asymmetric PoP key (not shown) and an rs_cnf
	and a "rs_cnf" parameter containing the public key of the RS.		parameter containing the public key of the RS.
	Header: Created (Code=2.01)		Header: Created (Code=2.01)
	Content-Format: "application/ace+cbor"		Content-Format: application/ace+cbor
	Payload:		Payload:
	{		{
	"access_token" : h'D08343A1010AA1054D2A45DF6FBC5A5A ...		/ access_token / 1 : h'D08343A1010AA1054D2A45DF6FBC5A5A/...
	(remainder of CWT omitted for brevity)',		(remainder of CWT omitted for brevity)/',
	"rs_cnf" : {		/ rs_cnf / 41 : {
	"COSE_Key" : {		/ COSE_Key / 1 : {
	"kty" : "EC2",		/ kty / 1 : 2 /EC2/,
	"kid" : h'12',		/ kid / 2 : h'12',
	"crv" : "P-256",		/ crv / -1 : 1 /P-256/,
	"x" : h'BCEE7EAAC162F91E6F330F5771211E220		/ x / -2 : h'BCEE7EAAC162F91E6F330F5771211E220
	B8B546C96589B0AC4AD0FD24C77E1F1',		B8B546C96589B0AC4AD0FD24C77E1F1',
	"y" : h'C647B38C55EFBBC4E62E651720F002D5D		/ y / -3 : h'C647B38C55EFBBC4E62E651720F002D5D
	75B2E0C02CD1326E662BCA222B90416'		75B2E0C02CD1326E662BCA222B90416'
	}		}
	}		}
	}		}
	Figure 3: Example AS response, including the RS's public key.		Figure 3: Example AS Response Including the RS's Public Key
	4. Parameters for the Introspection Endpoint		4. Parameters for the Introspection Endpoint
	This section defines the use of CBOR instead of JSON for the "cnf"		This section defines the use of CBOR instead of JSON for the cnf
	introspection response parameter specified in section 9.4 of		introspection response parameter specified in Section 9.4 of
	[RFC8705].		[RFC8705].
	If CBOR is used instead of JSON in an interaction with the		If CBOR is used instead of JSON in an interaction with the
	introspection endpoint, the AS MUST use the parameter mapping		introspection endpoint, the AS MUST use the parameter mapping
	specified in Figure 5 and the value must follow the syntax of "cnf"		specified in Table 1 and the value must follow the syntax of cnf
	claim values from section 3.1 of [RFC8747].		claim values from Section 3.1 of [RFC8747].
	Figure 4 shows an AS response to an introspection request including		Figure 4 shows an AS response to an introspection request including
	the "cnf" parameter to indicate the proof-of-possession key bound to		the cnf parameter to indicate the PoP key bound to the token.
	the token.
	Header: Created (Code=2.01)		Header: Created (Code=2.01)
	Content-Format: "application/ace+cbor"		Content-Format: application/ace+cbor
	Payload:		Payload:
	{		{
	"active" : true,		/ active / 10 : true,
	"scope" : "read",		/ scope / 9 : "read",
	"aud" : "tempSensor4711",		/ aud / 3 : "tempSensor4711",
	"cnf" : {		/ cnf / 8 : {
	"COSE_Key" : {		/ COSE_Key / 1 : {
	"kty" : "EC2",		/ kty / 1 : 2 /EC2/,
	"kid" : h'11',		/ kid / 2 : h'11',
	"crv" : "P-256",		/ crv / -1 : 1 /P-256/,
	"x" : h'BAC5B11CAD8F99F9C72B05CF4B9E26D24		/ x / -2 : h'BAC5B11CAD8F99F9C72B05CF4B9E26D24
	4DC189F745228255A219A86D6A09EFF',		4DC189F745228255A219A86D6A09EFF',
	"y" : h'20138BF82DC1B6D562BE0FA54AB7804A3		/ y / -3 : h'20138BF82DC1B6D562BE0FA54AB7804A3
	A64B6D72CCFED6B6FB6ED28BBFC117E'		A64B6D72CCFED6B6FB6ED28BBFC117E'
	}		}
	}		}
	}		}
	Figure 4: Example introspection response.		Figure 4: Example Introspection Response
	5. Confirmation Method Parameters		5. Confirmation Method Parameters
	The confirmation method parameters are used in		The confirmation method parameters are used in [RFC9200] as follows:
	[I-D.ietf-ace-oauth-authz] as follows:
	o "req_cnf" in the access token request C -> AS, OPTIONAL to		* req_cnf in the access token request C -> AS, OPTIONAL to indicate
	indicate the client's raw public key, or the key-identifier of a		the client's raw public key or the key identifier of a previously
	previously established key between C and RS that the client wishes		established key between the C and RS that the client wishes to use
	to use for proof-of-possession of the access token.		for proof of possession of the access token.
	o "cnf" in the token response AS -> C, OPTIONAL if using an		* cnf in the token response AS -> C, OPTIONAL if using an asymmetric
	asymmetric key or a key that the client requested via a key		key or a key that the client requested via a key identifier in the
	identifier in the request. REQUIRED if the client didn't specify		request. REQUIRED if the client didn't specify a req_cnf and
	a "req_cnf" and symmetric keys are used. Used to indicate the		symmetric keys are used. Used to indicate the symmetric key
	symmetric key generated by the AS for proof-of-possession of the		generated by the AS for proof of possession of the access token.
	access token.
	o "cnf" in the introspection response AS -> RS, REQUIRED if the		* cnf in the introspection response AS -> RS, REQUIRED if the access
	access token that was subject to introspection is a proof-of-		token that was subject to introspection is a PoP token, absent
	possession token, absent otherwise. Indicates the proof-of-		otherwise. Indicates the PoP key bound to the access token.
	possession key bound to the access token.
	o "rs_cnf" in the token response AS -> C, OPTIONAL to indicate the		* rs_cnf in the token response AS -> C, OPTIONAL to indicate the
	public key of the RS, if it uses one to authenticate itself to the		public key of the RS if it uses one to authenticate itself to the
	client and the binding between key and RS identity is not		client and the binding between the key and RS identity is not
	established through other means.		established through other means.
	Note that the COSE_Key structure in a confirmation claim or parameter		Note that the COSE_Key structure in a confirmation claim or parameter
	may contain an "alg" or "key_ops" parameter. If such parameters are		may contain an alg or key_ops parameter. If such parameters are
	present, a client MUST NOT use a key that is incompatible with the		present, a client MUST NOT use a key that is incompatible with the
	profile or proof-of-possession algorithm according to those		profile or PoP algorithm according to those parameters. An RS MUST
	parameters. An RS MUST reject a proof-of-possession using such a key		reject a proof of possession using such a key with a response code
	with a response code equivalent to the CoAP code 4.00 (Bad Request).		equivalent to the CoAP code 4.00 (Bad Request).
	If an access token is issued for an audience that includes several		If an access token is issued for an audience that includes several
	RS, the "rs_cnf" parameter MUST NOT be used, since the client cannot		RSs, the rs_cnf parameter MUST NOT be used, since the client cannot
	determine for which RS the key applies. This document recommends to		determine for which RS the key applies. This document recommends to
	specify a different endpoint that the client can use to acquire RS		specify a different endpoint that the client can use to acquire RS
	authentication keys in such cases. The specification of such an		authentication keys in such cases. The specification of such an
	endpoint is out of scope for this document.		endpoint is out of scope for this document.
	6. CBOR Mappings		6. CBOR Mappings
	If CBOR is used, the new parameters and claims defined in this		If CBOR is used, the new parameters and claims defined in this
	document MUST be mapped to CBOR types as specified in Figure 5, using		document MUST be mapped to CBOR types, as specified in Table 1, using
	the given integer abbreviation for the map key.		the given integer abbreviation for the map key.
	/----------+----------+-------------------------------------\		+=========+==========+============+========================+
	| Name | CBOR Key | Value Type | Usage |		| Name | CBOR Key | Value Type | Usage |
	|----------+----------+-------------------------------------|		+=========+==========+============+========================+
	| req_cnf | TBD (4) | map | token request |		| req_cnf | 4 | map | token request |
	| cnf | TBD (8) | map | token response |		+---------+----------+------------+------------------------+
	| cnf | TBD (8) | map | introspection response |		| cnf | 8 | map | token response |
	| rs_cnf | TBD (41) | map | token response |		+---------+----------+------------+------------------------+
	\----------+----------+------------+------------------------/		| cnf | 8 | map | introspection response |
			+---------+----------+------------+------------------------+
			| rs_cnf | 41 | map | token response |
			+---------+----------+------------+------------------------+
	Figure 5: CBOR mappings for new parameters and claims.		Table 1: CBOR Mappings for New Parameters and Claims
	7. Requirements when using asymmetric keys		7. Requirements When Using Asymmetric Keys
	An RS using asymmetric keys to authenticate to the client MUST NOT		An RS using asymmetric keys to authenticate to the client MUST NOT
	hold several different asymmetric key pairs, applicable to the same		hold several different asymmetric key pairs applicable to the same
	authentication algorithm. For example when using DTLS, the RS MUST		authentication algorithm. For example, when using DTLS, the RS MUST
	NOT hold several asymmetric key pairs applicable to the same cipher		NOT hold several asymmetric key pairs applicable to the same cipher
	suite. The reason for this restriction is that the RS has no way of		suite. The reason for this restriction is that the RS has no way of
	determining which key to use before the client's identity is		determining which key to use before the client's identity is
	established. Therefore authentication attempts by the RS could		established. Therefore, authentication attempts by the RS could
	randomly fail based on which key the RS selects, unless the algorithm		randomly fail based on which key the RS selects, unless the algorithm
	negotiation produces a unique choice of key pair for the RS.		negotiation produces a unique choice of key pair for the RS.
	8. Security Considerations		8. Security Considerations
	This document is an extension to [I-D.ietf-ace-oauth-authz]. All		This document is an extension to [RFC9200]. All security
	security considerations from that document apply here as well.		considerations from that document apply here as well.
	9. Privacy Considerations		9. Privacy Considerations
	This document is an extension to [I-D.ietf-ace-oauth-authz]. All		This document is an extension to [RFC9200]. All privacy
	privacy considerations from that document apply here as well.		considerations from that document apply here as well.
	10. IANA Considerations		10. IANA Considerations
	10.1. OAuth Parameter Registration		10.1. OAuth Parameter Registration
	This section registers the following parameters in the "OAuth		This section registers the following parameters in the "OAuth
	Parameters" registry [IANA.OAuthParameters]:		Parameters" registry [IANA.OAuthParameters]:
	o Name: "req_cnf"		Name: req_cnf
	o Parameter Usage Location: token request		Parameter Usage Location: token request
	o Change Controller: IESG		Change Controller: IETF
	o Reference: Section 5 of [this document]		Reference: Section 5 of RFC 9201
	o Name: "rs_cnf"		Name: rs_cnf
	o Parameter Usage Location: token response		Parameter Usage Location: token response
	o Change Controller: IESG		Change Controller: IETF
	o Reference: Section 5 of [this document]		Reference: Section 5 of RFC 9201
	o Name: "cnf"		Name: cnf
	o Parameter Usage Location: token response		Parameter Usage Location: token response
	o Change Controller: IESG		Change Controller: IETF
	o Reference: Section 5 of [this document]		Reference: Section 5 of RFC 9201
	10.2. OAuth Parameters CBOR Mappings Registration		10.2. OAuth Parameters CBOR Mappings Registration
	This section registers the following parameter mappings in the "OAuth		This section registers the following parameter mappings in the "OAuth
	Parameters CBOR Mappings" registry established in section 8.9. of		Parameters CBOR Mappings" registry established in Section 8.10 of
	[I-D.ietf-ace-oauth-authz].		[RFC9200].
	o Name: "req_cnf"		Name: req_cnf
	o CBOR key: TBD (suggested: 4)		CBOR Key: 4
	o Change Controller: IESG		Value Type: map
	o Reference: Section 3.1 of [this document]		Reference: Section 3.1 of RFC 9201
			Original Specification: RFC 9201
	o Name: "cnf"		Name: cnf
	o CBOR key: TBD (suggested: 8)		CBOR Key: 8
	o Change Controller: IESG		Value Type: map
	o Reference: Section 3.2 of [this document]		Reference: Section 3.2 of RFC 9201
			Original Specification: RFC 9201
	o Name: "rs_cnf"		Name: rs_cnf
	o CBOR key: TBD (suggested: 41)		CBOR Key: 41
	o Change Controller: IESG		Value Type: map
	o Reference: Section 3.2 of [this document]		Reference: Section 3.2 of RFC 9201
			Original Specification: RFC 9201
	10.3. OAuth Token Introspection Response CBOR Mappings Registration		10.3. OAuth Token Introspection Response CBOR Mappings Registration
	This section registers the following parameter mapping in the "OAuth		This section registers the following parameter mapping in the "OAuth
	Token Introspection Response CBOR Mappings" registry established in		Token Introspection Response CBOR Mappings" registry established in
	section 8.11. of [I-D.ietf-ace-oauth-authz].		Section 8.12 of [RFC9200].
	o Name: "cnf"
	o CBOR key: TBD (suggested: 8)
	o Change Controller: IESG
	o Reference: Section 4 of [this document]
	11. Acknowledgments
	This document is a product of the ACE working group of the IETF.
	Special thanks to Brian Campbell for his thorough review of this
	document.
	Ludwig Seitz worked on this document as part of the CelticNext
	projects CyberWI, and CRITISEC with funding from Vinnova.
	12. References		Name: cnf
			CBOR Key: 8
			Value Type: map
			Reference: Section 4 of RFC 9201
			Original Specification: [RFC8705]
	12.1. Normative References		11. References
	[I-D.ietf-ace-oauth-authz]		11.1. Normative References
	Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
	H. Tschofenig, "Authentication and Authorization for
	Constrained Environments (ACE) using the OAuth 2.0
	Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-40
	(work in progress), April 2021.
	[IANA.OAuthParameters]		[IANA.OAuthParameters]
	IANA, "OAuth Parameters",		IANA, "OAuth Parameters",
	<https://www.iana.org/assignments/oauth-parameters/oauth-		<https://www.iana.org/assignments/oauth-parameters>.
	parameters.xhtml#parameters>.
	[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>.
	[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>.
	skipping to change at page 11, line 39 ¶		skipping to change at line 463 ¶
	[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		[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", STD 94, RFC 8949,		Representation (CBOR)", STD 94, RFC 8949,
	DOI 10.17487/RFC8949, December 2020,		DOI 10.17487/RFC8949, December 2020,
	<https://www.rfc-editor.org/info/rfc8949>.		<https://www.rfc-editor.org/info/rfc8949>.
	12.2. Informative References		[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
			H. Tschofenig, "Authentication and Authorization for
			Constrained Environments (ACE) Using the OAuth 2.0
			Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200,
			August 2022, <https://www.rfc-editor.org/info/rfc9200>.
			11.2. Informative References
	[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>.
			Acknowledgments
			This document is a product of the ACE Working Group of the IETF.
			Special thanks to Brian Campbell for his thorough review of this
			document.
			Ludwig Seitz worked on this document as part of the CelticNext
			projects CyberWI and CRITISEC with funding from Vinnova.
	Author's Address		Author's Address
	Ludwig Seitz		Ludwig Seitz
	Combitech		Combitech
	Djaeknegatan 31		Djäknegatan 31
	Malmoe 211 35		SE-211 35 Malmö
	Sweden		Sweden
	Email: ludwig.seitz@combitech.com		Email: ludwig.seitz@combitech.com
End of changes. 76 change blocks.
	249 lines changed or deleted		243 lines changed or added
This html diff was produced by rfcdiff 1.48.