rfc9200v1.xml   rfc9200.xml 
skipping to change at line 24 skipping to change at line 24
b) updated text in Section 5.8.4.4 b) updated text in Section 5.8.4.4
c) RFC 4648 added as a normative reference c) RFC 4648 added as a normative reference
For all changes, please see this diff file: For all changes, please see this diff file:
https://www.ietf.org/rfcdiff?url1=draft-ietf-ace-oauth-authz-43&url2=draft-ietf-ace-oauth-authz-46 https://www.ietf.org/rfcdiff?url1=draft-ietf-ace-oauth-authz-43&url2=draft-ietf-ace-oauth-authz-46
(Note: This includes noise such as changes to the characters in bulleted lists.) (Note: This includes noise such as changes to the characters in bulleted lists.)
--> -->
<!-- xml2rfc v2v3 conversion 3.9.1 --> <!-- xml2rfc v2v3 conversion 3.9.1 -->
<!-- ***** FRONT MATTER ***** -->
<front> <front>
<title abbrev="ACE-OAuth">Authentication and Authorization for Constrained Environments (ACE) Using the OAuth 2.0 Framework (ACE-OAuth)</title> <title abbrev="ACE-OAuth">Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)</title>
<!--[rfced] Regarding the title, is "(ACE)" necessary? It seems redundant with
"(ACE-OAuth)" later.
Current:
Authentication and Authorization for Constrained Environments (ACE)
Using the OAuth 2.0 Framework (ACE-OAuth)
Perhaps:
Authentication and Authorization for Constrained Environments
Using the OAuth 2.0 Framework (ACE-OAuth)
<seriesInfo name="RFC" value="9200"/> <seriesInfo name="RFC" value="9200"/>
<author fullname="Ludwig Seitz" initials="L." surname="Seitz"> <author fullname="Ludwig Seitz" initials="L." surname="Seitz">
<organization>Combitech</organization> <organization>Combitech</organization>
<address> <address>
<postal> <postal>
<street>Djäknegatan 31</street> <street>Djäknegatan 31</street>
<code>211 35</code> <code>211 35</code>
<city>Malmö</city> <city>Malmö</city>
<country>Sweden</country> <country>Sweden</country>
skipping to change at line 68 skipping to change at line 53
<postal> <postal>
<street>Faroegatan 6</street> <street>Faroegatan 6</street>
<code>164 80</code> <code>164 80</code>
<city>Kista</city> <city>Kista</city>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>goran.selander@ericsson.com</email> <email>goran.selander@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="Erik Wahlstroem" initials="E." surname="Wahlstroem"> <author fullname="Erik Wahlstroem" initials="E." surname="Wahlstroem">
<!--[rfced] Erik, would you like your surname to appear
as Wahlström or Wahlstroem in the RFC?
<organization/> <organization/>
<address> <address>
<postal> <postal>
<street/> <street/>
<code/> <code/>
<city/> <city/>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>erik@wahlstromstekniska.se</email> <email>erik@wahlstromstekniska.se</email>
</address> </address>
skipping to change at line 129 skipping to change at line 111
The framework is based on a set of building blocks including OAuth 2.0 The framework is based on a set of building blocks including OAuth 2.0
and the Constrained Application Protocol (CoAP), thus transforming a and the Constrained Application Protocol (CoAP), thus transforming a
well-known and widely used authorization solution into a form suitable well-known and widely used authorization solution into a form suitable
for IoT devices. Existing specifications are used where possible, but for IoT devices. Existing specifications are used where possible, but
extensions are added and profiles are defined to better serve the IoT use extensions are added and profiles are defined to better serve the IoT use
cases. cases.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<!-- ***************************************************** -->
<section anchor="intro" numbered="true" toc="default"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>Authorization is the process for granting approval to an entity to <t>Authorization is the process for granting approval to an entity to
access a generic resource <xref target="RFC4949" format="default"/>. The authorization access a generic resource <xref target="RFC4949" format="default"/>. The authorization
task itself can best be described as granting access to a requesting client for task itself can best be described as granting access to a requesting client for
a resource hosted on a device, i.e., the resource server (RS). This exchange is a resource hosted on a device, i.e., the resource server (RS). This exchange is
mediated by one or multiple authorization servers (ASes). Managing mediated by one or multiple authorization servers (ASes). Managing
authorization for a large number of devices and users can be a complex task. authorization for a large number of devices and users can be a complex task.
</t> </t>
skipping to change at line 177 skipping to change at line 158
Implementations may claim conformance with a specific profile, whereby Implementations may claim conformance with a specific profile, whereby
implementations utilizing the same profile interoperate, while implementations utilizing the same profile interoperate, while
implementations of different profiles are not expected to be interoperable. implementations of different profiles are not expected to be interoperable.
More powerful devices, such as mobile phones and tablets, may implement multiple More powerful devices, such as mobile phones and tablets, may implement multiple
profiles and will therefore be able to interact with a wider range of constrained devices. profiles and will therefore be able to interact with a wider range of constrained devices.
Requirements on profiles are described at contextually Requirements on profiles are described at contextually
appropriate places throughout this specification and also summarized in appropriate places throughout this specification and also summarized in
<xref target="app_profileRequirements" format="default"/>. <xref target="app_profileRequirements" format="default"/>.
</t> </t>
</section> </section>
<!-- ***************************************************** -->
<section anchor="terminology" numbered="true" toc="default"> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.</t>
<t>Certain security-related terms, such as "authentication", <t>Certain security-related terms, such as "authentication",
"authorization", "confidentiality", "(data) integrity", "message "authorization", "confidentiality", "(data) integrity", "message
authentication code", and "verify", are taken from <xref target="RFC4949" format="default"/>. authentication code", and "verify", are taken from <xref target="RFC4949" format="default"/>.
</t> </t>
<!--[rfced] FYI, we have added this sentence to explain "RESTful".
(Similar text appears in RFC 8613 and others.)
Original:
Since exchanges in this specification are described as RESTful
protocol interactions, HTTP [RFC7231] offers useful terminology.
Current:
Since exchanges in this specification are described as RESTful
protocol interactions, HTTP [RFC7231] offers useful terminology.
(Note that "RESTful" refers to the Representational State Transfer
(REST) architecture.)
<t>Since exchanges in this specification are described as RESTful protocol <t>Since exchanges in this specification are described as RESTful protocol
interactions, HTTP <xref target="RFC7231" format="default"/> offers useful terminology. interactions, HTTP <xref target="RFC7231" format="default"/> offers useful terminology.
(Note that "RESTful" refers to the Representational State Transfer (REST) architecture.) (Note that "RESTful" refers to the Representational State Transfer (REST) architecture.)
</t> </t>
<t>Terminology for entities in the architecture is defined in OAuth <t>Terminology for entities in the architecture is defined in OAuth
2.0 <xref target="RFC6749" format="default"/>, such as client (C), resource server (RS), 2.0 <xref target="RFC6749" format="default"/>, such as client (C), resource server (RS),
and authorization server (AS).</t> and authorization server (AS).</t>
<t>Note that the term "endpoint" is used here following its OAuth <t>Note that the term "endpoint" is used here following its OAuth
definition, which is to denote resources, such as token and definition, which is to denote resources, such as token and
introspection at the AS and authz-info at the RS (see <xref target="tokenAuthInfoEndpoint" format="default"/> for a definition of the authz-info endpoint). introspection at the AS and authz-info at the RS (see <xref target="tokenAuthInfoEndpoint" format="default"/> for a definition of the authz-info endpoint).
skipping to change at line 223 skipping to change at line 190
<t>The specification in this document is called the "framework" or "ACE framework". <t>The specification in this document is called the "framework" or "ACE framework".
When referring to "profiles of this framework", it refers to additional specifications that When referring to "profiles of this framework", it refers to additional specifications that
define the use of this specification with concrete transport and communication define the use of this specification with concrete transport and communication
security protocols (e.g., CoAP over DTLS). security protocols (e.g., CoAP over DTLS).
</t> </t>
<t>The term "Access Information" is used for parameters, other than the access token, provided to the client by the AS to enable it to access the RS <t>The term "Access Information" is used for parameters, other than the access token, provided to the client by the AS to enable it to access the RS
(e.g., public key of the RS or profile supported by RS).</t> (e.g., public key of the RS or profile supported by RS).</t>
<t>The term "authorization information" is used to denote all information, <t>The term "authorization information" is used to denote all information,
including the claims of relevant access tokens, that an RS uses to determine whether an access request should be granted.</t> including the claims of relevant access tokens, that an RS uses to determine whether an access request should be granted.</t>
</section> </section>
<!-- ***************************************************** -->
<section anchor="overview" numbered="true" toc="default"> <section anchor="overview" numbered="true" toc="default">
<name>Overview</name> <name>Overview</name>
<t>This specification defines the ACE framework for authorization in the Internet <t>This specification defines the ACE framework for authorization in the Internet
of Things environment. It consists of a set of building blocks.</t> of Things environment. It consists of a set of building blocks.</t>
<t> <t>
The basic block is the OAuth 2.0 <xref target="RFC6749" format="default"/> The basic block is the OAuth 2.0 <xref target="RFC6749" format="default"/>
framework, which enjoys widespread deployment. Many IoT devices can support framework, which enjoys widespread deployment. Many IoT devices can support
OAuth 2.0 without any additional extensions, but for certain constrained OAuth 2.0 without any additional extensions, but for certain constrained
settings, additional profiling is needed. settings, additional profiling is needed.
skipping to change at line 395 skipping to change at line 361
<t> The token is either a simple reference <t> The token is either a simple reference
or a structured information object (e.g., CWT <xref target="RFC8392" format="default"/>) or a structured information object (e.g., CWT <xref target="RFC8392" format="default"/>)
protected by a cryptographic wrapper (e.g., COSE <xref target="RFC8152" format="default"/>). The choice of PoP key does not necessarily imply protected by a cryptographic wrapper (e.g., COSE <xref target="RFC8152" format="default"/>). The choice of PoP key does not necessarily imply
a specific credential type for the integrity protection of the a specific credential type for the integrity protection of the
token.</t> token.</t>
</dd> </dd>
<dt>Scopes and Permissions:</dt> <dt>Scopes and Permissions:</dt>
<dd> <dd>
<t> <t>
In OAuth 2.0, the client specifies the type of permissions it is In OAuth 2.0, the client specifies the type of permissions it is
seeking to obtain (via the scope parameter) in the access token seeking to obtain (via the <tt>scope</tt> parameter) in the access token
request. In turn, the AS may use the scope response parameter to request. In turn, the AS may use the <tt>scope</tt> response parameter to
inform the client of the scope of the access token issued. As the inform the client of the scope of the access token issued. As the
client could be a constrained device as well, this specification client could be a constrained device as well, this specification
defines the use of CBOR encoding (see <xref target="oauthProfile" format="default"/>) for such requests and responses. defines the use of CBOR encoding (see <xref target="oauthProfile" format="default"/>) for such requests and responses.
</t> </t>
<t> <t>
The values of the scope parameter in OAuth 2.0 are expressed as a list The values of the <tt>scope</tt> parameter in OAuth 2.0 are expressed as a list
of space-delimited, case-sensitive strings with a semantic that is of space-delimited, case-sensitive strings with a semantic that is
well known to the AS and the RS. well known to the AS and the RS.
<!--[rfced] We see a number of author-inserted comments in the XML
file for this document. We are unsure if these have been resolved.
Please review and let us know if these can be deleted or if they
need to be addressed.-->
<!-- <vspace blankLines="1"/>
A common misconception is that the requested scopes must
also be included in the returned access token, but the requested scopes
are only metadata about the token. They could also be packaged in the
token as a separate attribute, but it's more common to assert the
requested and authorized access using claims within the access token.
<vspace blankLines="1"/>-->
More details about the concept of scopes are found under More details about the concept of scopes are found under
<xref target="RFC6749" sectionFormat="of" section="3.3"/>.</t> <xref target="RFC6749" sectionFormat="of" section="3.3"/>.</t>
</dd> </dd>
<dt>Claims:</dt> <dt>Claims:</dt>
<dd> <dd>
<t> <t>
Information carried in the access token or returned from introspection, called claims, is in the form of Information carried in the access token or returned from introspection, called claims, is in the form of
name-value pairs. An access token may, for example, include a claim name-value pairs. An access token may, for example, include a claim
identifying the AS that issued the token (via the "iss" claim) and identifying the AS that issued the token (via the <tt>iss</tt> claim) and
what audience the access token is intended for (via the "aud" claim). what audience the access token is intended for (via the <tt>aud</tt> claim).
The audience of an access token can be a specific resource, one resource, or The audience of an access token can be a specific resource, one resource, or
many resource servers. The resource owner policies influence what many resource servers. The resource owner policies influence what
claims are put into the access token by the authorization server. claims are put into the access token by the authorization server.
</t> </t>
<t> <t>
While the structure and encoding of the access token varies throughout While the structure and encoding of the access token varies throughout
deployments, a standardized format has been defined with the JSON Web deployments, a standardized format has been defined with the JSON Web
Token (JWT) <xref target="RFC7519" format="default"/>, where claims are encoded as a Token (JWT) <xref target="RFC7519" format="default"/>, where claims are encoded as a
JSON object. In <xref target="RFC8392" format="default"/>, the CBOR Web Token (CWT) JSON object. In <xref target="RFC8392" format="default"/>, the CBOR Web Token (CWT)
has been defined as an equivalent format using CBOR encoding. has been defined as an equivalent format using CBOR encoding.
skipping to change at line 499 skipping to change at line 454
<t>In this framework, the use of CoAP as replacement for HTTP is <bcp14>RECOMMENDED</bcp14> <t>In this framework, the use of CoAP as replacement for HTTP is <bcp14>RECOMMENDED</bcp14>
for use in constrained environments. For communication security, this for use in constrained environments. For communication security, this
framework does not make an explicit protocol recommendation, since the choice framework does not make an explicit protocol recommendation, since the choice
depends on the requirements of the specific application. DTLS depends on the requirements of the specific application. DTLS
<xref target="RFC6347" format="default"/> <xref target="RFC9147" format="default"/> and OSCORE <xref target="RFC6347" format="default"/> <xref target="RFC9147" format="default"/> and OSCORE
<xref target="RFC8613" format="default"/> are mentioned as examples; other protocols fulfilling <xref target="RFC8613" format="default"/> are mentioned as examples; other protocols fulfilling
the requirements from <xref target="minimalCommSecReq" format="default"/> are also the requirements from <xref target="minimalCommSecReq" format="default"/> are also
applicable.</t> applicable.</t>
</section> </section>
</section> </section>
<!-- ***************************************************** -->
<section anchor="specs" numbered="true" toc="default"> <section anchor="specs" numbered="true" toc="default">
<name>Protocol Interactions</name> <name>Protocol Interactions</name>
<t> <t>
The ACE framework is based on the OAuth 2.0 protocol interactions using The ACE framework is based on the OAuth 2.0 protocol interactions using
the token endpoint and optionally the introspection endpoint. the token endpoint and optionally the introspection endpoint.
A client obtains an access token, and optionally a refresh token, from an A client obtains an access token, and optionally a refresh token, from an
AS using the token endpoint and subsequently presents the access token to AS using the token endpoint and subsequently presents the access token to
an RS to gain access to a protected resource. In most deployments, the RS can an RS to gain access to a protected resource. In most deployments, the RS can
process the access token locally; however, in some cases, the RS may present process the access token locally; however, in some cases, the RS may present
it to the AS via the introspection endpoint to get fresh information. it to the AS via the introspection endpoint to get fresh information.
skipping to change at line 626 skipping to change at line 581
the communication security protocol used. the communication security protocol used.
</dd> </dd>
</dl> </dl>
<t>The OAuth 2.0 framework defines a number of "protocol flows" via grant types, <t>The OAuth 2.0 framework defines a number of "protocol flows" via grant types,
which have been extended which have been extended
further with extensions to OAuth 2.0 (such as <xref target="RFC7521" further with extensions to OAuth 2.0 (such as <xref target="RFC7521"
format="default"/> and <xref target="RFC8628" format="default"/>). format="default"/> and <xref target="RFC8628" format="default"/>).
What grant type works best depends on the usage scenario; <xref What grant type works best depends on the usage scenario; <xref
target="RFC7744" format="default"/> describes many different IoT use cases, but target="RFC7744" format="default"/> describes many different IoT use cases, but
there are two grant types that cover a majority of these scenarios, namely the there are two grant types that cover a majority of these scenarios, namely the
authorization code grant (described in <xref target="RFC7521" format="default" authorization code grant (described in <xref target="RFC6749" format="default"
sectionFormat="of" section="4.1"/>) and sectionFormat="of" section="4.1"/>) and the client credentials grant (described
<!--[rfced] Citations
a) Note that as RFC 7521 does not have a Section 4.4, we
have updated this citation to be Section 4.4 of RFC 6749. Please
let us know if this is not correct.
Original:
and the Client Credentials
Grant (described in Section 4.4 of [RFC7521]).
Current:
and the client credentials
grant (described in Section 4.4 of [RFC6749]).
b) We note that RFC 8392 does not contain a Section 5.1.
How should this citation be updated?
Original:
Additional protection for the access token can be applied by
encrypting it, for example encryption of CWTs is specified in
Section 5.1 of [RFC8392].
the client credentials grant (described
in <xref target="RFC6749" sectionFormat="of" section="4.4"/>). The authorization in <xref target="RFC6749" sectionFormat="of" section="4.4"/>). The authorization
code grant is a good fit for use with apps running on smartphones and tablets that request access to IoT devices, a common scenario in the smart home environment, where users need to go through an authentication and authorization phase (at least during the initial setup phase). The native apps guidelines described in <xref target="RFC8252" format="default"/> are applicable to this use case. The client credentials grant is a good fit for use with IoT devices where the OAuth client itself is constrained. In such a case, the resource owner has prearranged access rights for the client with the authorization server, which is often accomplished using a commissioning tool.</t> code grant is a good fit for use with apps running on smartphones and tablets that
request access to IoT devices, a common scenario in the smart home environment,
where users need to go through an authentication and authorization phase (at least
during the initial setup phase). The native apps guidelines described in <xref
target="RFC8252" format="default"/> are applicable to this use case. The client
credentials grant is a good fit for use with IoT devices where the OAuth client
itself is constrained. In such a case, the resource owner has prearranged access
rights for the client with the authorization server, which is often accomplished
using a commissioning tool.</t>
<t> <t>
The consent of the resource owner, for giving a client access to a protected The consent of the resource owner, for giving a client access to a protected
resource, can be provided dynamically as in the traditional OAuth flows, or it resource, can be provided dynamically as in the classical OAuth flows, or it
could be preconfigured by the resource owner as authorization policies at could be preconfigured by the resource owner as authorization policies at
the AS, which the AS evaluates when a token request arrives. The resource the AS, which the AS evaluates when a token request arrives. The resource
owner and the requesting party (i.e., client owner) are not shown in <xref target="fig_protocolFlow" format="default"/>. owner and the requesting party (i.e., client owner) are not shown in <xref target="fig_protocolFlow" format="default"/>.
</t> </t>
<t> <t>
This framework supports a wide variety of communication security mechanisms This framework supports a wide variety of communication security mechanisms
between the ACE entities, such as the client, between the ACE entities, such as the client,
AS, and RS. It is assumed that the client has been AS, and RS. It is assumed that the client has been
registered (also called enrolled or onboarded) to an AS using a mechanism defined registered (also called enrolled or onboarded) to an AS using a mechanism defined
outside the scope of this document. outside the scope of this document.
skipping to change at line 696 skipping to change at line 634
In this step, the client might also determine what permissions are needed to In this step, the client might also determine what permissions are needed to
access the protected resource. A generic procedure is described in <xref target="asDiscovery" format="default"/>; profiles <bcp14>MAY</bcp14> define other procedures for access the protected resource. A generic procedure is described in <xref target="asDiscovery" format="default"/>; profiles <bcp14>MAY</bcp14> define other procedures for
discovery.</t> discovery.</t>
<t>In Bluetooth Low Energy, for example, advertisements are broadcast by <t>In Bluetooth Low Energy, for example, advertisements are broadcast by
a peripheral, including information about the primary services. In CoAP, a peripheral, including information about the primary services. In CoAP,
as a second example, a client can make a request to "/.well-known/core" to as a second example, a client can make a request to "/.well-known/core" to
obtain information about available resources, which are returned in a obtain information about available resources, which are returned in a
standardized format, as described in <xref target="RFC6690" format="default"/>. standardized format, as described in <xref target="RFC6690" format="default"/>.
</t> </t>
</section> </section>
<!-- ***************************************************** -->
<section anchor="oauthProfile" numbered="true" toc="default"> <section anchor="oauthProfile" numbered="true" toc="default">
<name>Framework</name> <name>Framework</name>
<t>The following sections detail the profiling and extensions of OAuth 2.0 <t>The following sections detail the profiling and extensions of OAuth 2.0
for constrained environments, which constitutes the ACE framework. for constrained environments, which constitutes the ACE framework.
</t> </t>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>Credential Provisioning</dt> <dt>Credential Provisioning</dt>
<dd> <dd>
<t> <t>
skipping to change at line 720 skipping to change at line 657
between the client and the RS. The resulting security association between the client between the client and the RS. The resulting security association between the client
and the RS may then also be used to bind these credentials to the and the RS may then also be used to bind these credentials to the
access tokens the client uses. access tokens the client uses.
</t> </t>
</dd> </dd>
<dt>Proof of Possession</dt> <dt>Proof of Possession</dt>
<dd> <dd>
<t> <t>
The ACE framework, by default, implements proof of possession for The ACE framework, by default, implements proof of possession for
access tokens, i.e., that the token holder can prove being a holder of access tokens, i.e., that the token holder can prove being a holder of
the key bound to the token. The binding is provided by the "cnf" (confirmation) the key bound to the token. The binding is provided by the <tt>cnf</tt>
claim (confirmation) claim
<xref target="RFC8747" format="default"/>, indicating what key is used for <xref target="RFC8747" format="default"/>, indicating what key is used for
proof of possession. If a client needs to submit a new access token, proof of possession. If a client needs to submit a new access token,
e.g., to obtain additional access rights, they can request e.g., to obtain additional access rights, they can request
that the AS binds this token to the same key as the previous one. that the AS binds this token to the same key as the previous one.
</t> </t>
</dd> </dd>
<dt>ACE Profiles</dt> <dt>ACE Profiles</dt>
<dd> <dd>
The client or RS may be limited in the encodings or protocols it The client or RS may be limited in the encodings or protocols it
supports. To support a variety of different deployment settings, supports. To support a variety of different deployment settings,
specific interactions between the client and RS are defined in an ACE specific interactions between the client and RS are defined in an ACE
profile. In the ACE framework, the AS is expected to manage the matching profile. In the ACE framework, the AS is expected to manage the matching
of compatible profile choices between a client and an RS. The AS of compatible profile choices between a client and an RS. The AS
informs the client of the selected profile using the "ace_profile" informs the client of the selected profile using the <tt>ace_profile</tt>
parameter in the token response. parameter in the token response.
</dd> </dd>
</dl> </dl>
<t>OAuth 2.0 requires the use of TLS to protect the communication <t>OAuth 2.0 requires the use of TLS to protect the communication
between the AS and client when requesting an access token between the client and RS between the AS and client when requesting an access token between the client and RS
when accessing a resource and between the AS and RS if introspection is used. when accessing a resource and between the AS and RS if introspection is used.
In constrained settings, TLS is not always feasible or desirable. In constrained settings, TLS is not always feasible or desirable.
Nevertheless, it is <bcp14>REQUIRED</bcp14> that the communications named above are Nevertheless, it is <bcp14>REQUIRED</bcp14> that the communications named above are
encrypted, integrity protected, and protected against message replay. It is encrypted, integrity protected, and protected against message replay. It is
also <bcp14>REQUIRED</bcp14> that the communicating endpoints perform mutual authentication. also <bcp14>REQUIRED</bcp14> that the communicating endpoints perform mutual authentication.
skipping to change at line 782 skipping to change at line 719
<t>Profiles that use CBOR encoding of protocol message parameters at the <t>Profiles that use CBOR encoding of protocol message parameters at the
outermost encoding layer <bcp14>MUST</bcp14> use the Content-Format "application/ace+cbor". outermost encoding layer <bcp14>MUST</bcp14> use the Content-Format "application/ace+cbor".
If CoAP is used for communication, the Content-Format <bcp14>MUST</bcp14> be abbreviated If CoAP is used for communication, the Content-Format <bcp14>MUST</bcp14> be abbreviated
with the ID: 19 (see <xref target="IANAcoapContentFormat" format="default"/>).</t> with the ID: 19 (see <xref target="IANAcoapContentFormat" format="default"/>).</t>
<t>The OAuth 2.0 AS uses a JSON structure in the payload of its responses <t>The OAuth 2.0 AS uses a JSON structure in the payload of its responses
both to the client and RS. If CoAP is used, it is <bcp14>REQUIRED</bcp14> to use both to the client and RS. If CoAP is used, it is <bcp14>REQUIRED</bcp14> to use
CBOR <xref target="RFC8949" format="default"/> instead of JSON. Depending on the profile, CBOR <xref target="RFC8949" format="default"/> instead of JSON. Depending on the profile,
the CBOR payload <bcp14>MAY</bcp14> be enclosed in a non-CBOR cryptographic wrapper.</t> the CBOR payload <bcp14>MAY</bcp14> be enclosed in a non-CBOR cryptographic wrapper.</t>
<section anchor="asDiscovery" numbered="true" toc="default"> <section anchor="asDiscovery" numbered="true" toc="default">
<name>Discovering Authorization Servers</name> <name>Discovering Authorization Servers</name>
<!--[rfced] Throughout this document and especially in Section 5.1,
the article "the" has been added before "C" and "RS" as it appears
elsewhere in this document. Please review usage and let us know if
any further updates are needed.
<t>The C must discover the AS in charge of the RS to determine where to request the <t>The C must discover the AS in charge of the RS to determine where to request the
access token. To do so, the C 1) must find out the AS URI to which the token access token. To do so, the C 1) must find out the AS URI to which the token
request message must be sent and 2) <bcp14>MUST</bcp14> validate that the AS with this request message must be sent and 2) <bcp14>MUST</bcp14> validate that the AS with this
URI is authorized to provide access tokens for this RS. URI is authorized to provide access tokens for this RS.
</t> </t>
<t> In order to determine the AS URI, the C <bcp14>MAY</bcp14> send an initial Unauthorized <t> In order to determine the AS URI, the C <bcp14>MAY</bcp14> send an initial Unauthorized
Resource Request message to the RS. The RS then denies the request and sends Resource Request message to the RS. The RS then denies the request and sends
the address of its AS back to the C (see <xref target="rreq" format="default"/>). How the C validates the the address of its AS back to the C (see <xref target="rreq" format="default"/>). How the C validates the
AS authorization is not in scope for this document. The C may, for example, ask AS authorization is not in scope for this document. The C may, for example, ask
its owner if this AS is authorized for this RS. The C may also use a its owner if this AS is authorized for this RS. The C may also use a
mechanism that addresses both problems at once (e.g., by querying a dedicated secure service provided by the client owner) .</t> mechanism that addresses both problems at once (e.g., by querying a dedicated secure service provided by the client owner) .</t>
</section> </section>
<!--AS Discovery -->
<section anchor="rreq" numbered="true" toc="default"> <section anchor="rreq" numbered="true" toc="default">
<name>Unauthorized Resource Request Message</name> <name>Unauthorized Resource Request Message</name>
<t>An Unauthorized Resource Request message is a request for any <t>An Unauthorized Resource Request message is a request for any
resource hosted by the RS for which the client does not have authorization granted. resource hosted by the RS for which the client does not have authorization granted.
The RSs <bcp14>MUST</bcp14> The RSs <bcp14>MUST</bcp14>
treat any request for a protected resource as an Unauthorized Resource treat any request for a protected resource as an Unauthorized Resource
Request message when any of the following hold: Request message when any of the following hold:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
skipping to change at line 831 skipping to change at line 762
NOT</bcp14> be protected as specified above (cf. <xref NOT</bcp14> be protected as specified above (cf. <xref
target="tokenAuthInfoEndpoint" format="default"/>).</t> target="tokenAuthInfoEndpoint" format="default"/>).</t>
<t>Unauthorized Resource Request messages <bcp14>MUST</bcp14> be denied with an <t>Unauthorized Resource Request messages <bcp14>MUST</bcp14> be denied with an
"unauthorized_client" error response. In this response, the resource server "unauthorized_client" error response. In this response, the resource server
<bcp14>SHOULD</bcp14> provide proper <bcp14>SHOULD</bcp14> provide proper
"AS Request Creation Hints" to enable the client to request an access token "AS Request Creation Hints" to enable the client to request an access token
from the RS's AS, as described in <xref target="asInfo" format="default"/>.</t> from the RS's AS, as described in <xref target="asInfo" format="default"/>.</t>
<t>The handling of all client requests (including unauthorized ones) <t>The handling of all client requests (including unauthorized ones)
by the RS is described in <xref target="requestC2RS" format="default"/>.</t> by the RS is described in <xref target="requestC2RS" format="default"/>.</t>
</section> </section>
<!-- Unauthorized Request -->
<section anchor="asInfo" numbered="true" toc="default"> <section anchor="asInfo" numbered="true" toc="default">
<name>AS Request Creation Hints</name> <name>AS Request Creation Hints</name>
<t>The "AS Request Creation Hints" message is sent by an RS as a response to <t>The "AS Request Creation Hints" are sent by an RS as a response to
an Unauthorized Resource Request message (see <xref target="rreq" an Unauthorized Resource Request message (see <xref target="rreq"
format="default"/>) to help format="default"/>) to help
the sender of the Unauthorized Resource Request message acquire a valid the sender of the Unauthorized Resource Request message acquire a valid
access token. The "AS Request Creation Hints" message is a CBOR or JSON map, access token. The "AS Request Creation Hints" are a CBOR or JSON map,
with an <bcp14>OPTIONAL</bcp14> element "AS" specifying an absolute URI (see with an <bcp14>OPTIONAL</bcp14> element "AS" specifying an absolute URI (see
<xref target="RFC3986" sectionFormat="of" section="4.3"/>) that identifies the <xref target="RFC3986" sectionFormat="of" section="4.3"/>) that identifies the
appropriate AS for the RS.</t> appropriate AS for the RS.</t>
<t>The message can also contain the following <bcp14>OPTIONAL</bcp14> <t>The message can also contain the following <bcp14>OPTIONAL</bcp14>
parameters:</t> parameters:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>An "audience" element contains an identifier the client <li>An "audience" element contains an identifier the client
should request at the AS, as suggested by the RS. With this parameter, should request at the AS, as suggested by the RS. With this parameter,
when included in the access token request to the AS, the AS is able to when included in the access token request to the AS, the AS is able to
restrict the use of the access token to specific RSs. See restrict the use of the access token to specific RSs. See
skipping to change at line 907 skipping to change at line 837
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Note that the schema part of the AS parameter may need to be <t>Note that the schema part of the AS parameter may need to be
adapted to the security protocol that is used between the client adapted to the security protocol that is used between the client
and the AS. Thus, the example AS value "coap://as.example.com/token" and the AS. Thus, the example AS value "coap://as.example.com/token"
might need to be transformed to "coaps://as.example.com/token". might need to be transformed to "coaps://as.example.com/token".
It is assumed that the client can determine the correct schema part on It is assumed that the client can determine the correct schema part on
its own depending on the way it communicates with the AS.</t> its own depending on the way it communicates with the AS.</t>
<t><xref target="fig_as-info-payload" format="default"/> shows an example for an "AS <t><xref target="fig_as-info-payload" format="default"/> shows an example for an "AS
Request Creation Hints" message payload using CBOR <xref target="RFC8949" format="default"/> Request Creation Hints" payload using CBOR <xref target="RFC8949" format="default"/>
diagnostic notation, using the parameter names instead of the CBOR keys for diagnostic notation, using the parameter names instead of the CBOR keys for
better human readability.</t> better human readability.</t>
<!-- [rfced] Please review the "type" attribute of each sourcecode element
in the XML file to ensure correctness. If the current list of preferred
values for "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt)
does not contain an applicable type, then feel free to let us know.-->
<figure anchor="fig_as-info-payload"> <figure anchor="fig_as-info-payload">
<name>AS Request Creation Hints Payload Example</name> <name>AS Request Creation Hints Payload Example</name>
<sourcecode type="cbor-diag"><![CDATA[ <sourcecode type="cbor-diag"><![CDATA[
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'
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>In the example above, the response parameter "AS" points the receiver of <t>In the example above, the response parameter "AS" points the receiver of
this message to the URI "coaps://as.example.com/token" to request access this message to the URI "coaps://as.example.com/token" to request access
tokens. The RS sending this response uses an internal clock tokens. The RS sending this response uses an internal clock
that is not synchronized with the clock of the AS. Therefore, it that is not synchronized with the clock of the AS. Therefore, it
cannot reliably verify the expiration time of access tokens it receives. cannot reliably verify the expiration time of access tokens it receives.
Nevertheless, to ensure a certain level of access token freshness, the RS has Nevertheless, to ensure a certain level of access token freshness, the RS has
included a <tt>cnonce</tt> parameter (see <xref target="cnonceParam" format="default"/>) in the response. (The hex sequence of the cnonce parameter included a <tt>cnonce</tt> parameter (see <xref target="cnonceParam" format="default"/>) in the response. (The hex sequence of the <tt>cnonce</tt> parameter
is encoded in CBOR-based notation in this example.)</t> is encoded in CBOR-based notation in this example.)</t>
<t><xref target="fig_as-info-cbor" format="default"/> illustrates the mandatory use <t><xref target="fig_as-info-cbor" format="default"/> illustrates the mandatory use
of binary encoding of the message payload shown in of binary encoding of the message payload shown in
<xref target="fig_as-info-payload" format="default"/>.</t> <xref target="fig_as-info-payload" format="default"/>.</t>
<figure anchor="fig_as-info-cbor"> <figure anchor="fig_as-info-cbor">
<name>AS Request Creation Hints Example Encoded in CBOR</name> <name>AS Request Creation Hints Example Encoded in CBOR</name>
<sourcecode name="" type="cbor"><![CDATA[ <sourcecode name="" type="cbor"><![CDATA[
a4 # map(4) a4 # map(4)
01 # unsigned(1) (=AS) 01 # unsigned(1) (=AS)
78 1c # text(28) 78 1c # text(28)
skipping to change at line 964 skipping to change at line 890
18 27 # unsigned(39) (=cnonce) 18 27 # unsigned(39) (=cnonce)
45 # bytes(5) 45 # bytes(5)
e0a156bb3f # e0a156bb3f #
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<section anchor="cnonceParam" numbered="true" toc="default"> <section anchor="cnonceParam" numbered="true" toc="default">
<name>The Client-Nonce Parameter</name> <name>The Client-Nonce Parameter</name>
<t>If the RS does not synchronize its clock with the AS, it could be <t>If the RS does not synchronize its clock with the AS, it could be
tricked into accepting old access tokens that are either expired or have tricked into accepting old access tokens that are either expired or have
been compromised. In order to ensure some level of token freshness been compromised. In order to ensure some level of token freshness
in that case, the RS can use the "cnonce" (client-nonce) parameter. in that case, the RS can use the <tt>cnonce</tt> (client-nonce) parameter.
The processing requirements for this parameter are as follows: The processing requirements for this parameter are as follows:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>An RS sending a "cnonce" parameter in an "AS Request Creation <li>An RS sending a <tt>cnonce</tt> parameter in "AS Request Creation
Hints" message <bcp14>MUST</bcp14> store information to validate that a given Hints" <bcp14>MUST</bcp14> store information to validate that a given
cnonce is fresh. How this is implemented internally is out of scope cnonce is fresh. How this is implemented internally is out of scope
for this specification. Expiration of client-nonces should be based for this specification. Expiration of client-nonces should be based
roughly on the time it would take a client to obtain an access token roughly on the time it would take a client to obtain an access token
after receiving the "AS Request Creation Hints" message, with some after receiving the "AS Request Creation Hints", with some
allowance for unexpected delays.</li> allowance for unexpected delays.</li>
<li>A client receiving a "cnonce" parameter in an "AS Request Creation <li>A client receiving a <tt>cnonce</tt> parameter in "AS Request Creation
Hints" message <bcp14>MUST</bcp14> include this in the parameters when Hints" <bcp14>MUST</bcp14> include this in the parameters when
requesting an access token at the AS, using the "cnonce" parameter from requesting an access token at the AS, using the <tt>cnonce</tt> parameter from
<xref target="cnonceParamToken" format="default"/>.</li> <xref target="cnonceParamToken" format="default"/>.</li>
<li>If an AS grants an access token request containing a "cnonce" <li>If an AS grants an access token request containing a <tt>cnonce</tt>
parameter, it <bcp14>MUST</bcp14> include this value in the access token, using parameter, it <bcp14>MUST</bcp14> include this value in the access token, using
the "cnonce" claim specified in <xref target="accessToken" the <tt>cnonce</tt> claim specified in <xref target="accessToken"
format="default"/>.</li> format="default"/>.</li>
<li>An RS that is using the client-nonce mechanism and that receives an <li>An RS that is using the client-nonce mechanism and that receives an
access token <bcp14>MUST</bcp14> verify that this token contains a cnonce access token <bcp14>MUST</bcp14> verify that this token contains a
claim, with <tt>cnonce</tt> claim, with
a client-nonce value that is fresh according to the information stored a client-nonce value that is fresh according to the information stored
at the first step above. If the cnonce claim is not present or if the at the first step above. If the <tt>cnonce</tt> claim is not present or if
cnonce claim value is not fresh, the RS <bcp14>MUST</bcp14> discard the access the
<tt>cnonce</tt> claim value is not fresh, the RS <bcp14>MUST</bcp14> discard the access
token. If this was an interaction with the authz-info endpoint, the RS token. If this was an interaction with the authz-info endpoint, the RS
<bcp14>MUST</bcp14> also <bcp14>MUST</bcp14> also
respond with an error message using a response code equivalent to the respond with an error message using a response code equivalent to the
CoAP code 4.01 (Unauthorized).</li> CoAP code 4.01 (Unauthorized).</li>
</ul> </ul>
</section> </section>
</section> </section>
<!--AS information-->
<section anchor="authorizationGrants" numbered="true" toc="default"> <section anchor="authorizationGrants" numbered="true" toc="default">
<name>Authorization Grants</name> <name>Authorization Grants</name>
<t>To request an access token, the client obtains authorization from the <t>To request an access token, the client obtains authorization from the
resource owner or uses its client credentials as a grant. The authorization resource owner or uses its client credentials as a grant. The authorization
is expressed in the form of an authorization grant.</t> is expressed in the form of an authorization grant.</t>
<t>The OAuth framework <xref target="RFC6749" format="default"/> defines four grant types. The grant types can <t>The OAuth framework <xref target="RFC6749" format="default"/> defines four grant types. The grant types can
be split up into two groups: those granted on behalf of the resource be split up into two groups: those granted on behalf of the resource
owner (password, authorization code, implicit) and those for the client owner (password, authorization code, implicit) and those for the client
(client credentials). Further grant types have been added later, such as an assertion-based authorization grant defined in <xref target="RFC7521" format="default"/>.</t> (client credentials). Further grant types have been added later, such as an assertion-based authorization grant defined in <xref target="RFC7521" format="default"/>.</t>
skipping to change at line 1018 skipping to change at line 944
the client acts on behalf of the resource owner, the authorization code the client acts on behalf of the resource owner, the authorization code
grant is recommended. If the client acts on behalf of the resource owner grant is recommended. If the client acts on behalf of the resource owner
but does not have any display or has very limited interaction possibilities, it is but does not have any display or has very limited interaction possibilities, it is
recommended to use the device code grant defined in recommended to use the device code grant defined in
<xref target="RFC8628" format="default"/>. In cases where the client <xref target="RFC8628" format="default"/>. In cases where the client
acts autonomously, the client credentials grant is recommended.</t> acts autonomously, the client credentials grant is recommended.</t>
<t>For details on the different grant types, see <xref target="RFC6749" sectionFormat="of" section="1.3"/>. The OAuth 2.0 framework provides an extension <t>For details on the different grant types, see <xref target="RFC6749" sectionFormat="of" section="1.3"/>. The OAuth 2.0 framework provides an extension
mechanism for defining additional grant types, so profiles of this framework mechanism for defining additional grant types, so profiles of this framework
<bcp14>MAY</bcp14> define additional grant types, if needed.</t> <bcp14>MAY</bcp14> define additional grant types, if needed.</t>
</section> </section>
<!--Grants-->
<section anchor="clientCredentials" numbered="true" toc="default"> <section anchor="clientCredentials" numbered="true" toc="default">
<name>Client Credentials</name> <name>Client Credentials</name>
<t>Authentication of the client is mandatory independent of the grant type <t>Authentication of the client is mandatory independent of the grant type
when requesting an access token from the token endpoint. In the case of when requesting an access token from the token endpoint. In the case of
the client credentials grant type, the authentication and grant coincide.</t> the client credentials grant type, the authentication and grant coincide.</t>
<t>Client registration and provisioning of client credentials to the client <t>Client registration and provisioning of client credentials to the client
is out of scope for this specification.</t> is out of scope for this specification.</t>
<t>The OAuth framework defines two client credential types in <t>The OAuth framework defines two client credential types in
<xref target="RFC6749" sectionFormat="of" section="2.3.1"/>: client id and client secret. <xref target="I-D.erdtman-oauth-rpcc" format="default"/> adds raw public key and pre-shared key to the <xref target="RFC6749" sectionFormat="of" section="2.3.1"/>: client id and client secret. <xref target="I-D.erdtman-oauth-rpcc" format="default"/> adds raw public key and pre-shared key to the
client credentials types. Profiles of this framework <bcp14>MAY</bcp14> extend with client credentials types. Profiles of this framework <bcp14>MAY</bcp14> extend with
an additional client credentials type using client certificates.</t> an additional client credentials type using client certificates.</t>
</section> </section>
<!--Client Credentials-->
<section anchor="ASAuthentication" numbered="true" toc="default"> <section anchor="ASAuthentication" numbered="true" toc="default">
<name>AS Authentication</name> <name>AS Authentication</name>
<t>The client credentials grant does not, by default, authenticate the AS that the client <t>The client credentials grant does not, by default, authenticate the AS that the client
connects to. In classic OAuth, the AS is authenticated with a TLS server connects to. In classic OAuth, the AS is authenticated with a TLS server
certificate.</t> certificate.</t>
<t>Profiles of this framework <bcp14>MUST</bcp14> specify how clients authenticate the AS <t>Profiles of this framework <bcp14>MUST</bcp14> specify how clients authenticate the AS
and how communication security is implemented. By default, server side TLS and how communication security is implemented. By default, server side TLS
certificates, as defined by OAuth 2.0, are required.</t> certificates, as defined by OAuth 2.0, are required.</t>
</section> </section>
<!--AS Authentication-->
<section anchor="authorizeEndpoint" numbered="true" toc="default"> <section anchor="authorizeEndpoint" numbered="true" toc="default">
<name>The Authorization Endpoint</name> <name>The Authorization Endpoint</name>
<t>The OAuth 2.0 authorization endpoint is used to interact with the resource owner <t>The OAuth 2.0 authorization endpoint is used to interact with the resource owner
and obtain an authorization grant in certain grant flows. The primary use and obtain an authorization grant in certain grant flows. The primary use
case for the ACE-OAuth framework is for machine-to-machine interactions that do not involve case for the ACE-OAuth framework is for machine-to-machine interactions that do not involve
the resource owner in the authorization flow; therefore, this endpoint is the resource owner in the authorization flow; therefore, this endpoint is
out of scope here. Future profiles may define constrained adaptation out of scope here. Future profiles may define constrained adaptation
mechanisms for this endpoint as well. Nonconstrained clients interacting mechanisms for this endpoint as well. Nonconstrained clients interacting
with constrained resource servers can use the specification in with constrained resource servers can use the specification in
<xref target="RFC6749" sectionFormat="of" section="3.1"/> and the attack countermeasures suggested in <xref target="RFC6749" sectionFormat="of" section="3.1"/> and the attack countermeasures suggested in
<xref target="RFC6819" sectionFormat="of" section="4.2"/>.</t> <xref target="RFC6819" sectionFormat="of" section="4.2"/>.</t>
</section> </section>
<!--The 'Authorize' Endpoint-->
<section anchor="tokenEndpoint" numbered="true" toc="default"> <section anchor="tokenEndpoint" numbered="true" toc="default">
<name>The Token Endpoint</name> <name>The Token Endpoint</name>
<t>In standard OAuth 2.0, the AS provides the token endpoint for submitting <t>In standard OAuth 2.0, the AS provides the token endpoint for submitting
access token requests. This framework extends the functionality of the access token requests. This framework extends the functionality of the
token endpoint, giving the AS the possibility to help the client and RS token endpoint, giving the AS the possibility to help the client and RS
establish shared keys or exchange their public keys. Furthermore, establish shared keys or exchange their public keys. Furthermore,
this framework defines encodings using CBOR as a substitute for JSON.</t> this framework defines encodings using CBOR as a substitute for JSON.</t>
<t>The endpoint may also be exposed over HTTPS, as in classical OAuth or <t>The endpoint may also be exposed over HTTPS, as in classical OAuth or
even other transports. A profile <bcp14>MUST</bcp14> define the details of the mapping even other transports. A profile <bcp14>MUST</bcp14> define the details of the mapping
skipping to change at line 1114 skipping to change at line 1036
<section anchor="tokenRequest" numbered="true" toc="default"> <section anchor="tokenRequest" numbered="true" toc="default">
<name>Client-to-AS Request</name> <name>Client-to-AS Request</name>
<t>The client sends a POST request to the token endpoint <t>The client sends a POST request to the token endpoint
at the AS. The profile <bcp14>MUST</bcp14> specify how the communication is protected. at the AS. The profile <bcp14>MUST</bcp14> specify how the communication is protected.
The content of the request consists of the parameters specified The content of the request consists of the parameters specified
in the relevant subsection of Section <xref target="RFC6749" section="4" sectionFormat="bare"/> of the OAuth 2.0 specification in the relevant subsection of Section <xref target="RFC6749" section="4" sectionFormat="bare"/> of the OAuth 2.0 specification
<xref target="RFC6749" format="default"/>, depending on the grant type, with the following <xref target="RFC6749" format="default"/>, depending on the grant type, with the following
exceptions and additions: exceptions and additions:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The parameter "grant_type" is <bcp14>OPTIONAL</bcp14> in the context <li>The parameter <tt>grant_type</tt> is <bcp14>OPTIONAL</bcp14> in the context
of this framework (as opposed to <bcp14>REQUIRED</bcp14> in <xref of this framework (as opposed to <bcp14>REQUIRED</bcp14> in <xref
target="RFC6749" format="default"/>). If that parameter is target="RFC6749" format="default"/>). If that parameter is
missing, the default value "client_credentials" is implied.</li> missing, the default value "client_credentials" is implied.</li>
<li>The "audience" parameter from <xref target="RFC8693" <li>The <tt>audience</tt> parameter from <xref target="RFC8693"
format="default"/> is <bcp14>OPTIONAL</bcp14> to format="default"/> is <bcp14>OPTIONAL</bcp14> to
request an access token bound to a specific audience.</li> request an access token bound to a specific audience.</li>
<li>The "cnonce" parameter defined in <xref target="cnonceParamToken" <li>The <tt>cnonce</tt> parameter defined in <xref target="cnonceParamToken"
format="default"/> is format="default"/> is
<bcp14>REQUIRED</bcp14> if the RS provided a client-nonce in the "AS <bcp14>REQUIRED</bcp14> if the RS provided a client-nonce in the "AS
Request Creation Request Creation
Hints" message (<xref target="asInfo" format="default"/>).</li> Hints" (<xref target="asInfo" format="default"/>).</li>
<li>The "scope" parameter <bcp14>MAY</bcp14> be encoded as a byte string <li>The <tt>scope</tt> parameter <bcp14>MAY</bcp14> be encoded as a byte string
instead of instead of
the string encoding specified in <xref target="RFC6749" sectionFormat="of" the string encoding specified in <xref target="RFC6749" sectionFormat="of"
section="3.3"/> or section="3.3"/> or
in order to allow compact encoding of complex scopes. The syntax of in order to 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. Note specifically that a binary encoded to profiles or applications. Note specifically that a binary encoded
scope does not necessarily use the space character '0x20' to delimit scope does not necessarily use the space character '0x20' to delimit
scope-tokens.</li> scope-tokens.</li>
<li>The client can send an empty (null value) "ace_profile" parameter to <li>The client can send an empty (null value) <tt>ace_profile</tt> parameter to
indicate that it wants the AS to include the "ace_profile" parameter in indicate that it wants the AS to include the <tt>ace_profile</tt> parameter in
the response. See <xref target="paramProfile" format="default"/>.</li> the response. See <xref target="paramProfile" format="default"/>.</li>
<li>A client <bcp14>MUST</bcp14> be able to use the parameters from <xref target="RFC9201" format="default"/> in an access token request to the <li>A client <bcp14>MUST</bcp14> be able to use the parameters from <xref target="RFC9201" format="default"/> in an access token request to the
token endpoint, and the AS <bcp14>MUST</bcp14> be able to process these additional token endpoint, and the AS <bcp14>MUST</bcp14> be able to process these additional
parameters.</li> parameters.</li>
</ul> </ul>
<t>The default behavior is that the AS generates a symmetric <t>The default behavior is that the AS generates a symmetric
proof-of-possession key for the client. In order to use an asymmetric key proof-of-possession key for the client. In order to use an asymmetric key
pair or to reuse a key previously established with the RS, the client is pair or to reuse a key previously established with the RS, the client is
supposed to use the "req_cnf" parameter from <xref target="RFC9201" format="default"/>. supposed to use the <tt>req_cnf</tt> parameter from <xref target="RFC9201" format="default"/>.
</t> </t>
<t>If CoAP is used, then these parameters <bcp14>MUST</bcp14> be provided in a CBOR map <t>If CoAP is used, then these parameters <bcp14>MUST</bcp14> be provided in a CBOR map
(see <xref target="table_cborTokenParameters" format="default"/>).</t> (see <xref target="table_cborTokenParameters" format="default"/>).</t>
<t>When HTTP is used as a transport, then the client makes a <t>When HTTP is used as a transport, then the client makes a
request to the token endpoint; the parameters <bcp14>MUST</bcp14> be encoded as defined request to the token endpoint; the parameters <bcp14>MUST</bcp14> be encoded as defined
in <xref target="RFC6749" sectionFormat="of" section="B"/>.</t> in <xref target="RFC6749" sectionFormat="of" section="B"/>.</t>
<t>The following examples illustrate different types of requests <t>The following examples illustrate different types of requests
for proof-of-possession tokens. </t> for proof-of-possession tokens. </t>
<t><xref target="fig_symmATreq" format="default"/> shows a request for a token <t><xref target="fig_symmATreq" format="default"/> shows a request for a token
with a symmetric proof-of-possession key. The content is displayed in with a symmetric proof-of-possession key. The content is displayed in
skipping to change at line 1181 skipping to change at line 1103
</figure> </figure>
<t><xref target="fig_asymmATreq" format="default"/> shows a request for a token <t><xref target="fig_asymmATreq" format="default"/> shows a request for a token
with an with an
asymmetric proof-of-possession key. Note that, in this example, OSCORE asymmetric proof-of-possession key. Note that, in this example, OSCORE
<xref target="RFC8613" format="default"/> is used <xref target="RFC8613" format="default"/> is used
to provide object-security; therefore, the Content-Format is to provide object-security; therefore, the Content-Format is
"application/oscore" wrapping the "application/ace+cbor" type content. "application/oscore" wrapping the "application/ace+cbor" type content.
The OSCORE option has a decoded interpretation appended in parentheses The OSCORE option has a decoded interpretation appended in parentheses
for the reader's convenience. Also note that, in this example, the audience for the reader's convenience. Also note that, in this example, the audience
is implicitly known by both the client and AS. Furthermore, note that this is implicitly known by both the client and AS. Furthermore, note that this
example uses the "req_cnf" parameter from <xref target="RFC9201" example uses the <tt>req_cnf</tt> parameter from <xref target="RFC9201"
format="default"/>. format="default"/>.
</t> </t>
<figure anchor="fig_asymmATreq"> <figure anchor="fig_asymmATreq">
<name>Example Token Request Bound to an Asymmetric Key</name> <name>Example Token Request Bound to an Asymmetric Key</name>
<sourcecode name="" type="cbor-diag"><![CDATA[ <sourcecode name="" type="cbor-diag"><![CDATA[
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"
OSCORE: 0x09, 0x05, 0x44, 0x6C OSCORE: 0x09, 0x05, 0x44, 0x6C
(h=0, k=1, n=001, partialIV= 0x05, kid=[0x44, 0x6C]) (h=0, k=1, n=001, partialIV= 0x05, kid=[0x44, 0x6C])
skipping to change at line 1213 skipping to change at line 1135
"crv" : "P-256", "crv" : "P-256",
"x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8', "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
"y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4' "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t><xref target="fig_kidATreq" format="default"/> shows a request for a token <t><xref target="fig_kidATreq" format="default"/> shows a request for a token
where a previously communicated proof-of-possession key is only where a previously communicated proof-of-possession key is only
referenced using the "req_cnf" parameter from referenced using the <tt>req_cnf</tt> parameter from
<xref target="RFC9201" format="default"/>. <xref target="RFC9201" format="default"/>.
</t> </t>
<figure anchor="fig_kidATreq"> <figure anchor="fig_kidATreq">
<name>Example Request for an Access Token Bound to a Key Reference</name> <name>Example Request for an Access Token Bound to a Key Reference</name>
<sourcecode name="" type="cbor-diag"><![CDATA[ <sourcecode name="" type="cbor-diag"><![CDATA[
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"
skipping to change at line 1259 skipping to change at line 1181
request was invalid, or not authorized, the AS returns an error response, as request was invalid, or not authorized, the AS returns an error response, as
described in <xref target="errorsToken" format="default"/>.</t> described in <xref target="errorsToken" format="default"/>.</t>
<t>Note that the AS decides which token type and profile to use when <t>Note that the AS decides which token type and profile to use when
issuing a successful response. It is assumed that the AS has prior issuing a successful response. It is assumed that the AS has prior
knowledge of the capabilities of the client and the RS (see <xref knowledge of the capabilities of the client and the RS (see <xref
target="app_registration" format="default"/>). This prior knowledge may, target="app_registration" format="default"/>). This prior knowledge may,
for example, be set for example, be set
by the use of a dynamic client registration protocol exchange by the use of a dynamic client registration protocol exchange
<xref target="RFC7591" format="default"/>. If the client has requested a <xref target="RFC7591" format="default"/>. If the client has requested a
specific specific
proof-of-possession key using the "req_cnf" parameter from proof-of-possession key using the <tt>req_cnf</tt> parameter from
<xref target="RFC9201" format="default"/>, this may also influence which <xref target="RFC9201" format="default"/>, this may also influence which
profile the AS selects, as it needs to support the use of the key type profile the AS selects, as it needs to support the use of the key type
requested by the client.</t> requested by the client.</t>
<t>The content of the successful reply is the Access Information. <t>The content of the successful reply is the Access Information.
When using CoAP, the payload <bcp14>MUST</bcp14> be encoded as a CBOR map; When using CoAP, the payload <bcp14>MUST</bcp14> be encoded as a CBOR map;
when using when using
HTTP, the encoding is a JSON map, as specified in <xref target="RFC6749" HTTP, the encoding is a JSON map, as specified in <xref target="RFC6749"
sectionFormat="of" section="5.1"/>. In both cases, the parameters specified sectionFormat="of" section="5.1"/>. In both cases, the parameters specified
in <xref target="RFC6749" sectionFormat="of" section="5.1"/> are used, with in <xref target="RFC6749" sectionFormat="of" section="5.1"/> are used, with
the following additions and changes:</t> the following additions and changes:</t>
<dl newline="true" spacing="normal" indent="6"> <dl newline="true" spacing="normal" indent="6">
<dt>ace_profile:</dt> <dt>ace_profile:</dt>
<dd>This parameter is <bcp14>OPTIONAL</bcp14> unless the request included an <dd>This parameter is <bcp14>OPTIONAL</bcp14> unless the request included an
empty ace_profile parameter, empty <tt>ace_profile</tt> parameter,
in which case it is MANDATORY. This indicates the profile that the in which case it is MANDATORY. This indicates the profile that the
client <bcp14>MUST</bcp14> use towards the RS. See <xref client <bcp14>MUST</bcp14> use towards the RS. See <xref
target="paramProfile" format="default"/> for target="paramProfile" format="default"/> for
the formatting of this parameter. If this parameter is absent, the AS the formatting of this parameter. If this parameter is absent, the AS
assumes that the client implicitly knows which profile to use towards assumes that the client implicitly knows which profile to use towards
the RS.</dd> the RS.</dd>
<!--[rfced] We changed 'required' to REQUIRED because it seems to
be a direct mention of what appeared in RFC 6749. If this is not accurate,
please let us know.
Original:
token_type:
This parameter is OPTIONAL, as opposed to 'required' in
[RFC6749].
Current:
token_type:
This parameter is OPTIONAL, as opposed to REQUIRED in
[RFC6749].
<dt>token_type:</dt> <dt>token_type:</dt>
<dd>This parameter is <bcp14>OPTIONAL</bcp14>, as opposed to <dd>This parameter is <bcp14>OPTIONAL</bcp14>, as opposed to
<bcp14>REQUIRED</bcp14> in <bcp14>REQUIRED</bcp14> in
<xref target="RFC6749" format="default"/>. By default, implementations of <xref target="RFC6749" format="default"/>. By default, implementations of
this framework this framework
<bcp14>SHOULD</bcp14> assume that the token_type is "PoP". If a specific <bcp14>SHOULD</bcp14> assume that the token_type is "PoP". If a specific
use case use case
requires another token_type (e.g., "Bearer") to be used, then this requires another token_type (e.g., "Bearer") to be used, then this
parameter is <bcp14>REQUIRED</bcp14>. parameter is <bcp14>REQUIRED</bcp14>.
</dd> </dd>
skipping to change at line 1371 skipping to change at line 1279
<td>cnf</td> <td>cnf</td>
<td><xref target="RFC9201" format="default"/></td> <td><xref target="RFC9201" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td>rs_cnf</td> <td>rs_cnf</td>
<td><xref target="RFC9201" format="default"/></td> <td><xref target="RFC9201" format="default"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t><xref target="fig_symmATres" format="default"/> shows a response containing a token <t><xref target="fig_symmATres" format="default"/> shows a response containing a token
and a "cnf" parameter with a symmetric proof-of-possession key, which and a <tt>cnf</tt> parameter with a symmetric proof-of-possession key, which
is defined in <xref target="RFC9201" format="default"/>. Note that is defined in <xref target="RFC9201" format="default"/>. Note that
the key identifier 'kid' is only used to simplify indexing and the key identifier 'kid' is only used to simplify indexing and
retrieving the key, and no assumptions should be made that it is retrieving the key, and no assumptions should be made that it is
unique in the domains of either the client or the RS. unique in the domains of either the client or the RS.
</t> </t>
<figure anchor="fig_symmATres"> <figure anchor="fig_symmATres">
<name>Example AS Response with an Access Token Bound to a Symmetric Key</name> <name>Example AS Response with an Access Token Bound to a Symmetric Key</name>
<sourcecode name="" type="cbor-diag"><![CDATA[ <sourcecode name="" type="cbor-diag"><![CDATA[
Header: Created (Code=2.01) Header: Created (Code=2.01)
skipping to change at line 1421 skipping to change at line 1329
the Content-Format "application/ace+cbor". When using HTTP, the the Content-Format "application/ace+cbor". When using HTTP, the
payload is encoded in JSON, as specified in <xref target="RFC6749" payload is encoded in JSON, as specified in <xref target="RFC6749"
sectionFormat="of" section="5.2"/>.</li> sectionFormat="of" section="5.2"/>.</li>
<li>A response code equivalent to the CoAP code 4.00 (Bad Request) <li>A response code equivalent to the CoAP code 4.00 (Bad Request)
<bcp14>MUST</bcp14> <bcp14>MUST</bcp14>
be used for all error responses, except for invalid_client, where a be used for all error responses, except for invalid_client, where a
response code equivalent to the CoAP code 4.01 (Unauthorized) response code equivalent to the CoAP code 4.01 (Unauthorized)
<bcp14>MAY</bcp14> be <bcp14>MAY</bcp14> be
used under the same conditions as specified in used under the same conditions as specified in
<xref target="RFC6749" sectionFormat="of" section="5.2"/>.</li> <xref target="RFC6749" sectionFormat="of" section="5.2"/>.</li>
<li>The parameters "error", "error_description", and "error_uri" <bcp14>MUST</bcp14> <li>The parameters <tt>error</tt>, <tt>error_description</tt>, and
<tt>error_uri</tt> <bcp14>MUST</bcp14>
be abbreviated using the codes specified in <xref target="table_cborTokenParameters" format="default"/>, when a CBOR encoding is used.</li> be abbreviated using the codes specified in <xref target="table_cborTokenParameters" format="default"/>, when a CBOR encoding is used.</li>
<li>The error code (i.e., value of the "error" parameter) <bcp14>MUST</bcp14> be <li>The error code (i.e., value of the <tt>error</tt> parameter) <bcp14>MUST</bcp14> be
abbreviated, as specified in <xref target="table_cborErrorCodes" format="default"/>, when a CBOR encoding is used.</li> abbreviated, as specified in <xref target="table_cborErrorCodes" format="default"/>, when a CBOR encoding is used.</li>
</ul> </ul>
<!--[rfced] Please review whether "abbreviations" is an accurate term
as used in this document. For example: Section 5.8 refers to "integer
abbreviations for the parameters or their values".
Specifically, in the cases below, perhaps "values" would be more
precise than "abbreviations"? (where "CBOR Value" is the column title
in the corresponding IANA registry)
Current:
Table 3: CBOR Abbreviations for Common Error Codes
Perhaps:
Table 3: CBOR Values for Common Error Codes
Current:
Table 4: CBOR Abbreviations for Common Grant Types
Perhaps:
Table 4: CBOR Values for Common Grant Types
<table anchor="table_cborErrorCodes"> <table anchor="table_cborErrorCodes">
<name>CBOR Abbreviations for Common Error Codes</name> <name>CBOR Abbreviations for Common Error Codes</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>CBOR Values</th> <th>CBOR Values</th>
<th>Original Specification</th> <th>Original Specification</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
skipping to change at line 1562 skipping to change at line 1452
<tr> <tr>
<td>refresh_token</td> <td>refresh_token</td>
<td>3</td> <td>3</td>
<td><xref target="RFC6749" sectionFormat="of" section="6"/></td> <td><xref target="RFC6749" sectionFormat="of" section="6"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="paramTokenType" numbered="true" toc="default"> <section anchor="paramTokenType" numbered="true" toc="default">
<name>Token Type</name> <name>Token Type</name>
<t>The "token_type" parameter, defined in <xref target="RFC6749" <t>The <tt>token_type</tt> parameter, defined in <xref target="RFC6749"
sectionFormat="of" section="5.1"/>, allows the AS to indicate to the sectionFormat="of" section="5.1"/>, allows the AS to indicate to the
client which type of client which type of
access token it is receiving (e.g., a bearer token). </t> access token it is receiving (e.g., a bearer token). </t>
<t>This document registers the new value "PoP" for the "OAuth Access <t>This document registers the new value "PoP" for the "OAuth Access
Token Types" registry, specifying a proof-of-possession token. How the Token Types" registry, specifying a proof-of-possession token. How the
proof of possession by the client to the RS is performed proof of possession by the client to the RS is performed
<bcp14>MUST</bcp14> be specified by the profiles.</t> <bcp14>MUST</bcp14> be specified by the profiles.</t>
<t>The values in the "token_type" parameter <bcp14>MUST</bcp14> use the <t>The values in the <tt>token_type</tt> parameter <bcp14>MUST</bcp14> use the
CBOR abbreviations defined in the registry specified by CBOR abbreviations defined in the registry specified by
<xref target="IANATokenTypeMappings" format="default"/> if a CBOR <xref target="IANATokenTypeMappings" format="default"/> if a CBOR
encoding is used.</t> encoding is used.</t>
<t>In this framework, the "pop" value for the "token_type" parameter is <t>In this framework, the "pop" value for the <tt>token_type</tt> parameter is
the default. The AS may, however, provide a different value from those the default. The AS may, however, provide a different value from those
registered in <xref target="IANA.OAuthAccessTokenTypes" format="default"/>.</t> registered in <xref target="IANA.OAuthAccessTokenTypes" format="default"/>.</t>
</section> </section>
<section anchor="paramProfile" numbered="true" toc="default"> <section anchor="paramProfile" numbered="true" toc="default">
<name>Profile</name> <name>Profile</name>
<t>Profiles of this framework <bcp14>MUST</bcp14> define the communication <t>Profiles of this framework <bcp14>MUST</bcp14> define the communication
protocol and the communication security protocol between the client protocol and the communication security protocol between the client
and the RS. The security protocol <bcp14>MUST</bcp14> provide encryption, and the RS. The security protocol <bcp14>MUST</bcp14> provide encryption,
integrity, and integrity, and
replay protection. It <bcp14>MUST</bcp14> also provide a binding between replay protection. It <bcp14>MUST</bcp14> also provide a binding between
requests and requests and
responses. Furthermore, profiles <bcp14>MUST</bcp14> define a list of responses. Furthermore, profiles <bcp14>MUST</bcp14> define a list of
allowed proof-of-possession methods if they support proof-of-possession allowed proof-of-possession methods if they support proof-of-possession
tokens.</t> tokens.</t>
<t>A profile <bcp14>MUST</bcp14> specify an identifier that <bcp14>MUST</bcp14> be used to uniquely <t>A profile <bcp14>MUST</bcp14> specify an identifier that <bcp14>MUST</bcp14> be used to uniquely
identify itself in the "ace_profile" parameter. The textual identify itself in the <tt>ace_profile</tt> parameter. The textual
representation of the profile identifier is intended for human representation of the profile identifier is intended for human
readability and for JSON-based interactions; it <bcp14>MUST NOT</bcp14> be used for readability and for JSON-based interactions; it <bcp14>MUST NOT</bcp14> be used for
CBOR-based interactions. Profiles <bcp14>MUST</bcp14> register their identifier in the CBOR-based interactions. Profiles <bcp14>MUST</bcp14> register their identifier in the
registry defined in <xref target="IANAProfile" format="default"/>. registry defined in <xref target="IANAProfile" format="default"/>.
</t> </t>
<t>Profiles <bcp14>MAY</bcp14> define additional parameters for both the token request <t>Profiles <bcp14>MAY</bcp14> define additional parameters for both the token request
and the Access Information in the access token response in order to and the Access Information in the access token response in order to
support negotiation or signaling of profile-specific parameters. support negotiation or signaling of profile-specific parameters.
</t> </t>
<t>Clients that want the AS to provide them with the "ace_profile" <t>Clients that want the AS to provide them with the <tt>ace_profile</tt>
parameter in the access token response can indicate that by sending a parameter in the access token response can indicate that by sending an
ace_profile parameter with a null value for CBOR-based interactions, <tt>ace_profile</tt> parameter with a null value for CBOR-based interactions,
or an empty string if CBOR is not used, in the access token or an empty string if CBOR is not used, in the access token
request.</t> request.</t>
</section> </section>
<section anchor="cnonceParamToken" numbered="true" toc="default"> <section anchor="cnonceParamToken" numbered="true" toc="default">
<name>Client-Nonce</name> <name>Client-Nonce</name>
<t>This parameter <bcp14>MUST</bcp14> be sent from the client to the AS <t>This parameter <bcp14>MUST</bcp14> be sent from the client to the AS
if it previously received a "cnonce" parameter in the "AS Request if it previously received a <tt>cnonce</tt> parameter in the "AS Request
Creation Hints" (<xref target="asInfo" format="default"/>). The parameter Creation Hints" (<xref target="asInfo" format="default"/>). The parameter
is encoded as a byte string for CBOR-based interactions and as a is encoded as a byte string for CBOR-based interactions and as a
string (base64url without padding encoded binary <xref target="RFC4648" string (base64url without padding encoded binary <xref target="RFC4648"
format="default"/>) if CBOR is not used. format="default"/>) if CBOR is not used.
It <bcp14>MUST</bcp14> copy the value from the cnonce parameter in the "AS It <bcp14>MUST</bcp14> copy the value from the <tt>cnonce</tt> parameter in
Request Creation Hints".</t> the "AS Request Creation Hints".</t>
</section> </section>
</section> </section>
<!--Parameters -->
<section anchor="tokenCborParams" numbered="true" toc="default"> <section anchor="tokenCborParams" numbered="true" toc="default">
<name>Mapping Parameters to CBOR</name> <name>Mapping Parameters to CBOR</name>
<t>If CBOR encoding is used, all OAuth parameters in access token requests <t>If CBOR encoding is used, all OAuth parameters in access token requests
and responses <bcp14>MUST</bcp14> be mapped to CBOR types, as specified in the registry and responses <bcp14>MUST</bcp14> be mapped to CBOR types, as specified in the registry
defined by <xref target="IANAOAuthParameterMappingsRegistry" format="default"/>, using the defined by <xref target="IANAOAuthParameterMappingsRegistry" format="default"/>, using the
given integer abbreviation for the map keys.</t> given integer abbreviation for the map keys.</t>
<t>Note that we have aligned the abbreviations corresponding to claims <t>Note that we have aligned the abbreviations corresponding to claims
with the abbreviations defined in <xref target="RFC8392" format="default"/>.</t> with the abbreviations defined in <xref target="RFC8392" format="default"/>.</t>
<t>Note also that abbreviations from -24 to 23 have a 1-byte encoding <t>Note also that abbreviations from -24 to 23 have a 1-byte encoding
skipping to change at line 1768 skipping to change at line 1657
<tr> <tr>
<td>cnonce</td> <td>cnonce</td>
<td>39</td> <td>39</td>
<td>byte string</td> <td>byte string</td>
<td>RFC 9200</td> <td>RFC 9200</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<!-- Token endpoint -->
<section anchor="introspectionEndpoint" numbered="true" toc="default"> <section anchor="introspectionEndpoint" numbered="true" toc="default">
<name>The Introspection Endpoint</name> <name>The Introspection Endpoint</name>
<t>Token introspection <xref target="RFC7662" format="default"/> <bcp14>MAY</bcp14> <t>Token introspection <xref target="RFC7662" format="default"/> <bcp14>MAY</bcp14>
be implemented by the AS and the RS. When implemented, it <bcp14>MAY</bcp14> be be implemented by the AS and the RS. When implemented, it <bcp14>MAY</bcp14> be
used by the RS and to query the used by the RS and to query the
AS for metadata about a given token, e.g., validity or scope. Analogous to the AS for metadata about a given token, e.g., validity or scope. Analogous to the
protocol defined in <xref target="RFC7662" format="default"/> for HTTP and JSON, protocol defined in <xref target="RFC7662" format="default"/> for HTTP and JSON,
this section defines adaptations to more constrained environments using CBOR and this section defines adaptations to more constrained environments using CBOR and
leaving the choice of the application protocol to the profile.</t> leaving the choice of the application protocol to the profile.</t>
skipping to change at line 1853 skipping to change at line 1741
<xref target="errorsIntro" format="default"/>.</t> <xref target="errorsIntro" format="default"/>.</t>
<t>In a successful response, the AS encodes the response parameters in <t>In a successful response, the AS encodes the response parameters in
a map. If CoAP is used, this <bcp14>MUST</bcp14> be encoded as a CBOR map; if a map. If CoAP is used, this <bcp14>MUST</bcp14> be encoded as a CBOR map; if
HTTP is used, the JSON encoding specified in <xref target="RFC7662" HTTP is used, the JSON encoding specified in <xref target="RFC7662"
sectionFormat="of" section="2.2"/> sectionFormat="of" section="2.2"/>
is used. The map containing the response payload includes the same is used. The map containing the response payload includes the same
required and optional parameters as in required and optional parameters as in
<xref target="RFC7662" sectionFormat="of" section="2.2"/>, with the following <xref target="RFC7662" sectionFormat="of" section="2.2"/>, with the following
additions:</t> additions:</t>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>ace_profile:</dt> <dt><tt>ace_profile</tt>:</dt>
<dd>This parameter is <bcp14>OPTIONAL</bcp14>. This indicates the profile that <dd>This parameter is <bcp14>OPTIONAL</bcp14>. This indicates the profile that
the RS <bcp14>MUST</bcp14> use with the the RS <bcp14>MUST</bcp14> use with the
client. See <xref target="paramProfile" format="default"/> for more details on client. See <xref target="paramProfile" format="default"/> for more details on
the formatting of this parameter. If this parameter is absent, the AS the formatting of this parameter. If this parameter is absent, the AS
assumes that the RS implicitly knows which profile to use towards assumes that the RS implicitly knows which profile to use towards
the client.</dd> the client.</dd>
<dt>cnonce:</dt> <dt><tt>cnonce</tt>:</dt>
<dd>This parameter is <bcp14>OPTIONAL</bcp14>. This is a <dd>This parameter is <bcp14>OPTIONAL</bcp14>. This is a
client-nonce provided to the AS by the client. client-nonce provided to the AS by the client.
The RS <bcp14>MUST</bcp14> verify that this corresponds to the The RS <bcp14>MUST</bcp14> verify that this corresponds to the
client-nonce client-nonce
previously provided to the client in the "AS Request Creation previously provided to the client in the "AS Request Creation
Hints". See Sections <xref target="asInfo" format="counter"/> and Hints". See Sections <xref target="asInfo" format="counter"/> and
<xref target="cnonceParamToken" format="counter"/>. Its value is a <xref target="cnonceParamToken" format="counter"/>. Its value is a
byte string when encoded in CBOR and is the base64url encoding of this byte string when encoded in CBOR and is the base64url encoding of this
byte string without padding when encoded in JSON <xref byte string without padding when encoded in JSON <xref
target="RFC4648" format="default"/>. target="RFC4648" format="default"/>.
</dd> </dd>
<dt>cti:</dt> <dt><tt>cti</tt>:</dt>
<dd>This parameter is <bcp14>OPTIONAL</bcp14>. This is the "cti" claim associated to <dd>This parameter is <bcp14>OPTIONAL</bcp14>. This is the <tt>cti</tt>
this access token. claim associated to this access token.
This parameter has the same meaning and processing rules as the This parameter has the same meaning and processing rules as the
"jti" parameter defined in <xref target="RFC7662" sectionFormat="of" <tt>jti</tt> parameter defined in <xref target="RFC7662" sectionFormat="of"
section="3.1.2"/> except that its value is a byte string when encoded section="3.1.2"/> except that its value is a byte string when encoded
in CBOR and is the base64url encoding of this byte string without in CBOR and is the base64url encoding of this byte string without
padding when encoded in JSON <xref target="RFC4648" padding when encoded in JSON <xref target="RFC4648"
format="default"/>.</dd> format="default"/>.</dd>
<dt>exi:</dt> <dt><tt>exi</tt>:</dt>
<dd>This parameter is <bcp14>OPTIONAL</bcp14>. This is the <dd>This parameter is <bcp14>OPTIONAL</bcp14>. This is the
"expires-in" claim associated to this access token. <tt>expires-in</tt> claim associated to this access token.
See <xref target="tokenExpiration" format="default"/>. See <xref target="tokenExpiration" format="default"/>.
</dd> </dd>
</dl> </dl>
<t>Furthermore, <xref target="RFC9201" format="default"/> defines <t>Furthermore, <xref target="RFC9201" format="default"/> defines
more parameters that the AS <bcp14>MUST</bcp14> be able to use when responding to a more parameters that the AS <bcp14>MUST</bcp14> be able to use when responding to a
request to the introspection endpoint.</t> request to the introspection endpoint.</t>
<t>For example, <xref target="fig_introRes" format="default"/> shows an AS <t>For example, <xref target="fig_introRes" format="default"/> shows an AS
response to the introspection request in <xref target="fig_introReq" format="default"/>. response to the introspection request in <xref target="fig_introReq" format="default"/>.
Note that this example contains the "cnf" parameter defined in Note that this example contains the <tt>cnf</tt> parameter defined in
<xref target="RFC9201" format="default"/>. <xref target="RFC9201" format="default"/>.
</t> </t>
<figure anchor="fig_introRes"> <figure anchor="fig_introRes">
<name>Example Introspection Response</name> <name>Example Introspection Response</name>
<sourcecode name="" type="cbor-diag"><![CDATA[ <sourcecode name="" type="cbor-diag"><![CDATA[
Header: Created (Code=2.01) Header: Created (Code=2.01)
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
skipping to change at line 1940 skipping to change at line 1828
<li>If the credentials used by the requesting entity (usually the RS) <li>If the credentials used by the requesting entity (usually the RS)
are invalid, the AS <bcp14>MUST</bcp14> respond with the response code are invalid, the AS <bcp14>MUST</bcp14> respond with the response code
equivalent to the equivalent to the
CoAP code 4.01 (Unauthorized) and use the required and optional CoAP code 4.01 (Unauthorized) and use the required and optional
parameters from <xref target="RFC7662" sectionFormat="of" parameters from <xref target="RFC7662" sectionFormat="of"
section="2.3"/>.</li> section="2.3"/>.</li>
<li>If the requesting entity does not have the right to perform this <li>If the requesting entity does not have the right to perform this
introspection request, the AS <bcp14>MUST</bcp14> respond with a response code introspection request, the AS <bcp14>MUST</bcp14> respond with a response code
equivalent to the CoAP code 4.03 (Forbidden). In this case, no payload is equivalent to the CoAP code 4.03 (Forbidden). In this case, no payload is
returned.</li> returned.</li>
<li>The parameters "error", "error_description", and "error_uri" <bcp14>MUST</bcp14> <li>The parameters <tt>error</tt>, <tt>error_description</tt>, and <tt>error_uri</tt> <bcp14>MUST</bcp14>
be abbreviated using the codes specified in <xref target="table_cborTokenParameters" format="default"/>.</li> be abbreviated using the codes specified in <xref target="table_cborTokenParameters" format="default"/>.</li>
<li>The error codes <bcp14>MUST</bcp14> be abbreviated using the codes specified in <li>The error codes <bcp14>MUST</bcp14> be abbreviated using the codes specified in
the registry defined by <xref target="IANAErrorCBORMappings" format="default"/>.</li> the registry defined by <xref target="IANAErrorCBORMappings" format="default"/>.</li>
</ul> </ul>
<t>Note that a properly formed and authorized query for an inactive or <t>Note that a properly formed and authorized query for an inactive or
otherwise invalid token does not warrant an error response by this otherwise invalid token does not warrant an error response by this
specification. In these cases, the authorization server <bcp14>MUST</bcp14> instead specification. In these cases, the authorization server <bcp14>MUST</bcp14> instead
respond with an introspection response with the "active" field set to respond with an introspection response with the <tt>active</tt> field set to
"false".</t> "false".</t>
</section> </section>
<section anchor="introParamsCbor" numbered="true" toc="default"> <section anchor="introParamsCbor" numbered="true" toc="default">
<name>Mapping Introspection Parameters to CBOR</name> <name>Mapping Introspection Parameters to CBOR</name>
<t>If CBOR is used, the introspection request and response parameters <bcp14>MUST</bcp14> <t>If CBOR is used, the introspection request and response parameters <bcp14>MUST</bcp14>
be mapped to CBOR types, as specified in the registry defined by <xref target="IANAIntrospectionEndpointCBORMappingsRegistry" format="default"/>, using the given be mapped to CBOR types, as specified in the registry defined by <xref target="IANAIntrospectionEndpointCBORMappingsRegistry" format="default"/>, using the given
integer abbreviation for the map key.</t> integer abbreviation for the map key.</t>
<t>Note that we have aligned abbreviations that correspond to a <t>Note that we have aligned abbreviations that correspond to a
claim with the abbreviations defined in <xref target="RFC8392" format="default"/> claim with the abbreviations defined in <xref target="RFC8392" format="default"/>
and the abbreviations of parameters with the same name from and the abbreviations of parameters with the same name from
skipping to change at line 2086 skipping to change at line 1974
<td>38</td> <td>38</td>
<td>integer</td> <td>integer</td>
<td>RFC 9200</td> <td>RFC 9200</td>
</tr> </tr>
<tr> <tr>
<td>cnonce</td> <td>cnonce</td>
<td>39</td> <td>39</td>
<td>byte string</td> <td>byte string</td>
<td>RFC 9200</td> <td>RFC 9200</td>
</tr> </tr>
<!-- [rfced] For exi's type, the word "unsigned" has been removed because
it does not appear in the IANA registry. Please review and let us know if
this should be handled otherwise.
Original:
| exi | 40 | unsigned integer |[this document]|
Current:
| exi | 40 | integer | RFC 9200 |
<tr> <tr>
<td>exi</td> <td>exi</td>
<td>40</td> <td>40</td>
<td>integer</td> <td>unsigned integer</td>
<td>RFC 9200</td> <td>RFC 9200</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<!-- introspection endpoint -->
<section anchor="accessToken" numbered="true" toc="default"> <section anchor="accessToken" numbered="true" toc="default">
<name>The Access Token</name> <name>The Access Token</name>
<t>In this framework, the use of CBOR Web Token (CWT) as <t>In this framework, the use of CBOR Web Token (CWT) as
specified in <xref target="RFC8392" format="default"/> is <bcp14>RECOMMENDED</bcp14>. specified in <xref target="RFC8392" format="default"/> is <bcp14>RECOMMENDED</bcp14>.
</t> </t>
<t>In order to facilitate offline processing of access tokens, <t>In order to facilitate offline processing of access tokens,
this document uses the "cnf" claim from <xref target="RFC8747" format="default"/> and the "scope" claim from <xref target="RFC8693" format="default"/> for this document uses the <tt>cnf</tt> claim from <xref target="RFC8747"
format="default"/> and the <tt>scope</tt> claim from <xref target="RFC8693"
format="default"/> for
JWT- and CWT-encoded tokens. In addition to string encoding specified for JWT- and CWT-encoded tokens. In addition to string encoding specified for
the "scope" claim, a binary encoding <bcp14>MAY</bcp14> be used. The syntax of such an the <tt>scope</tt> claim, a binary encoding <bcp14>MAY</bcp14> be used. The syntax of such an
encoding is explicitly not specified here and left to profiles or encoding is explicitly not specified here and left to profiles or
applications, specifically note that a binary encoded scope does not applications, specifically note that a binary encoded scope does not
necessarily use the space character '0x20' to delimit scope-tokens.</t> necessarily use the space character '0x20' to delimit scope-tokens.</t>
<t>If the AS needs to convey a hint to the RS about which profile it <t>If the AS needs to convey a hint to the RS about which profile it
should use to communicate with the client, the AS <bcp14>MAY</bcp14> include an should use to communicate with the client, the AS <bcp14>MAY</bcp14> include an
"ace_profile" claim in the access token, with the same syntax and semantics <tt>ace_profile</tt> claim in the access token, with the same syntax and semantics
as defined in <xref target="paramProfile" format="default"/>.</t> as defined in <xref target="paramProfile" format="default"/>.</t>
<t>If the client submitted a client-nonce parameter in the access token <t>If the client submitted a <tt>cnonce</tt> parameter in the access token
request (<xref target="cnonceParamToken" format="default"/>), the AS request (<xref target="cnonceParamToken" format="default"/>), the AS
<bcp14>MUST</bcp14> include the value of <bcp14>MUST</bcp14> include the value of
this parameter in the "cnonce" claim specified here. The "cnonce" claim this parameter in the <tt>cnonce</tt> claim specified here. The <tt>cnonce</tt>
uses binary encoding.</t> claim uses binary encoding.</t>
<section anchor="tokenAuthInfoEndpoint" numbered="true" toc="default"> <section anchor="tokenAuthInfoEndpoint" numbered="true" toc="default">
<name>The Authorization Information Endpoint</name> <name>The Authorization Information Endpoint</name>
<t>The access token, containing authorization information and information <t>The access token, containing authorization information and information
about the proof-of-possession method used by the client, needs to be about the proof-of-possession method used by the client, needs to be
transported to the RS so that the RS can authenticate and authorize the transported to the RS so that the RS can authenticate and authorize the
client request.</t> client request.</t>
<t>This section defines a method for transporting the access token to the RS <t>This section defines a method for transporting the access token to the RS
using a RESTful protocol, such as CoAP. Profiles of this framework <bcp14>MAY</bcp14> define using a RESTful protocol, such as CoAP. Profiles of this framework <bcp14>MAY</bcp14> define
other methods for token transport. other methods for token transport.
</t> </t>
skipping to change at line 2195 skipping to change at line 2074
however, implementations are not required to use this name and can define however, implementations are not required to use this name and can define
their own instead.</t> their own instead.</t>
<section anchor="verifyToken" numbered="true" toc="default"> <section anchor="verifyToken" numbered="true" toc="default">
<name>Verifying an Access Token</name> <name>Verifying an Access Token</name>
<t>When an RS receives an access token, it <bcp14>MUST</bcp14> verify it before storing <t>When an RS receives an access token, it <bcp14>MUST</bcp14> verify it before storing
it. The details of token verification depends on various aspects, including it. The details of token verification depends on various aspects, including
the token encoding, the type of token, the security protection applied to the token encoding, the type of token, the security protection applied to
the token, and the claims. The token encoding matters since the security the token, and the claims. The token encoding matters since the security
protection differs between the token encodings. For example, a CWT token protection differs between the token encodings. For example, a CWT token
uses COSE, while a JWT token uses JSON Object Signing and Encryption (JOSE). uses COSE, while a JWT token uses JSON Object Signing and Encryption (JOSE).
<!--[rfced] Should "token-by-reference" be "reference token" in this sentence?
Original:
The type of token also has an influence on the verification
procedure since tokens may be self-contained whereby token
verification may happen locally at the RS while a token-by-reference
requires further interaction with the authorization server, for
example using token introspection, to obtain the claims associated
with the token reference.
The type of token also has an The type of token also has an
influence on the verification procedure since tokens may be self-contained, influence on the verification procedure since tokens may be self-contained,
whereby token verification may happen locally at the RS, while a whereby token verification may happen locally at the RS, while a
token-by-reference requires further interaction with the authorization reference token requires further interaction with the authorization
server, for example, using token introspection, to obtain the claims server, for example, using token introspection, to obtain the claims
associated with the token reference. Self-contained tokens <bcp14>MUST</bcp14> at associated with the token reference. Self-contained tokens <bcp14>MUST</bcp14> at
least be integrity protected, but they <bcp14>MAY</bcp14> also be encrypted.</t> least be integrity protected, but they <bcp14>MAY</bcp14> also be encrypted.</t>
<t>For self-contained tokens, the RS <bcp14>MUST</bcp14> process the security <t>For self-contained tokens, the RS <bcp14>MUST</bcp14> process the security
protection of the token first, as specified by the respective token format. protection of the token first, as specified by the respective token format.
For CWT, the description can be found in <xref target="RFC8392" For CWT, the description can be found in <xref target="RFC8392"
format="default"/>; for format="default"/>; for
JWT, the relevant specification is <xref target="RFC7519" format="default"/>. JWT, the relevant specification is <xref target="RFC7519" format="default"/>.
This <bcp14>MUST</bcp14> This <bcp14>MUST</bcp14>
include a verification that security protection (and thus the token) was include a verification that security protection (and thus the token) was
skipping to change at line 2246 skipping to change at line 2115
message with a response code equivalent to the CoAP code 4.00 (Bad message with a response code equivalent to the CoAP code 4.00 (Bad
Request).</li> Request).</li>
</ul> </ul>
<t>Next, the RS <bcp14>MUST</bcp14> verify claims, if present, contained in the <t>Next, the RS <bcp14>MUST</bcp14> verify claims, if present, contained in the
access access
token. Errors are returned when claim checks fail, in the order of token. Errors are returned when claim checks fail, in the order of
priority of this list: priority of this list:
</t> </t>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>iss</dt> <dt>iss</dt>
<dd>The issuer claim (if present) must identify the AS that <dd>The <tt>iss</tt> claim (if present) must identify the AS that
has produced the security protection for the access token. If that is has produced the security protection for the access token. If that is
not the case, the RS <bcp14>MUST</bcp14> discard the token. If this was an not the case, the RS <bcp14>MUST</bcp14> discard the token. If this was an
interaction with authz-info, the RS <bcp14>MUST</bcp14> also respond with a interaction with authz-info, the RS <bcp14>MUST</bcp14> also respond with a
response code equivalent response code equivalent
to the CoAP code 4.01 (Unauthorized).</dd> to the CoAP code 4.01 (Unauthorized).</dd>
<dt>exp</dt> <dt>exp</dt>
<dd>The expiration date must be in the future. <dd>The expiration date must be in the future.
If that is not the case, the RS <bcp14>MUST</bcp14> discard the token. If If that is not the case, the RS <bcp14>MUST</bcp14> discard the token. If
this was an this was an
interaction with authz-info, the RS <bcp14>MUST</bcp14> also respond with a interaction with authz-info, the RS <bcp14>MUST</bcp14> also respond with a
response code response code
equivalent to the CoAP code 4.01 (Unauthorized). Note that the RS has to equivalent to the CoAP code 4.01 (Unauthorized). Note that the RS has to
terminate access rights to the protected resources at the time when the terminate access rights to the protected resources at the time when the
tokens expire. </dd> tokens expire. </dd>
<dt>aud</dt> <dt>aud</dt>
<dd>The audience claim must refer to an audience that <dd>The <tt>aud</tt> claim must refer to an audience that
the RS identifies with. If that is not the case, the RS <bcp14>MUST</bcp14> the RS identifies with. If that is not the case, the RS <bcp14>MUST</bcp14>
discard the discard the
token. If this was an interaction with authz-info, the RS token. If this was an interaction with authz-info, the RS
<bcp14>MUST</bcp14> also <bcp14>MUST</bcp14> also
respond with a response code equivalent to the CoAP code 4.03 respond with a response code equivalent to the CoAP code 4.03
(Forbidden).</dd> (Forbidden).</dd>
<dt>scope</dt> <dt>scope</dt>
<dd>The RS must recognize value of the scope claim. <dd>The RS must recognize value of the <tt>scope</tt> claim.
If that is not the case, the RS <bcp14>MUST</bcp14> discard the token. If If that is not the case, the RS <bcp14>MUST</bcp14> discard the token. If
this was an this was an
interaction with authz-info, the RS <bcp14>MUST</bcp14> also respond with a interaction with authz-info, the RS <bcp14>MUST</bcp14> also respond with a
response code response code
equivalent to the CoAP code 4.00 (Bad Request). The RS <bcp14>MAY</bcp14> equivalent to the CoAP code 4.00 (Bad Request). The RS <bcp14>MAY</bcp14>
provide provide
additional information in the error response to clarify what additional information in the error response to clarify what
went wrong.</dd> went wrong.</dd>
</dl> </dl>
<t>Additional processing may be needed for other claims in a way <t>Additional processing may be needed for other claims in a way
specific to a profile or the underlying application.</t> specific to a profile or the underlying application.</t>
<t>Note that the Subject (sub) claim cannot always be verified when <t>Note that the Subject (<tt>sub</tt>) claim cannot always be verified when
the token is submitted to the RS since the client may not have the token is submitted to the RS since the client may not have
authenticated yet. Also note that a counter for the expires_in (exi) claim authenticated yet. Also note that a counter for the expires_in (<tt>exi</tt>) claim
<bcp14>MUST</bcp14> be initialized when the RS first verifies this token.</t> <bcp14>MUST</bcp14> be initialized when the RS first verifies this token.</t>
<t>Also note that profiles of this framework may define access token <t>Also note that profiles of this framework may define access token
transport mechanisms that do not allow for error responses. Therefore, the transport mechanisms that do not allow for error responses. Therefore, the
error messages specified here only apply if the token was sent to the error messages specified here only apply if the token was sent to the
authz-info endpoint.</t> authz-info endpoint.</t>
<t>When sending error responses, the RS <bcp14>MAY</bcp14> use the error <t>When sending error responses, the RS <bcp14>MAY</bcp14> use the error
codes from <xref target="RFC6750" sectionFormat="of" section="3.1"/> to codes from <xref target="RFC6750" sectionFormat="of" section="3.1"/> to
provide additional details to the client.</t> provide additional details to the client.</t>
</section> </section>
<section anchor="protAuthzInfo" numbered="true" toc="default"> <section anchor="protAuthzInfo" numbered="true" toc="default">
skipping to change at line 2325 skipping to change at line 2194
that authorizes this request and that the client has performed the that authorizes this request and that the client has performed the
proof-of-possession binding for that token to the request.</t> proof-of-possession binding for that token to the request.</t>
<t>The response code <bcp14>MUST</bcp14> be 4.01 (Unauthorized) in case the client has <t>The response code <bcp14>MUST</bcp14> be 4.01 (Unauthorized) in case the client has
not performed the proof of possession or if the RS has no valid access token for not performed the proof of possession or if the RS has no valid access token for
the client. If the RS has an access token for the client but the token does not the client. If the RS has an access token for the client but the token does not
authorize access for the resource that was requested, the RS <bcp14>MUST</bcp14> reject the authorize access for the resource that was requested, the RS <bcp14>MUST</bcp14> reject the
request with a 4.03 (Forbidden). If the RS has an access token for the client but request with a 4.03 (Forbidden). If the RS has an access token for the client but
it does not cover the action that was requested on the resource, the RS <bcp14>MUST</bcp14> it does not cover the action that was requested on the resource, the RS <bcp14>MUST</bcp14>
reject the request with a 4.05 (Method Not Allowed).</t> reject the request with a 4.05 (Method Not Allowed).</t>
<t>Note: The use of the response codes 4.03 and 4.05 is intended to prevent <t>Note: The use of the response codes 4.03 and 4.05 is intended to prevent
infinite loops where a dumb client optimistically tries to access a infinite loops where a client optimistically tries to access a
requested resource with any access token received from AS. As malicious requested resource with any access token received from AS. As malicious
clients could pretend to be the C to determine the C's privileges, these detailed clients could pretend to be the C to determine the C's privileges, these detailed
response codes must be used only when a certain level of security is response codes must be used only when a certain level of security is
already available, which can be achieved only when the client is already available, which can be achieved only when the client is
authenticated.</t> authenticated.</t>
<t>Note: The RS <bcp14>MAY</bcp14> use introspection for timely validation of an <t>Note: The RS <bcp14>MAY</bcp14> use introspection for timely validation of an
access token at the time when a request is presented.</t> access token at the time when a request is presented.</t>
<t>Note: Matching the claims of the access token (e.g., scope) to a specific <t>Note: Matching the claims of the access token (e.g., scope) to a specific
request is application specific.</t> request is application specific.</t>
<t>If the request matches a valid token and the client has performed the <t>If the request matches a valid token and the client has performed the
proof of possession for that token, the RS continues to process the request proof of possession for that token, the RS continues to process the request
as specified by the underlying application.</t> as specified by the underlying application.</t>
</section> </section>
<section anchor="tokenExpiration" numbered="true" toc="default"> <section anchor="tokenExpiration" numbered="true" toc="default">
<name>Token Expiration</name> <name>Token Expiration</name>
<t>Depending on the capabilities of the RS, there are various ways in <t>Depending on the capabilities of the RS, there are various ways in
which it can verify the expiration of a received access token. The following is which it can verify the expiration of a received access token. The following is
a list of the possibilities including what functionality they require of the a list of the possibilities including what functionality they require of the
RS.</t> RS.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The token is a CWT and includes an "exp" claim and possibly the <li>The token is a CWT and includes an <tt>exp</tt> claim and possibly the
"nbf" claim. The RS verifies these by comparing them to values from <tt>nbf</tt> claim. The RS verifies these by comparing them to values from
its internal clock, as defined in <xref target="RFC7519" format="default"/>. In its internal clock, as defined in <xref target="RFC7519" format="default"/>.
this case, the RS's internal clock must reflect the current date and time or In this case, the RS's internal clock must reflect the current date and time
at least be synchronized with the AS's clock. How this clock or at least be synchronized with the AS's clock. How this clock
synchronization would be performed is out of scope for this synchronization would be performed is out of scope for this
specification.</li> specification.</li>
<li>The RS verifies the validity of the token by performing an <li>The RS verifies the validity of the token by performing an
introspection request, as specified in <xref target="introspectionEndpoint" introspection request, as specified in <xref target="introspectionEndpoint"
format="default"/>. This requires the RS to have a format="default"/>. This requires the RS to have a
reliable network connection to the AS and to be able to handle two reliable network connection to the AS and to be able to handle two
secure sessions in parallel (C to RS and RS to AS).</li> secure sessions in parallel (C to RS and RS to AS).</li>
<li>In order to support token expiration for devices that have no reliable <li>In order to support token expiration for devices that have no reliable
way of synchronizing their internal clocks, this specification defines the way of synchronizing their internal clocks, this specification defines the
following approach: The claim "exi" ("expires in") can be used to provide following approach: The claim <tt>exi</tt> ("expires in") can be used to provide
the RS with the lifetime of the token in seconds from the time the RS first the RS with the lifetime of the token in seconds from the time the RS first
receives the token. This mechanism only works for self-contained tokens, receives the token. This mechanism only works for self-contained tokens,
i.e., CWTs and JWTs. For CWTs, this parameter is encoded as an unsigned integer, i.e., CWTs and JWTs. For CWTs, this parameter is encoded as an unsigned integer,
while JWTs encode this as JSON number.</li> while JWTs encode this as JSON number.</li>
<li> <li>
<t> Processing this claim requires that the RS does the following: <t> Processing this claim requires that the RS does the following:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>For each token the RS receives that contains an "exi" claim, <li>For each token the RS receives that contains an <tt>exi</tt> claim,
keep track of the time it received that token and revisit that list keep track of the time it received that token and revisit that list
regularly to expunge expired tokens.</li> regularly to expunge expired tokens.</li>
<li> <li>
<t>Keep track of the identifiers of tokens containing the "exi" <t>Keep track of the identifiers of tokens containing the <tt>exi</tt>
claim that have expired (in order to avoid accepting them again). claim that have expired (in order to avoid accepting them again).
In order to avoid an unbounded memory usage growth, this <bcp14>MUST</bcp14> be In order to avoid an unbounded memory usage growth, this <bcp14>MUST</bcp14> be
implemented in the following way when the "exi" claim is used: implemented in the following way when the <tt>exi</tt> claim is used:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>When creating the token, the AS <bcp14>MUST</bcp14> add a 'cti' claim ( <li>When creating the token, the AS <bcp14>MUST</bcp14> add a <tt>cti</tt> claim (or <tt>jti</tt> for JWTs) to the access token. The value of this claim
or 'jti' for JWTs) to the access token. The value of this claim
<bcp14>MUST</bcp14> be created as the binary representation of the concatenation <bcp14>MUST</bcp14> be created as the binary representation of the concatenation
of the identifier of the RS with a sequence number counting the of the identifier of the RS with a sequence number counting the
tokens containing an 'exi' claim, issued by this AS for the tokens containing an <tt>exi</tt> claim, issued by this AS for the
RS.</li> RS.</li>
<li>The RS <bcp14>MUST</bcp14> store the highest sequence number of an expired <li>The RS <bcp14>MUST</bcp14> store the highest sequence number of an expired
token containing the "exi" claim that it has seen and treat token containing the <tt>exi</tt> claim that it has seen and treat
tokens with lower sequence numbers as expired. Note that tokens with lower sequence numbers as expired. Note that
this could lead to discarding valid tokens with lower sequence numbers this could lead to discarding valid tokens with lower sequence numbers
if the AS where to issue tokens of different validity time for the same if the AS where to issue tokens of different validity time for the same
RS. The assumption is that typically tokens in such a scenario would RS. The assumption is that typically tokens in such a scenario would
all have the same validity time.</li> all have the same validity time.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
skipping to change at line 2427 skipping to change at line 2295
is opaque to the client, one of the following methods <bcp14>MUST</bcp14> be used to is opaque to the client, one of the following methods <bcp14>MUST</bcp14> be used to
inform the client about the validity of an access token: inform the client about the validity of an access token:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The client knows a default validity time for all tokens it is <li>The client knows a default validity time for all tokens it is
using (i.e., how long a token is valid after being issued). This using (i.e., how long a token is valid after being issued). This
information could be provisioned to the client when it is registered at the information could be provisioned to the client when it is registered at the
AS or published by the AS in a way that the client can query.</li> AS or published by the AS in a way that the client can query.</li>
<li>The AS informs the client about the token validity using the <li>The AS informs the client about the token validity using the
"expires_in" parameter in the Access Information.</li> <tt>expires_in</tt> parameter in the Access Information.</li>
</ul> </ul>
<t>A client that is not able to obtain information about the expiration of a <t>A client that is not able to obtain information about the expiration of a
token <bcp14>MUST NOT</bcp14> use this token.</t> token <bcp14>MUST NOT</bcp14> use this token.</t>
</section> </section>
</section> </section>
<!-- access token -->
</section> </section>
<!--Framework-->
<section anchor="security" numbered="true" toc="default"> <section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Security considerations applicable to authentication and authorization <t>Security considerations applicable to authentication and authorization
in RESTful environments provided in OAuth 2.0 <xref target="RFC6749" format="default"/> apply in RESTful environments provided in OAuth 2.0 <xref target="RFC6749" format="default"/> apply
to this work. Furthermore, <xref target="RFC6819" format="default"/> to this work. Furthermore, <xref target="RFC6819" format="default"/>
provides additional security considerations for OAuth, which apply to IoT provides additional security considerations for OAuth, which apply to IoT
deployments as well. If the introspection endpoint is used, deployments as well. If the introspection endpoint is used,
the security considerations from <xref target="RFC7662" format="default"/> also apply.</t> the security considerations from <xref target="RFC7662" format="default"/> also apply.</t>
<t>The following subsections address issues specific to this document and <t>The following subsections address issues specific to this document and
skipping to change at line 2493 skipping to change at line 2359
token that is still valid. Client-initiated revocation is specified token that is still valid. Client-initiated revocation is specified
in <xref target="RFC7009" format="default"/> for OAuth 2.0. Other revocation in <xref target="RFC7009" format="default"/> for OAuth 2.0. Other revocation
mechanisms mechanisms
are currently not specified, as the underlying assumption in OAuth are currently not specified, as the underlying assumption in OAuth
is that access tokens are issued with a relatively short lifetime. is that access tokens are issued with a relatively short lifetime.
This may not hold true for disconnected constrained devices needing This may not hold true for disconnected constrained devices needing
access tokens with relatively long lifetimes and would therefore access tokens with relatively long lifetimes and would therefore
necessitate further standardization work that is out of scope for necessitate further standardization work that is out of scope for
this document.</t> this document.</t>
</section> </section>
<!--token protection-->
<section anchor="commSec" numbered="true" toc="default"> <section anchor="commSec" numbered="true" toc="default">
<name>Communication Security</name> <name>Communication Security</name>
<t>Communication with the authorization server <bcp14>MUST</bcp14> use confidentiality <t>Communication with the authorization server <bcp14>MUST</bcp14> 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 server RS may obtain the proof-of-possession key from the authorization server
for use with a specific access token. Not using confidentiality for use with a specific access token. Not using confidentiality
protection exposes this secret (and the access token) to an eavesdropper, protection exposes this secret (and the access token) to an eavesdropper,
thereby completely negating proof-of-possession security. thereby completely negating proof-of-possession security.
The requirements for communication security of profiles are specified The requirements for communication security of profiles are specified
in <xref target="oauthProfile" format="default"/>.</t> in <xref target="oauthProfile" format="default"/>.</t>
<t>Additional protection for the access token can be applied by <t>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
<xref target="RFC8392" sectionFormat="of" section="5.1"/>. Such additional <xref target="RFC8392" sectionFormat="of" section="7.1"/>. Such additional
protection can be necessary protection can be necessary
if the token is later transferred over an insecure connection if the token is later transferred over an insecure connection
(e.g., when it is sent to the authz-info endpoint).</t> (e.g., when it is sent to the authz-info endpoint).</t>
<t>Care must be taken by developers to prevent leakage of the PoP <t>Care must be taken by developers to prevent leakage of the PoP
credentials (i.e., the private key or the symmetric key). An credentials (i.e., the private key or the symmetric key). An
adversary in possession of the PoP credentials bound to the access adversary in possession of the PoP credentials bound to the access
token will be able to impersonate the client. Be aware that this is a token will be able to impersonate the client. Be aware that this is a
real risk with many constrained environments, since adversaries may real risk with many constrained environments, since adversaries may
get physical access to the devices and can therefore use physical get physical access to the devices and can therefore use physical
extraction techniques to gain access to memory contents. This risk can extraction techniques to gain access to memory contents. This risk can
be mitigated to some extent by making sure that keys are refreshed be mitigated to some extent by making sure that keys are refreshed
frequently, by using software isolation techniques, and by using hardware frequently, by using software isolation techniques, and by using hardware
security.</t> security.</t>
</section> </section>
<!--communication security-->
<section anchor="keys" numbered="true" toc="default"> <section anchor="keys" numbered="true" toc="default">
<name>Long-Term Credentials</name> <name>Long-Term Credentials</name>
<t>Both the clients and RSs have long-term credentials that are used to <t>Both the clients and RSs have long-term credentials that are used to
secure communications and authenticate to the AS. These credentials secure communications and authenticate to the AS. These credentials
need to be protected against unauthorized access. In constrained need to be protected against unauthorized access. In constrained
devices deployed in publicly accessible places, such protection can devices deployed in publicly accessible places, such protection can
be difficult to achieve without specialized hardware (e.g., secure be difficult to achieve without specialized hardware (e.g., secure
key storage memory).</t> key storage memory).</t>
<t>If credentials are lost or compromised, the operator of the affected <t>If credentials are lost or compromised, the operator of the affected
skipping to change at line 2546 skipping to change at line 2410
compromise of other credentials not linked to that device; therefore, compromise of other credentials not linked to that device; therefore,
secret keys used for authentication <bcp14>MUST NOT</bcp14> be shared between more than secret keys used for authentication <bcp14>MUST NOT</bcp14> be shared between more than
two parties.</t> two parties.</t>
<t>Operators of the clients or RSs <bcp14>SHOULD</bcp14> have procedures in place to <t>Operators of the clients or RSs <bcp14>SHOULD</bcp14> have procedures in place to
replace credentials that are suspected to have been compromised or that replace credentials that are suspected to have been compromised or that
have been lost.</t> have been lost.</t>
<t>Operators also <bcp14>SHOULD</bcp14> have procedures for decommissioning devices <t>Operators also <bcp14>SHOULD</bcp14> have procedures for decommissioning devices
that include securely erasing credentials and other security-critical that include securely erasing credentials and other security-critical
material in the devices being decommissioned.</t> material in the devices being decommissioned.</t>
</section> </section>
<!--credential livecycle-->
<section anchor="unprotected-as-information" numbered="true" toc="default"> <section anchor="unprotected-as-information" numbered="true" toc="default">
<name>Unprotected AS Request Creation Hints</name> <name>Unprotected AS Request Creation Hints</name>
<t>Initially, no secure channel exists to protect the communication <t>Initially, no secure channel exists to protect the communication
between the C and RS. Thus, the C cannot determine if the "AS Request between the C and RS. Thus, the C cannot determine if the "AS Request
Creation Hints" contained in an unprotected response from the RS to an Creation Hints" contained in an unprotected response from the RS to an
unauthorized request (see <xref target="asInfo" format="default"/>) are unauthorized request (see <xref target="asInfo" format="default"/>) are
authentic. Therefore, the C authentic. Therefore, the C
<bcp14>MUST</bcp14> determine if an AS is authorized to provide <bcp14>MUST</bcp14> determine if an AS is authorized to provide
access access
skipping to change at line 2624 skipping to change at line 2487
</section> </section>
<section anchor="nonce" numbered="true" toc="default"> <section anchor="nonce" numbered="true" toc="default">
<name>Token Freshness and Expiration</name> <name>Token Freshness and Expiration</name>
<t>An RS that is offline faces the problem of clock drift. Since it <t>An RS that is offline faces the problem of clock drift. Since it
cannot synchronize its clock with the AS, it may be tricked cannot synchronize its clock with the AS, it may be tricked
into accepting old access tokens that are no longer valid or have been into accepting old access tokens that are no longer valid or have been
compromised. In order to prevent this, an RS may use the nonce-based compromised. In order to prevent this, an RS may use the nonce-based
mechanism (cnonce) defined in <xref target="asInfo" format="default"/> to ensure mechanism (cnonce) defined in <xref target="asInfo" format="default"/> to ensure
freshness of an Access Token subsequently presented to this RS.</t> freshness of an Access Token subsequently presented to this RS.</t>
<t>Another problem with clock drift is that evaluating the <t>Another problem with clock drift is that evaluating the
standard token expiration claim "exp" can give unpredictable results. standard token expiration claim <tt>exp</tt> can give unpredictable results.
</t> </t>
<t>Acceptable ranges of clock drift are highly dependent on the <t>Acceptable ranges of clock drift are highly dependent on the
concrete application. Important factors are how long access tokens concrete application. Important factors are how long access tokens
are valid and how critical timely expiration of the access token is.</t> are valid and how critical timely expiration of the access token is.</t>
<t>The expiration mechanism implemented by the "exi" claim, based on <t>The expiration mechanism implemented by the <tt>exi</tt> claim, based on
the first time the RS sees the token, was defined to provide a more the first time the RS sees the token, was defined to provide a more
predictable alternative. The "exi" approach has some drawbacks that predictable alternative. The <tt>exi</tt> approach has some drawbacks that
need to be considered: need to be considered:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>A malicious client may hold back tokens with the "exi" claim in <li>A malicious client may hold back tokens with the <tt>exi</tt> claim in
order to prolong their lifespan.</li> order to prolong their lifespan.</li>
<li> <li>
If an RS loses state (e.g., due to an unscheduled reboot), it If an RS loses state (e.g., due to an unscheduled reboot), it
may lose the current values of counters tracking the "exi" claims of may lose the current values of counters tracking the <tt>exi</tt> claims of
tokens it is storing.</li> tokens it is storing.</li>
</ul> </ul>
<t> <t>
The first drawback is inherent to the deployment scenario and the "exi" The first drawback is inherent to the deployment scenario and the <tt>exi</tt>
solution. It can therefore not be mitigated without requiring the solution. It can therefore not be mitigated without requiring the
RS be online at times. The second drawback can be mitigated by RS be online at times. The second drawback can be mitigated by
regularly storing the value of "exi" counters to persistent memory.</t> regularly storing the value of <tt>exi</tt> counters to persistent memory.</t>
</section> </section>
<section anchor="mixnmatch" numbered="true" toc="default"> <section anchor="mixnmatch" numbered="true" toc="default">
<name>Combining Profiles</name> <name>Combining Profiles</name>
<t>There may be use cases where different transport and security <t>There may be use cases where different transport and security
protocols are allowed for the different interactions, and, if that is protocols are allowed for the different interactions, and, if that is
not explicitly covered by an existing profile, it corresponds to not explicitly covered by an existing profile, it corresponds to
combining profiles into a new one. For example, a new profile could combining profiles into a new one. For example, a new profile could
specify that a previously defined MQTT-TLS profile is used between specify that a previously defined MQTT-TLS profile is used between
the client and the RS in combination with a previously defined the client and the RS in combination with a previously defined
CoAP-DTLS profile for interactions between the client and the AS. The CoAP-DTLS profile for interactions between the client and the AS. The
skipping to change at line 2693 skipping to change at line 2556
introspection by the RS.</t> introspection by the RS.</t>
<t>If the initial Unauthorized Resource Request message (see <xref target="rreq" format="default"/>) is used, the client <bcp14>MUST</bcp14> make sure that it is <t>If the initial Unauthorized Resource Request message (see <xref target="rreq" format="default"/>) is used, the client <bcp14>MUST</bcp14> make sure that it is
not sending sensitive content in this request. While GET and DELETE not sending sensitive content in this request. While GET and DELETE
requests only reveal the target URI of the resource, POST and PUT requests only reveal the target URI of the resource, POST and PUT
requests would reveal the whole payload of the intended operation.</t> requests would reveal the whole payload of the intended operation.</t>
<t>Since the client is not authenticated at the point when <t>Since the client is not authenticated at the point when
it is submitting an access token to the authz-info endpoint, it is submitting an access token to the authz-info endpoint,
attackers may be pretending to be a client and trying to trick attackers may be pretending to be a client and trying to trick
an RS to use an obsolete profile that in turn specifies a an RS to use an obsolete profile that in turn specifies a
vulnerable security mechanism via the authz-info endpoint. Such an vulnerable security mechanism via the authz-info endpoint. Such an
attack would require a valid access token containing an "ace_profile" attack would require a valid access token containing an <tt>ace_profile</tt>
claim requesting the use of said obsolete profile. Resource owners claim requesting the use of said obsolete profile. Resource owners
should update the configuration of their RSs to prevent them from should update the configuration of their RSs to prevent them from
using such obsolete profiles.</t> using such obsolete profiles.</t>
</section> </section>
<section anchor="audience" numbered="true" toc="default"> <section anchor="audience" numbered="true" toc="default">
<name>Identifying Audiences</name> <name>Identifying Audiences</name>
<t>The audience claim, as defined in <xref target="RFC7519" format="default"/>, <t>The <tt>aud</tt> claim, as defined in <xref target="RFC7519"
and the equivalent "audience" parameter from format="default"/>, and the equivalent <tt>audience</tt> parameter from
<xref target="RFC8693" format="default"/> are intentionally vague <xref target="RFC8693" format="default"/> are intentionally vague
on how to match the audience value to a specific RS. This is intended on how to match the audience value to a specific RS. This is intended
to allow application-specific semantics to be used. This section to allow application-specific semantics to be used. This section
attempts to give some general guidance for the use of audiences in attempts to give some general guidance for the use of audiences in
constrained environments.</t> constrained environments.</t>
<t>URLs are not a good way of identifying mobile devices that can <t>URLs are not a good way of identifying mobile devices that can
switch networks and thus be associated with new URLs. If the switch networks and thus be associated with new URLs. If the
audience represents a single RS and asymmetric keys are used, audience represents a single RS and asymmetric keys are used,
the RS can be uniquely identified by a hash of its public key. the RS can be uniquely identified by a hash of its public key.
If this approach is used, it is <bcp14>RECOMMENDED</bcp14> to apply the If this approach is used, it is <bcp14>RECOMMENDED</bcp14> to apply the
skipping to change at line 2724 skipping to change at line 2587
of a group identifier to an individual RS has to be provisioned to each RS of a group identifier to an individual RS has to be provisioned to each RS
before the group-audience is usable. Managing dynamic groups could be before the group-audience is usable. Managing dynamic groups could be
an issue if any RS is not always reachable when the groups' memberships an issue if any RS is not always reachable when the groups' memberships
change. Furthermore, issuing access tokens bound to symmetric change. Furthermore, issuing access tokens bound to symmetric
proof-of-possession keys that apply to a group-audience is problematic, proof-of-possession keys that apply to a group-audience is problematic,
as an RS that is in possession of the access token can impersonate the as an RS that is in possession of the access token can impersonate the
client towards the other RSs that are part of the group. It is client towards the other RSs that are part of the group. It is
therefore <bcp14>NOT RECOMMENDED</bcp14> to issue access tokens bound to a group therefore <bcp14>NOT RECOMMENDED</bcp14> to issue access tokens bound to a group
audience and symmetric proof-of possession keys.</t> audience and symmetric proof-of possession keys.</t>
<t>Even the client must be able to determine the correct values to put <t>Even the client must be able to determine the correct values to put
into the "audience" parameter in order to obtain a token for the into the <tt>audience</tt> parameter in order to obtain a token for the
intended RS. Errors in this process can lead to the client intended RS. Errors in this process can lead to the client
inadvertently obtaining a token for the wrong RS. The correct values inadvertently obtaining a token for the wrong RS. The correct values
for "audience" can either be provisioned to the client as part of its for <tt>audience</tt> can either be provisioned to the client as part of its
configuration or dynamically looked up by the client in some configuration or dynamically looked up by the client in some
directory. In the latter case, the integrity and correctness of the directory. In the latter case, the integrity and correctness of the
directory data must be assured. Note that the "audience" hint directory data must be assured. Note that the <tt>audience</tt> hint
provided by the RS as part of the "AS Request Creation Hints" (<xref provided by the RS as part of the "AS Request Creation Hints" (<xref
target="asInfo" format="default"/>) is not typically source authenticated and target="asInfo" format="default"/>) is not typically source authenticated and
integrity protected and should therefore not be treated a trusted value.</t> integrity protected and should therefore not be treated a trusted value.</t>
</section> </section>
<section anchor="introDos" numbered="true" toc="default"> <section anchor="introDos" numbered="true" toc="default">
<name>Denial of Service Against or with Introspection</name> <name>Denial of Service Against or with Introspection</name>
<t> <t>
The optional introspection mechanism provided by OAuth and supported The optional introspection mechanism provided by OAuth and supported
in the ACE framework allows for two types of attacks that need in the ACE framework allows for two types of attacks that need
to be considered by implementers.</t> to be considered by implementers.</t>
skipping to change at line 2792 skipping to change at line 2655
not a machine-to-machine interaction).</t> not a machine-to-machine interaction).</t>
<t>Clients using asymmetric keys for proof of possession should be aware <t>Clients using asymmetric keys for proof of possession should be aware
of the consequences of using the same key pair for proof of possession of the consequences of using the same key pair for proof of possession
towards different RSs. A set of colluding RSs or an attacker able to towards different RSs. A set of colluding RSs or an attacker able to
obtain the access tokens will be able to link the requests or even obtain the access tokens will be able to link the requests or even
to determine the client's identity.</t> to determine the client's identity.</t>
<t>An unprotected response to an unauthorized request (see <t>An unprotected response to an unauthorized request (see
<xref target="asInfo" format="default"/>) may disclose information about the RS <xref target="asInfo" format="default"/>) may disclose information about the RS
and/or its and/or its
existing relationship with the C. It is advisable to include as little existing relationship with the C. It is advisable to include as little
information as possible in an unencrypted response. Even the absolute URI of the AS may reveal sensitive information about the service that the RS provides. Developers must ensure that the RS does not disclose information that has an impact on the privacy of the stakeholders in the "AS Request Creation Hints". They may choose to use a different mechanism for the discovery of the AS if necessary. If means of encrypting information as possible in an unencrypted response. Even the absolute URI of the AS
may reveal sensitive information about the service that the RS provides. Developers
must ensure that the RS does not disclose information that has an impact on the
privacy of the stakeholders in the "AS Request Creation Hints". They may choose to
use a different mechanism for the discovery of the AS if necessary. If means of
encrypting
communication between the C and RS already exist, more detailed information communication between the C and RS already exist, more detailed information
may be included with an error response to provide the C with sufficient may be included with an error response to provide the C with sufficient
information to react on that particular error.</t> information to react on that particular error.</t>
</section> </section>
<section anchor="iana" numbered="true" toc="default"> <section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<!--[rfced] May the titles of these subsections be made consistent?
The original is inconsistent about including the word "Registration" or
"Registry" vs. no additional word. Is the following option acceptable
(no additional word)? (The title of 8.15 was changed to singular because
it contains one registration.)
Original:
8. IANA Considerations
8.1. ACE Authorization Server Request Creation Hints
8.2. CoRE Resource Type Registry
8.3. OAuth Extensions Error Registration
8.4. OAuth Error Code CBOR Mappings Registry
8.5. OAuth Grant Type CBOR Mappings
8.6. OAuth Access Token Types
8.7. OAuth Access Token Type CBOR Mappings
8.7.1. Initial Registry Contents
8.8. ACE Profile Registry
8.9. OAuth Parameter Registration
8.10. OAuth Parameters CBOR Mappings Registry
8.11. OAuth Introspection Response Parameter Registration
8.12. OAuth Token Introspection Response CBOR Mappings
Registry
8.13. JSON Web Token Claims
8.14. CBOR Web Token Claims
8.15. Media Type Registrations
8.16. CoAP Content-Format Registry
Perhaps:
8. IANA Considerations
8.1. ACE Authorization Server Request Creation Hints
8.2. CoRE Resource Types
8.3. OAuth Extensions Errors
8.4. OAuth Error Code CBOR Mappings
8.5. OAuth Grant Type CBOR Mappings
8.6. OAuth Access Token Types
8.7. OAuth Access Token Type CBOR Mappings
8.7.1. Initial Registry Contents
8.8. ACE Profiles
8.9. OAuth Parameters
8.10. OAuth Parameters CBOR Mappings
8.11. OAuth Introspection Response Parameters
8.12. OAuth Token Introspection Response CBOR Mappings
8.13. JSON Web Token Claims
8.14. CBOR Web Token Claims
8.15. Media Type Registration
8.16. CoAP Content-Formats
<t>This document creates several registries with a registration policy of <t>This document creates several registries with a registration policy of
Expert Review; guidelines to the experts are given in Expert Review; guidelines to the experts are given in
<xref target="IANAinstructions" format="default"/>.</t> <xref target="IANAinstructions" format="default"/>.</t>
<section anchor="IANAASInformation" numbered="true" toc="default"> <section anchor="IANAASInformation" numbered="true" toc="default">
<name>ACE Authorization Server Request Creation Hints</name> <name>ACE Authorization Server Request Creation Hints</name>
<t>This specification establishes the IANA "ACE Authorization Server <t>This specification establishes the IANA "ACE Authorization Server
Request Creation Hints" registry.</t> Request Creation Hints" registry.</t>
<t>The columns of the registry are:</t> <t>The columns of the registry are:</t>
<dl newline="false"> <dl newline="false">
<dt>Name:</dt> <dt>Name:</dt>
skipping to change at line 2878 skipping to change at line 2697
<dd>The CBOR data types allowable for the values of <dd>The CBOR data types allowable for the values of
this parameter.</dd> this parameter.</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd>This contains a pointer to the public <dd>This contains a pointer to the public
specification of the Request Creation Hint abbreviation, if one specification of the Request Creation Hint abbreviation, if one
exists.</dd> exists.</dd>
</dl> </dl>
<t>This registry has been initially populated by the values in <xref target="table_asinfo"/>. The Reference column for all of these entries is this document.</t> <t>This registry has been initially populated by the values in <xref target="table_asinfo"/>. The Reference column for all of these entries is this document.</t>
</section> </section>
<section anchor="IANAcoreRT" numbered="true" toc="default"> <section anchor="IANAcoreRT" numbered="true" toc="default">
<name>CoRE Resource Type Registry</name> <name>CoRE Resource Types</name>
<t>IANA has registered a new Resource Type (rt=) Link Target <t>IANA has registered a new Resource Type (rt=) Link Target
Attribute in the "Resource Type (rt=) Link Target Attribute Values" Attribute in the "Resource Type (rt=) Link Target Attribute Values"
subregistry under the "Constrained RESTful Environments (CoRE) subregistry under the "Constrained RESTful Environments (CoRE)
Parameters" <xref target="IANA.CoreParameters" format="default"/> registry:</t> Parameters" <xref target="IANA.CoreParameters" format="default"/> registry:</t>
<dl newline="false" spacing="compact"> <dl newline="false" spacing="compact">
<dt>Value:</dt> <dt>Value:</dt>
<dd><tt>ace.ai</tt></dd> <dd><tt>ace.ai</tt></dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd>ACE-OAuth authz-info endpoint resource.</dd> <dd>ACE-OAuth authz-info endpoint resource.</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd>RFC 9200</dd> <dd>RFC 9200</dd>
</dl> </dl>
<t>Specific ACE-OAuth profiles can use this common resource type for <t>Specific ACE-OAuth profiles can use this common resource type for
defining their profile-specific discovery processes.</t> defining their profile-specific discovery processes.</t>
</section> </section>
<section anchor="IANAOAuthErrorCodes" numbered="true" toc="default"> <section anchor="IANAOAuthErrorCodes" numbered="true" toc="default">
<name>OAuth Extensions Error Registration</name> <name>OAuth Extensions Errors</name>
<t>This specification registers the following error values in the OAuth <t>This specification registers the following error values in the OAuth
Extensions Error registry Extensions Error registry
<xref target="IANA.OAuthExtensionsErrorRegistry" format="default"/>.</t> <xref target="IANA.OAuthExtensionsErrorRegistry" format="default"/>.</t>
<dl newline="false" spacing="compact"> <dl newline="false" spacing="compact">
<dt>Error name:</dt> <dt>Error name:</dt>
<dd><tt>unsupported_pop_key</tt></dd> <dd><tt>unsupported_pop_key</tt></dd>
<dt>Error usage location:</dt> <dt>Error usage location:</dt>
<dd>token error response</dd> <dd>token error response</dd>
<dt>Related protocol extension:</dt> <dt>Related protocol extension:</dt>
<dd>RFC 9200</dd> <dd>RFC 9200</dd>
skipping to change at line 2925 skipping to change at line 2744
<dd>token error response</dd> <dd>token error response</dd>
<dt>Related protocol extension:</dt> <dt>Related protocol extension:</dt>
<dd>RFC 9200</dd> <dd>RFC 9200</dd>
<dt>Change Controller:</dt> <dt>Change Controller:</dt>
<dd>IETF</dd> <dd>IETF</dd>
<dt>Specification document(s):</dt> <dt>Specification document(s):</dt>
<dd><xref target="errorsToken" format="default"/> of RFC 9200</dd> <dd><xref target="errorsToken" format="default"/> of RFC 9200</dd>
</dl> </dl>
</section> </section>
<section anchor="IANAErrorCBORMappings" numbered="true" toc="default"> <section anchor="IANAErrorCBORMappings" numbered="true" toc="default">
<name>OAuth Error Code CBOR Mappings Registry</name> <name>OAuth Error Code CBOR Mappings</name>
<t>This specification establishes the IANA "OAuth Error Code <t>This specification establishes the IANA "OAuth Error Code
CBOR Mappings" registry.</t> CBOR Mappings" registry.</t>
<!--[rfced] In Sections 8.1, 8.4, 8.5, 8.7, 8.8, 8.10, and 8.12, the original
contained redundant text regarding the registration policies. FYI, the
detailed text regarding the ranges of the registration policies remains,
whereas the preceding sentence ("The registry has been created to use the ...")
has been removed.
<t>The columns of the registry are:</t> <t>The columns of the registry are:</t>
<dl newline="false"> <dl newline="false">
<dt>Name:</dt> <dt>Name:</dt>
<dd>The OAuth Error Code name, refers to the name in <dd>The OAuth Error Code name, refers to the name in
<xref target="RFC6749" sectionFormat="of" section="5.2"/>, e.g., <xref target="RFC6749" sectionFormat="of" section="5.2"/>, e.g.,
"invalid_request".</dd> "invalid_request".</dd>
<dt>CBOR Value:</dt> <dt>CBOR Value:</dt>
<dd>CBOR abbreviation for this error code. <dd>CBOR abbreviation for this error code.
Integer values less than -65536 are marked as Private Use; all other values use Integer values less than -65536 are marked as Private Use; all other values use
the registration policy Expert Review <xref target="RFC8126" format="default"/>.</dd> the registration policy Expert Review <xref target="RFC8126" format="default"/>.</dd>
skipping to change at line 2988 skipping to change at line 2801
</section> </section>
<section anchor="IANAOAuthTokenType" numbered="true" toc="default"> <section anchor="IANAOAuthTokenType" numbered="true" toc="default">
<name>OAuth Access Token Types</name> <name>OAuth Access Token Types</name>
<t>This section registers the following new token type in the <t>This section registers the following new token type in the
"OAuth Access Token Types" registry <xref target="IANA.OAuthAccessTokenTypes" format="default"/>.</t> "OAuth Access Token Types" registry <xref target="IANA.OAuthAccessTokenTypes" format="default"/>.</t>
<dl newline="false" spacing="compact"> <dl newline="false" spacing="compact">
<dt>Type name:</dt> <dt>Type name:</dt>
<dd><tt>PoP</tt></dd> <dd><tt>PoP</tt></dd>
<dt>Additional Token Endpoint Response Parameters:</dt> <dt>Additional Token Endpoint Response Parameters:</dt>
<dd>"cnf", "rs_cnf" (see <xref target="RFC8747" sectionFormat="of" section="3.1"/> <xref target="RFC9201" <dd><tt>cnf</tt>, <tt>rs_cnf</tt> (see <xref target="RFC8747" sectionFormat="of" section="3.1"/> <xref target="RFC9201"
sectionFormat="of" section="3.2"/>).</dd> sectionFormat="of" section="3.2"/>).</dd>
<dt>HTTP Authentication Scheme(s):</dt> <dt>HTTP Authentication Scheme(s):</dt>
<dd>N/A</dd> <dd>N/A</dd>
<dt>Change Controller:</dt> <dt>Change Controller:</dt>
<dd>IETF</dd> <dd>IETF</dd>
<dt>Specification document(s):</dt> <dt>Specification document(s):</dt>
<dd>RFC 9200</dd> <dd>RFC 9200</dd>
</dl> </dl>
</section> </section>
<section anchor="IANATokenTypeMappings" numbered="true" toc="default"> <section anchor="IANATokenTypeMappings" numbered="true" toc="default">
skipping to change at line 3043 skipping to change at line 2856
<dt>Value:</dt> <dt>Value:</dt>
<dd>2</dd> <dd>2</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd>RFC 9200</dd> <dd>RFC 9200</dd>
<dt>Original Specification:</dt> <dt>Original Specification:</dt>
<dd>RFC 9200</dd> <dd>RFC 9200</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="IANAProfile" numbered="true" toc="default"> <section anchor="IANAProfile" numbered="true" toc="default">
<name>ACE Profile Registry</name> <name>ACE Profiles</name>
<t>This specification establishes the IANA "ACE Profile" registry. </t> <t>This specification establishes the IANA "ACE Profile" registry. </t>
<t>The columns of this registry are:</t> <t>The columns of this registry are:</t>
<dl newline="false"> <dl newline="false">
<dt>Name:</dt> <dt>Name:</dt>
<dd> The name of the profile to be used as the value of <dd> The name of the profile to be used as the value of
the profile attribute.</dd> the profile attribute.</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> Text giving an overview of the profile and <dd> Text giving an overview of the profile and
the context it is developed for.</dd> the context it is developed for.</dd>
<dt>CBOR Value:</dt> <dt>CBOR Value:</dt>
skipping to change at line 3066 skipping to change at line 2879
designated as Standards Action. Integer values from -65536 to -257 and from 256 designated as Standards Action. Integer values from -65536 to -257 and from 256
to 65535 are designated as Specification Required. Integer values greater to 65535 are designated as Specification Required. Integer values greater
than 65535 are designated as Expert Review. Integer values less than than 65535 are designated as Expert Review. Integer values less than
-65536 are marked as Private Use.</dd> -65536 are marked as Private Use.</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd>This contains a pointer to the public <dd>This contains a pointer to the public
specification of the profile abbreviation, if one exists.</dd> specification of the profile abbreviation, if one exists.</dd>
</dl> </dl>
</section> </section>
<section anchor="IANAOAuthParameter" numbered="true" toc="default"> <section anchor="IANAOAuthParameter" numbered="true" toc="default">
<name>OAuth Parameter Registration</name> <name>OAuth Parameters</name>
<t>This specification registers the following parameter in the "OAuth <t>This specification registers the following parameter in the "OAuth
Parameters" registry <xref target="IANA.OAuthParameters" format="default"/>:</t> Parameters" registry <xref target="IANA.OAuthParameters" format="default"/>:</t>
<dl newline="false" spacing="compact"> <dl newline="false" spacing="compact">
<dt>Name:</dt> <dt>Name:</dt>
<dd><tt>ace_profile</tt></dd> <dd><tt>ace_profile</tt></dd>
<dt>Parameter Usage Location:</dt> <dt>Parameter Usage Location:</dt>
<dd>token response</dd> <dd>token response</dd>
<dt>Change Controller:</dt> <dt>Change Controller:</dt>
<dd>IETF</dd> <dd>IETF</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd>Sections <xref target="tokenResponse" format="counter"/> and <dd>Sections <xref target="tokenResponse" format="counter"/> and
<xref target="paramProfile" format="counter"/> of RFC 9200</dd> <xref target="paramProfile" format="counter"/> of RFC 9200</dd>
</dl> </dl>
</section> </section>
<section anchor="IANAOAuthParameterMappingsRegistry" numbered="true" toc="default"> <section anchor="IANAOAuthParameterMappingsRegistry" numbered="true" toc="default">
<name>OAuth Parameters CBOR Mappings Registry</name> <name>OAuth Parameters CBOR Mappings</name>
<t>This specification establishes the IANA "OAuth Parameters CBOR Mappings" <t>This specification establishes the IANA "OAuth Parameters CBOR Mappings"
registry.</t> registry.</t>
<t>The columns of this registry are:</t> <t>The columns of this registry are:</t>
<dl newline="false"> <dl newline="false">
<dt>Name:</dt> <dt>Name:</dt>
<dd>The OAuth Parameter name, refers to the name in <dd>The OAuth Parameter name, refers to the name in
the OAuth parameter registry, e.g., "client_id".</dd> the OAuth parameter registry, e.g., <tt>client_id</tt>.</dd>
<dt>CBOR Key:</dt> <dt>CBOR Key:</dt>
<dd>CBOR map key for this parameter. Integer <dd>CBOR map key for this parameter. Integer
values less than -65536 are marked as Private Use; all other values use values less than -65536 are marked as Private Use; all other values use
the registration policy Expert Review <xref target="RFC8126" format="default"/>.</dd> the registration policy Expert Review <xref target="RFC8126" format="default"/>.</dd>
<dt>Value Type:</dt> <dt>Value Type:</dt>
<dd>The allowable CBOR data types for values <dd>The allowable CBOR data types for values
of this parameter.</dd> of this parameter.</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd>This contains a pointer to the public <dd>This contains a pointer to the public
specification of the OAuth parameter abbreviation, if one exists.</dd> specification of the OAuth parameter abbreviation, if one exists.</dd>
<dt>Original Specification</dt> <dt>Original Specification</dt>
<dd>This contains a pointer to the public <dd>This contains a pointer to the public
specification of the OAuth parameter, if one exists.</dd> specification of the OAuth parameter, if one exists.</dd>
</dl> </dl>
<t>This registry has been initially populated by the values in <xref target="table_cborTokenParameters"/>. The Reference column for all of these entries is this document.</t> <t>This registry has been initially populated by the values in <xref target="table_cborTokenParameters"/>. The Reference column for all of these entries is this document.</t>
</section> </section>
<section anchor="IANAOAuthIntrospectionResponseParameterRegistration" numbered="true" toc="default"> <section anchor="IANAOAuthIntrospectionResponseParameterRegistration" numbered="true" toc="default">
<name>OAuth Introspection Response Parameter Registration</name> <name>OAuth Introspection Response Parameters</name>
<t>This specification registers the following parameters in the OAuth <t>This specification registers the following parameters in the OAuth
Token Introspection Response registry <xref target="IANA.TokenIntrospectionResponse" format="default"/>.</t> Token Introspection Response registry <xref target="IANA.TokenIntrospectionResponse" format="default"/>.</t>
<dl newline="false" spacing="compact"> <dl newline="false" spacing="compact">
<dt>Name:</dt> <dt>Name:</dt>
<dd><tt>ace_profile</tt></dd> <dd><tt>ace_profile</tt></dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd>The ACE profile used between the client and RS.</dd> <dd>The ACE profile used between the client and RS.</dd>
<dt>Change Controller:</dt> <dt>Change Controller:</dt>
<dd>IETF</dd> <dd>IETF</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
skipping to change at line 3160 skipping to change at line 2973
from the time the RS first sees it. Used to implement a weaker form of from the time the RS first sees it. Used to implement a weaker form of
token expiration for devices that cannot synchronize their internal token expiration for devices that cannot synchronize their internal
clocks.</dd> clocks.</dd>
<dt>Change Controller:</dt> <dt>Change Controller:</dt>
<dd>IETF</dd> <dd>IETF</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd><xref target="introRes" format="default"/> of RFC 9200</dd> <dd><xref target="introRes" format="default"/> of RFC 9200</dd>
</dl> </dl>
</section> </section>
<section anchor="IANAIntrospectionEndpointCBORMappingsRegistry" numbered="true" toc="default"> <section anchor="IANAIntrospectionEndpointCBORMappingsRegistry" numbered="true" toc="default">
<name>OAuth Token Introspection Response CBOR Mappings Registry</name> <name>OAuth Token Introspection Response CBOR Mappings</name>
<t>This specification establishes the IANA "OAuth Token Introspection <t>This specification establishes the IANA "OAuth Token Introspection
Response CBOR Mappings" registry.</t> Response CBOR Mappings" registry.</t>
<t>The columns of this registry are:</t> <t>The columns of this registry are:</t>
<dl newline="false"> <dl newline="false">
<dt>Name:</dt> <dt>Name:</dt>
<dd>The OAuth Parameter name, refers to the name in <dd>The OAuth Parameter name, refers to the name in
the OAuth parameter registry, e.g., "client_id".</dd> the OAuth parameter registry, e.g., <tt>client_id</tt>.</dd>
<dt>CBOR Key:</dt> <dt>CBOR Key:</dt>
<dd>CBOR map key for this parameter. Integer <dd>CBOR map key for this parameter. Integer
values less than -65536 are marked as Private Use; all other values use values less than -65536 are marked as Private Use; all other values use
the registration policy Expert Review <xref target="RFC8126" format="default"/>.</dd> the registration policy Expert Review <xref target="RFC8126" format="default"/>.</dd>
<dt>Value Type:</dt> <dt>Value Type:</dt>
<dd>The allowable CBOR data types for values <dd>The allowable CBOR data types for values
of this parameter.</dd> of this parameter.</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd>This contains a pointer to the public <dd>This contains a pointer to the public
specification of the introspection response parameter abbreviation, if specification of the introspection response parameter abbreviation, if
skipping to change at line 3278 skipping to change at line 3091
<dt>Claim Name:</dt> <dt>Claim Name:</dt>
<dd><tt>exi</tt></dd> <dd><tt>exi</tt></dd>
<dt>Claim Description:</dt> <dt>Claim Description:</dt>
<dd>The expiration time of a token measured from when it was received at the RS <dd>The expiration time of a token measured from when it was received at the RS
in seconds.</dd> in seconds.</dd>
<dt>JWT Claim Name:</dt> <dt>JWT Claim Name:</dt>
<dd>exi</dd> <dd>exi</dd>
<dt>Claim Key:</dt> <dt>Claim Key:</dt>
<dd>40</dd> <dd>40</dd>
<dt>Claim Value Type(s):</dt> <dt>Claim Value Type(s):</dt>
<dd>integer</dd> <dd>unsigned integer</dd>
<dt>Change Controller:</dt> <dt>Change Controller:</dt>
<dd>IETF</dd> <dd>IETF</dd>
<dt>Specification Document(s):</dt> <dt>Specification Document(s):</dt>
<dd><xref target="tokenExpiration" format="default"/> of RFC 9200</dd> <dd><xref target="tokenExpiration" format="default"/> of RFC 9200</dd>
</dl> </dl>
<dl newline="false" spacing="compact"> <dl newline="false" spacing="compact">
<dt>Claim Name:</dt> <dt>Claim Name:</dt>
<dd><tt>scope</tt></dd> <dd><tt>scope</tt></dd>
<dt>Claim Description:</dt> <dt>Claim Description:</dt>
<dd>The scope of an access token, as defined in <xref target="RFC6749" <dd>The scope of an access token, as defined in <xref target="RFC6749"
skipping to change at line 3347 skipping to change at line 3160
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Restrictions on usage:</dt> <dt>Restrictions on usage:</dt>
<dd>none</dd> <dd>none</dd>
<dt>Author:</dt> <dt>Author:</dt>
<dd>Ludwig Seitz &lt;ludwig.seitz@combitech.se&gt;</dd> <dd>Ludwig Seitz &lt;ludwig.seitz@combitech.se&gt;</dd>
<dt>Change controller:</dt> <dt>Change controller:</dt>
<dd>IETF</dd> <dd>IETF</dd>
</dl> </dl>
</section> </section>
<section anchor="IANAcoapContentFormat" numbered="true" toc="default"> <section anchor="IANAcoapContentFormat" numbered="true" toc="default">
<name>CoAP Content-Format Registry</name> <name>CoAP Content-Formats</name>
<t>The following entry has been registered in the "CoAP <t>The following entry has been registered in the "CoAP
Content-Formats" registry:</t> Content-Formats" registry:</t>
<dl newline="false" spacing="compact"> <dl newline="false" spacing="compact">
<dt>Media Type:</dt> <dt>Media Type:</dt>
<dd>application/ace+cbor</dd> <dd>application/ace+cbor</dd>
<dt>Encoding:</dt> <dt>Encoding:</dt>
<dd>-</dd> <dd>-</dd>
<dt>ID:</dt> <dt>ID:</dt>
<dd>19</dd> <dd>19</dd>
<dt>Reference:</dt> <dt>Reference:</dt>
skipping to change at line 3400 skipping to change at line 3213
<li>Since a high degree of overlap is expected between these registries <li>Since a high degree of overlap is expected between these registries
and the contents of the OAuth parameters <xref target="IANA.OAuthParameters" format="default"/> registries, experts should require new and the contents of the OAuth parameters <xref target="IANA.OAuthParameters" format="default"/> registries, experts should require new
registrations to maintain alignment with parameters from OAuth that have registrations to maintain alignment with parameters from OAuth that have
comparable functionality. Deviation from this alignment should only comparable functionality. Deviation from this alignment should only
be allowed if there are functional differences that are motivated by be allowed if there are functional differences that are motivated by
the use case and that cannot be easily or efficiently addressed by the use case and that cannot be easily or efficiently addressed by
comparable OAuth parameters.</li> comparable OAuth parameters.</li>
</ul> </ul>
</section> </section>
</section> </section>
<!-- IANA considerations -->
<!-- Possibly a 'Contributors' section ... -->
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<displayreference target="I-D.erdtman-oauth-rpcc" to="OAUTH-RPCC"/> <displayreference target="I-D.erdtman-oauth-rpcc" to="OAUTH-RPCC"/>
<displayreference target="I-D.gerdes-ace-dcaf-authorize" to="DCAF"/> <displayreference target="I-D.gerdes-ace-dcaf-authorize" to="DCAF"/>
<displayreference target="I-D.ietf-oauth-pop-key-distribution" to="POP-KEY-DIST"/> <displayreference target="I-D.ietf-oauth-pop-key-distribution" to="POP-KEY-DIST"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6920.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6920.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
skipping to change at line 3552 skipping to change at line 3359
<title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title> <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'> <author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization /> <organization />
</author> </author>
<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'> <author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
<organization /> <organization />
</author> </author>
<author initials='N' surname='Modadugu' fullname='Nagendra Modadugu'> <author initials='N' surname='Modadugu' fullname='Nagendra Modadugu'>
<organization /> <organization />
</author> </author>
<date year="2022" month="March" /><!-- TBD --> <date year="2022" month="March" />
</front> </front>
<seriesInfo name="RFC" value="9147"/> <seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/> <seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference> </reference>
<!-- [I-D.erdtman-ace-rpcc] Replaced by draft-erdtman-oauth-rpcc [I-D.erdtman-oauth-rpcc]; IESG state Expired --> <!-- [I-D.erdtman-ace-rpcc] Replaced by draft-erdtman-oauth-rpcc [I-D.erdtman-oauth-rpcc]; IESG state Expired -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.erdtman-oauth-rpcc-00.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.erdtman-oauth-rpcc-00.xml"/>
<!-- [I-D.ietf-quic-transport] Published as RFC 9000 --> <!-- [I-D.ietf-quic-transport] Published as RFC 9000 -->
skipping to change at line 3614 skipping to change at line 3421
</author> </author>
<author initials='L' surname='Seitz' fullname='Ludwig Seitz'> <author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
<organization /> <organization />
</author> </author>
<date year="2022" month="March" /> <date year="2022" month="March" />
</front> </front>
<seriesInfo name="RFC" value="9202"/> <seriesInfo name="RFC" value="9202"/>
<seriesInfo name="DOI" value="10.17487/RFC9202"/> <seriesInfo name="DOI" value="10.17487/RFC9202"/>
</reference> </reference>
<!--[rfced] FYI, we have added the following documents to the
Informative References, as they appear in the Acknowledgments. Please
let us know if you prefer otherwise.
[DCAF] Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP
Authentication and Authorization Framework (DCAF)", Work
in Progress, Internet-Draft, draft-gerdes-ace-dcaf-
authorize-04, 19 October 2015,
<https://datatracker.ietf.org/doc/html/draft-gerdes-ace-
dcaf-authorize-04>.
[POP-KEY-DIST]
Bradley, J., Hunt, P., Jones, M. B., Tschofenig, H., and
M. Meszaros, "OAuth 2.0 Proof-of-Possession: Authorization
Server to Client Key Distribution", Work in Progress,
Internet-Draft, draft-ietf-oauth-pop-key-distribution-07,
27 March 2019, <https://datatracker.ietf.org/doc/html/
draft-ietf-oauth-pop-key-distribution-07>.
<!-- [I-D.ietf-oauth-pop-key-distribution] IESG state Expired <!-- [I-D.ietf-oauth-pop-key-distribution] IESG state Expired
--> -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-oauth-pop-key-distribution-07.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-oauth-pop-key-distribution-07.xml"/>
<!-- [I-D.gerdes-ace-dcaf-authorize] IESG state Expired <!-- [I-D.gerdes-ace-dcaf-authorize] IESG state Expired
--> -->
<xi:include <xi:include
href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.gerdes-ace-dcaf-authorize-04.xml"/> href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.gerdes-ace-dcaf-authorize-04.xml"/>
<reference anchor="Margi10impact"> <reference anchor="Margi10impact">
skipping to change at line 3818 skipping to change at line 3605
concerning the RS that the AS returns to the client in an access concerning the RS that the AS returns to the client in an access
token response (see <xref target="tokenResponse" format="default"/>). This token response (see <xref target="tokenResponse" format="default"/>). This
aims at aims at
enabling scenarios where a powerful client supporting multiple enabling scenarios where a powerful client supporting multiple
profiles needs to interact with an RS for which it does not know the profiles needs to interact with an RS for which it does not know the
supported profiles and the raw public key. supported profiles and the raw public key.
</dd> </dd>
<dt>Proof of Possession:</dt> <dt>Proof of Possession:</dt>
<dd> <dd>
This framework makes use of proof-of-possession tokens, using This framework makes use of proof-of-possession tokens, using
the "cnf" claim <xref target="RFC8747" format="default"/>. A request the <tt>cnf</tt> claim <xref target="RFC8747" format="default"/>. A request
parameter "cnf" and a Response parameter "cnf", both having a parameter <tt>cnf</tt> and a Response parameter <tt>cnf</tt>, both having a
value space semantically and syntactically identical to the "cnf" value space semantically and syntactically identical to the <tt>cnf</tt>
claim, are defined for the token endpoint to allow requesting and claim, are defined for the token endpoint to allow requesting and
stating confirmation keys. This aims at making token theft harder. stating confirmation keys. This aims at making token theft harder.
Token theft is specifically relevant in constrained use cases, as Token theft is specifically relevant in constrained use cases, as
communication often passes through middleboxes, which could be able communication often passes through middleboxes, which could be able
to steal bearer tokens and use them to gain unauthorized access. to steal bearer tokens and use them to gain unauthorized access.
</dd> </dd>
<dt>Authz-Info endpoint:</dt> <dt>Authz-Info endpoint:</dt>
<dd> <dd>
This framework introduces a new way of providing access tokens This framework introduces a new way of providing access tokens
to an RS by exposing an authz-info endpoint to which access tokens to an RS by exposing an authz-info endpoint to which access tokens
skipping to change at line 4021 skipping to change at line 3808
</li> </li>
<li>Send a response following the agreed upon communication <li>Send a response following the agreed upon communication
security mechanism(s).</li> security mechanism(s).</li>
<li>Safely store credentials, such as raw public keys, for <li>Safely store credentials, such as raw public keys, for
authentication or proof-of-possession keys linked to access authentication or proof-of-possession keys linked to access
tokens.</li> tokens.</li>
</ul> </ul>
</dd> </dd>
</dl> </dl>
</section> </section>
<!-- ***************************************************** -->
<section anchor="app_profileRequirements" numbered="true" toc="default"> <section anchor="app_profileRequirements" numbered="true" toc="default">
<name>Requirements on Profiles</name> <name>Requirements on Profiles</name>
<t>This section lists the requirements on profiles of this framework <t>This section lists the requirements on profiles of this framework
for the convenience of profile designers.</t> for the convenience of profile designers.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Optionally, define new methods for the client to discover the <li>Optionally, define new methods for the client to discover the
necessary permissions and AS for accessing a resource different from necessary permissions and AS for accessing a resource different from
the one proposed in Sections <xref target="asDiscovery" format="counter"/> and <xref the one proposed in Sections <xref target="asDiscovery" format="counter"/> and <xref
target="specs" format="counter"/></li> target="specs" format="counter"/></li>
<li>Optionally, specify new grant types <li>Optionally, specify new grant types
skipping to change at line 4088 skipping to change at line 3875
<li>The key types (e.g., pre-shared symmetric key, raw public key, <li>The key types (e.g., pre-shared symmetric key, raw public key,
key length, and other key parameters) that the client or RS supports.</li> key length, and other key parameters) that the client or RS supports.</li>
<li>The types of access tokens the RS supports (e.g., CWT).</li> <li>The types of access tokens the RS supports (e.g., CWT).</li>
<li>If the RS supports CWTs, the COSE parameters for the crypto wrapper <li>If the RS supports CWTs, the COSE parameters for the crypto wrapper
(e.g., algorithm, key-wrap algorithm, and key-length) that the RS supports.</li> (e.g., algorithm, key-wrap algorithm, and key-length) that the RS supports.</li>
<li>The expiration time for access tokens issued to this RS <li>The expiration time for access tokens issued to this RS
(unless the RS accepts a default time chosen by the AS).</li> (unless the RS accepts a default time chosen by the AS).</li>
<li>The symmetric key shared between the client and AS (if any).</li> <li>The symmetric key shared between the client and AS (if any).</li>
<li>The symmetric key shared between the RS and AS (if any).</li> <li>The symmetric key shared between the RS and AS (if any).</li>
<li>The raw public key of the client or RS (if any).</li> <li>The raw public key of the client or RS (if any).</li>
<li>Whether the RS has synchronized time (and thus is able to use the 'exp' <li>Whether the RS has synchronized time (and thus is able to use the <tt>exp</tt>
claim) or not.</li> claim) or not.</li>
</ul> </ul>
</section> </section>
<section anchor="app_diffOAuth" numbered="true" toc="default"> <section anchor="app_diffOAuth" numbered="true" toc="default">
<name>Differences to OAuth 2.0</name> <name>Differences to OAuth 2.0</name>
<t>This document adapts OAuth 2.0 to be suitable for constrained environments. <t>This document adapts OAuth 2.0 to be suitable for constrained environments.
This section lists the main differences from the normative requirements of This section lists the main differences from the normative requirements of
OAuth 2.0.</t> OAuth 2.0.</t>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>Use of TLS</dt> <dt>Use of TLS</dt>
<dd>OAuth 2.0 requires the use of TLS to protect the <dd>OAuth 2.0 requires the use of TLS to protect the
communication between the AS and client when requesting an access token, communication between the AS and client when requesting an access token,
between the client and RS when accessing a resource, and between the AS and RS if between the client and RS when accessing a resource, and between the AS and RS if
introspection is used. This framework requires similar security introspection is used. This framework requires similar security
properties but does not require that they be realized with TLS. properties but does not require that they be realized with TLS.
See <xref target="oauthProfile" format="default"/>.</dd> See <xref target="oauthProfile" format="default"/>.</dd>
<dt>Cardinality of "grant_type" parameter</dt> <dt>Cardinality of <tt>grant_type</tt> parameter</dt>
<dd>In client-to-AS requests <dd>In client-to-AS requests
using OAuth 2.0, the "grant_type" parameter is required (per using OAuth 2.0, the <tt>grant_type</tt> parameter is required (per
<xref target="RFC6749" format="default"/>). In this framework, this parameter <xref target="RFC6749" format="default"/>). In this framework, this parameter
is optional. See <xref target="tokenRequest" format="default"/>.</dd> is optional. See <xref target="tokenRequest" format="default"/>.</dd>
<dt>Encoding of "scope" parameter</dt> <dt>Encoding of <tt>scope</tt> parameter</dt>
<dd>In client-to-AS requests using OAuth <dd>In client-to-AS requests using OAuth
2.0, the "scope" parameter is string encoded (per 2.0, the <tt>scope</tt> parameter is string encoded (per
<xref target="RFC6749" format="default"/>). In this framework, this parameter <xref target="RFC6749" format="default"/>). In this framework, this parameter
may also be may also be
encoded as a byte string. See <xref target="tokenRequest" encoded as a byte string. See <xref target="tokenRequest"
format="default"/>.</dd> format="default"/>.</dd>
<dt>Cardinality of "token_type" parameter</dt> <dt>Cardinality of <tt>token_type</tt> parameter</dt>
<dd>In AS-to-client responses <dd>In AS-to-client responses
using OAuth 2.0, the token_type parameter is required (per using OAuth 2.0, the <tt>token_type</tt> parameter is required (per
<xref target="RFC6749" format="default"/>). In this framework, this parameter <xref target="RFC6749" format="default"/>). In this framework, this parameter
is is
optional. See <xref target="tokenResponse" format="default"/>.</dd> optional. See <xref target="tokenResponse" format="default"/>.</dd>
<dt>Access token retention</dt> <dt>Access token retention</dt>
<dd>In OAuth 2.0, the access token may be sent with <dd>In OAuth 2.0, the access token may be sent with
every request to the RS. The exact use of access tokens depends on the every request to the RS. The exact use of access tokens depends on the
semantics semantics
of the application and the session management concept it uses. In this of the application and the session management concept it uses. In this
framework, framework,
the RS must be able to store these tokens for later use. See the RS must be able to store these tokens for later use. See
<xref target="tokenAuthInfoEndpoint" format="default"/>.</dd> <xref target="tokenAuthInfoEndpoint" format="default"/>.</dd>
</dl> </dl>
</section> </section>
<!-- ***************************************************** -->
<section anchor="app_options" numbered="true" toc="default"> <section anchor="app_options" numbered="true" toc="default">
<name>Deployment Examples</name> <name>Deployment Examples</name>
<t>There is a large variety of IoT deployments, as is indicated in <t>There is a large variety of IoT deployments, as is indicated in
<xref target="constraints" format="default"/>, and this section highlights a few common <xref target="constraints" format="default"/>, and this section highlights a few common
variants. This section is not normative but illustrates how the variants. This section is not normative but illustrates how the
framework can be applied. framework can be applied.
</t> </t>
<t>For each of the deployment variants, there are a number of possible <t>For each of the deployment variants, there are a number of possible
security setups between clients, resource servers, and authorization security setups between clients, resource servers, and authorization
servers. The main focus in the following subsections is on how servers. The main focus in the following subsections is on how
authorization of a client request for a resource hosted by an RS is authorization of a client request for a resource hosted by an RS is
performed. This requires the security of the requests and performed. This requires the security of the requests and
responses between the clients and the RS to be considered. responses between the clients and the RS to be considered.
</t> </t>
<t>Note: CBOR diagnostic notation is used for examples of requests <t>Note: CBOR diagnostic notation is used for examples of requests
and responses.</t> and responses.</t>
<!-- ************************** -->
<!-- ************************** -->
<section anchor="localTokenValidation" numbered="true" toc="default"> <section anchor="localTokenValidation" numbered="true" toc="default">
<name>Local Token Validation</name> <name>Local Token Validation</name>
<t>In this scenario, the case where the resource server is offline is considered, <t>In this scenario, the case where the resource server is offline is considered,
i.e., it is not connected to the AS at the time of the access request. i.e., it is not connected to the AS at the time of the access request.
This access procedure involves steps (A), (B), (C), and (F) of <xref This access procedure involves steps (A), (B), (C), and (F) of <xref
target="fig_protocolFlow" format="default"/>.</t> target="fig_protocolFlow" format="default"/>.</t>
<t>Since the resource server must be able to verify the access token locally, <t>Since the resource server must be able to verify the access token locally,
self-contained access tokens must be used.</t> self-contained access tokens must be used.</t>
<t>This example shows the interactions between a client, the <t>This example shows the interactions between a client, the
authorization server, and a temperature sensor acting as a resource server. Message authorization server, and a temperature sensor acting as a resource server. Message
skipping to change at line 4175 skipping to change at line 3960
<dt>A:</dt> <dt>A:</dt>
<dd> <dd>
<t>The client first generates a public-private key pair used for <t>The client first generates a public-private key pair used for
communication security with the RS.</t> communication security with the RS.</t>
<t>The client sends a CoAP POST request to the token endpoint at the AS. <t>The client sends a CoAP POST request to the token endpoint at the AS.
The security The security
of this request can be transport or application layer. It is up the of this request can be transport or application layer. It is up the
communication security profile to define. In the example, it is communication security profile to define. In the example, it is
assumed that both the client and AS have performed mutual authentication, assumed that both the client and AS have performed mutual authentication,
e.g., via DTLS. The request contains the public key of the client and e.g., via DTLS. The request contains the public key of the client and
the audience parameter set to "tempSensorInLivingRoom", a value that the <tt>audience</tt> parameter set to "tempSensorInLivingRoom", a value that
the temperature sensor identifies itself with. The AS evaluates the the temperature sensor identifies itself with. The AS evaluates the
request and authorizes the client to access the resource.</t> request and authorizes the client to access the resource.</t>
</dd> </dd>
<dt>B:</dt> <dt>B:</dt>
<dd> <dd>
<t>The AS responds with a 2.05 (Content) response containing the <t>The AS responds with a 2.05 (Content) response containing the
Access Information, including the access token. Access Information, including the access token.
The PoP access token contains the public key of the client, and the The PoP access token contains the public key of the client, and the
Access Information contains the public key of the RS. For communication Access Information contains the public key of the RS. For communication
security, this example uses DTLS RawPublicKey between the client and the security, this example uses DTLS RawPublicKey between the client and the
RS. The issued token will have a short validity time, i.e., "exp" close RS. The issued token will have a short validity time, i.e., "exp" close
to "iat", in order to mitigate attacks using stolen client credentials. to "iat", in order to mitigate attacks using stolen client credentials.
The token includes claims, such as "scope", with the authorized access The token includes claims, such as <tt>scope</tt>, with the authorized access
that an owner of the temperature device can enjoy. In this example, the that an owner of the temperature device can enjoy. In this example, the
"scope" claim issued by the AS informs the RS that the owner of the <tt>scope</tt> claim issued by the AS informs the RS that the owner of the
token that can prove the possession of a key is authorized to make a GET token that can prove the possession of a key is authorized to make a GET
request against the /temperature resource and a POST request on the request against the /temperature resource and a POST request on the
/firmware resource. Note that the syntax and semantics of the scope claim /firmware resource. Note that the syntax and semantics of the <tt>scope</tt> claim
are application specific.</t> are application specific.</t>
<t>Note: In this example, it is assumed that the client knows what resource <t>Note: In this example, it is assumed that the client knows what resource
it wants to access and is therefore able to request specific it wants to access and is therefore able to request specific
audience and scope claims for the access token.</t> <tt>audience</tt> and <tt>scope</tt> claims for the access token.</t>
</dd> </dd>
</dl> </dl>
<!--[rfced] Please review this item in Figures 11 and 16.
Should quotation marks be added?
Content-Format: application/ace+cbor
vs.
Content-Format: "application/ace+cbor" (as in Figure 18)
(FYI, the figure numbers are different from the original.)
<figure anchor="fig_RSOffline"> <figure anchor="fig_RSOffline">
<name>Token Request and Response Using Client Credentials</name> <name>Token Request and Response Using Client Credentials</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
Authorization Authorization
Client Server Client Server
| | | |
|<=======>| DTLS Connection Establishment |<=======>| DTLS Connection Establishment
| | and mutual authentication | | and mutual authentication
| | | |
A: +-------->| Header: POST (Code=0.02) A: +-------->| Header: POST (Code=0.02)
| POST | Uri-Path:"token" | POST | Uri-Path:"token"
| | Content-Format: application/ace+cbor | | Content-Format: "application/ace+cbor"
| | Payload: <Request-Payload> | | Payload: <Request-Payload>
| | | |
B: |<--------+ Header: 2.05 Content B: |<--------+ Header: 2.05 Content
| 2.05 | Content-Format: application/ace+cbor | 2.05 | Content-Format: "application/ace+cbor"
| | Payload: <Response-Payload> | | Payload: <Response-Payload>
| | | |
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The information contained in the Request-Payload and the <t>The information contained in the Request-Payload and the
Response-Payload is shown in <xref target="fig_RSOfflineReq" format="default"/>. Response-Payload is shown in <xref target="fig_RSOfflineReq" format="default"/>.
Note that the parameter "rs_cnf" from Note that the <tt>rs_cnf</tt> parameter from
<xref target="RFC9201" format="default"/> is used to inform <xref target="RFC9201" format="default"/> is used to inform
the client about the resource server's public key. the client about the resource server's public key.
</t> </t>
<figure anchor="fig_RSOfflineReq"> <figure anchor="fig_RSOfflineReq">
<name>Request and Response Payload Details</name> <name>Request and Response Payload Details</name>
<sourcecode name="" type="cbor-diag"><![CDATA[ <sourcecode name="" type="cbor-diag"><![CDATA[
Request-Payload : Request-Payload :
{ {
"audience" : "tempSensorInLivingRoom", "audience" : "tempSensorInLivingRoom",
"client_id" : "myclient", "client_id" : "myclient",
"req_cnf" : { "req_cnf" : {
"COSE_Key" : { "COSE_Key" : {
skipping to change at line 4274 skipping to change at line 4048
"y" : b64'4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM' "y" : b64'4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM'
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>The content of the access token is shown <t>The content of the access token is shown
in <xref target="fig_BothcborMappingValueAsymmetricCWT" format="default"/>.</t> in <xref target="fig_BothcborMappingValueAsymmetricCWT" format="default"/>.</t>
<figure anchor="fig_BothcborMappingValueAsymmetricCWT"> <figure anchor="fig_BothcborMappingValueAsymmetricCWT">
<name>Access Token Including Public Key of the Client</name> <name>Access Token Including Public Key of the Client</name>
<sourcecode name="" type="json"><![CDATA[ <sourcecode name="" type="cbor-diag"><![CDATA[
{ {
"aud" : "tempSensorInLivingRoom", "aud" : "tempSensorInLivingRoom",
"iat" : "1563451500", "iat" : "1563451500",
"exp" : "1563453000", "exp" : "1563453000",
"scope" : "temperature_g firmware_p", "scope" : "temperature_g firmware_p",
"cnf" : { "cnf" : {
"COSE_Key" : { "COSE_Key" : {
"kid" : b64'1Bg8vub9tLe1gHMzV76e8', "kid" : b64'1Bg8vub9tLe1gHMzV76e8',
"kty" : "EC", "kty" : "EC",
"crv" : "P-256", "crv" : "P-256",
skipping to change at line 4354 skipping to change at line 4128
| GET | Uri-Path: "temperature" | GET | Uri-Path: "temperature"
| | | |
| | | |
| | | |
F: |<--------+ Header: 2.05 Content F: |<--------+ Header: 2.05 Content
| 2.05 | Payload: <sensor value> | 2.05 | Payload: <sensor value>
| | | |
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<!-- ************************** -->
<section anchor="introspectionAidedTokenValidation" numbered="true" toc="default"> <section anchor="introspectionAidedTokenValidation" numbered="true" toc="default">
<name>Introspection Aided Token Validation</name> <name>Introspection Aided Token Validation</name>
<t>In this deployment scenario, it is assumed that a client is not able to <t>In this deployment scenario, it is assumed that a client is not able to
access the AS at the time of the access request, whereas the RS is assumed access the AS at the time of the access request, whereas the RS is assumed
to be connected to the back-end infrastructure. Thus, the RS can make use of to be connected to the back-end infrastructure. Thus, the RS can make use of
token introspection. This access procedure involves steps (A)-(F) of token introspection. This access procedure involves steps (A)-(F) of
<xref target="fig_protocolFlow" format="default"/> but assumes steps (A) and (B) have been <xref target="fig_protocolFlow" format="default"/> but assumes steps (A) and (B) have been
carried out during a phase when the client had connectivity to the AS. carried out during a phase when the client had connectivity to the AS.
</t> </t>
skipping to change at line 4380 skipping to change at line 4153
which is shown in the example below.</t> which is shown in the example below.</t>
<t>In the example, interactions between an offline client <t>In the example, interactions between an offline client
(key fob), an RS (online lock), and an AS is shown. It is (key fob), an RS (online lock), and an AS is shown. It is
assumed that there is a provisioning step where the client has access to the assumed that there is a provisioning step where the client has access to the
AS. This corresponds to message exchanges A and B, which are shown in AS. This corresponds to message exchanges A and B, which are shown in
<xref target="fig_cOffline" format="default"/>. <xref target="fig_cOffline" format="default"/>.
</t> </t>
<t>Authorization consent from the resource owner can be preconfigured, <t>Authorization consent from the resource owner can be preconfigured,
but it can also be provided via an interactive flow with the resource but it can also be provided via an interactive flow with the resource
owner. An example of this for the key fob case could be that the owner. An example of this for the key fob case could be that the
resource owner has a connected car that he buys a generic key for and resource owner has a connected car and buys a generic key to use with the
wants to use with the car. To authorize the key fob, he connects it car. To authorize the key fob, the owner connects it to a computer that
to his computer that then provides the UI for the device. After then provides the UI for the device. After that, OAuth 2.0 implicit flow
that, OAuth 2.0 implicit flow can be used to authorize the key for can be used to authorize the key for the car at the car manufacturer's
his car at the car manufacturers AS.</t> AS.</t>
<t>Note: In this example, the client does not know the exact door it <t>Note: In this example, the client does not know the exact door it
will be used to access since the token request is not sent at the will be used to access since the token request is not sent at the
time of access. So the scope and audience parameters are set quite time of access. So the <tt>scope</tt> and <tt>audience</tt> parameters are set quite
wide to start with, while tailored values narrowing down the claims to wide to start with, while tailored values narrowing down the claims to
the specific RS being accessed can be provided to that RS during the specific RS being accessed can be provided to that RS during
an introspection step.</t> an introspection step.</t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>A:</dt> <dt>A:</dt>
<dd>The client sends a CoAP POST request to the token endpoint at the <dd>The client sends a CoAP POST request to the token endpoint at the
AS. The request contains the audience parameter set to "PACS1337" AS. The request contains the <tt>audience</tt> parameter set to "PACS1337"
(Physical Access System (PACS)), a value that identifies the (Physical Access System (PACS)), a value that identifies the
physical access control system to which the individual doors are physical access control system to which the individual doors are
connected. The AS generates an access token as an opaque string, which connected. The AS generates an access token as an opaque string, which
it can match to the specific client and the targeted audience. It it can match to the specific client and the targeted audience. It
furthermore generates a symmetric proof-of-possession key. The furthermore generates a symmetric proof-of-possession key. The
communication security and authentication between the client and AS communication security and authentication between the client and AS
is assumed to have been provided at the transport layer (e.g., via DTLS) is assumed to have been provided at the transport layer (e.g., via DTLS)
using a pre-shared security context (pre-shared key (PSK), RPK, or using a pre-shared security context (pre-shared key (PSK), RPK, or
certificate).</dd> certificate).</dd>
<dt>B:</dt> <dt>B:</dt>
skipping to change at line 4430 skipping to change at line 4203
<name>Token Request and Response Using Client Credentials</name> <name>Token Request and Response Using Client Credentials</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
Authorization Authorization
Client Server Client Server
| | | |
|<=======>| DTLS Connection Establishment |<=======>| DTLS Connection Establishment
| | and mutual authentication | | and mutual authentication
| | | |
A: +-------->| Header: POST (Code=0.02) A: +-------->| Header: POST (Code=0.02)
| POST | Uri-Path:"token" | POST | Uri-Path:"token"
| | Content-Format: application/ace+cbor | | Content-Format: "application/ace+cbor"
| | Payload: <Request-Payload> | | Payload: <Request-Payload>
| | | |
B: |<--------+ Header: 2.05 Content B: |<--------+ Header: 2.05 Content
| | Content-Format: application/ace+cbor | | Content-Format: "application/ace+cbor"
| 2.05 | Payload: <Response-Payload> | 2.05 | Payload: <Response-Payload>
| | | |
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The information contained in the Request-Payload and the <t>The information contained in the Request-Payload and the
Response-Payload is shown in <xref target="fig_cOfflineReq" format="default"/>. Response-Payload is shown in <xref target="fig_cOfflineReq" format="default"/>.
</t> </t>
<figure anchor="fig_cOfflineReq"> <figure anchor="fig_cOfflineReq">
<name>Request and Response Payload for the C Offline</name> <name>Request and Response Payload for the C Offline</name>
<sourcecode name="" type="cbor-diag"><![CDATA[ <sourcecode name="" type="cbor-diag"><![CDATA[
skipping to change at line 4483 skipping to change at line 4256
client with a status code until after step E.</dd> client with a status code until after step E.</dd>
<dt>D:</dt> <dt>D:</dt>
<dd>The RS sends the token to the introspection <dd>The RS sends the token to the introspection
endpoint on the AS using a CoAP POST request. In this example, the RS and endpoint on the AS using a CoAP POST request. In this example, the RS and
AS are assumed to have performed mutual authentication using a pre-shared security AS are assumed to have performed mutual authentication using a pre-shared security
context (PSK, RPK, or certificate) with the RS acting as the DTLS client.</dd> context (PSK, RPK, or certificate) with the RS acting as the DTLS client.</dd>
<dt>E:</dt> <dt>E:</dt>
<dd> <dd>
<t>The AS provides the introspection response (2.05 Content) <t>The AS provides the introspection response (2.05 Content)
containing parameters about the token. This includes the confirmation containing parameters about the token. This includes the confirmation
key (cnf) parameter that allows the RS to verify the client's proof of key (<tt>cnf</tt>) parameter that allows the RS to verify the client's proof of
possession in step F. Note that our example in <xref possession in step F. Note that our example in <xref
target="fig_cOfflineIntroReq" format="default"/> assumes a preestablished key target="fig_cOfflineIntroReq" format="default"/> assumes a preestablished key
(e.g., one (e.g., one
used by the client and the RS for a previous token) that is now only used by the client and the RS for a previous token) that is now only
referenced by its key identifier 'kid'.</t> referenced by its key identifier 'kid'.</t>
<t>After receiving message E, the RS responds to the client's POST in <t>After receiving message E, the RS responds to the client's POST in
step C with the CoAP response code 2.01 (Created).</t> step C with the CoAP response code 2.01 (Created).</t>
</dd> </dd>
</dl> </dl>
<figure anchor="fig_cOfflineIntrospection"> <figure anchor="fig_cOfflineIntrospection">
skipping to change at line 4550 skipping to change at line 4323
"cnf" : { "cnf" : {
"kid" : b64'c29tZSBwdWJsaWMga2V5IGlk' "kid" : b64'c29tZSBwdWJsaWMga2V5IGlk'
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>The client uses the symmetric PoP key to establish a DTLS <t>The client uses the symmetric PoP key to establish a DTLS
PreSharedKey secure connection to the RS. The CoAP request PUT is PreSharedKey secure connection to the RS. The CoAP request PUT is
sent to the uri-path /state on the RS, changing the state of the door to sent to the uri-path /state on the RS, changing the state of the door to
locked.</t> locked.</t>
<!--[rfced] We are having trouble parsing the following sentence. Please
let us know how we may clarify.
Original:
F: The RS responds with a appropriate over the secure DTLS
channel.
Perhaps:
F: The RS responds with an appropriate response over the secure DTLS
channel.
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>F:</dt> <dt>F:</dt>
<dd>The RS responds with an appropriate over the secure DTLS channel.</dd> <dd>The RS responds with an appropriate response over the secure DTLS channel.</dd>
</dl> </dl>
<figure anchor="fig_cOfflineDTLSRequestAndResponse"> <figure anchor="fig_cOfflineDTLSRequestAndResponse">
<name>Resource Request and Response Protected by OSCORE</name> <name>Resource Request and Response Protected by OSCORE</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
Resource Resource
Client Server Client Server
| | | |
|<=======>| DTLS Connection Establishment |<=======>| DTLS Connection Establishment
| | using Pre Shared Key | | using Pre Shared Key
| | | |
skipping to change at line 4614 skipping to change at line 4376
<t>Thanks to <contact fullname="Cigdem Sengul"/> for some very useful review <t>Thanks to <contact fullname="Cigdem Sengul"/> for some very useful review
comments.</t> comments.</t>
<t>Thanks to <contact fullname="Carsten Bormann"/> for contributing the text for <t>Thanks to <contact fullname="Carsten Bormann"/> for contributing the text for
the CoRE Resource Type registry.</t> the CoRE Resource Type registry.</t>
<t>Thanks to <contact fullname="Roman Danyliw"/> for suggesting <xref <t>Thanks to <contact fullname="Roman Danyliw"/> for suggesting <xref
target="app_diffOAuth" format="default"/> target="app_diffOAuth" format="default"/>
(including its contents).</t> (including its contents).</t>
<t><contact fullname="Ludwig Seitz"/> and <contact fullname="Göran Selander"/> <t><contact fullname="Ludwig Seitz"/> and <contact fullname="Göran Selander"/>
worked on this document as part of the CelticPlus project CyberWI, with funding worked on this document as part of the CelticPlus project CyberWI, with funding
from Vinnova. <contact fullname="Ludwig Seitz"/> from Vinnova. <contact fullname="Ludwig Seitz"/>
was also received further funding for this work by Vinnova in the context of has also received further funding for this work by Vinnova in the context of
the CelticNext project CRITISEC.</t> the CelticNext project CRITISEC.</t>
</section> </section>
</back> </back>
<!--[rfced] Terminology <!--[rfced] Terminology
a) Throughout the text, the following terminology appears to a) Throughout the text, the following terminology appears to
be used inconsistently. Please review these occurrences and let us know be used inconsistently. Please review these occurrences and let us know
if/how they be made consistent. if/how they be made consistent.
group-audience vs. group audience group-audience vs. group audience
"AS Request Creation Hints" message vs. "AS Request Creation Hints" ===
Ludwig: I cannot find any instances of "group audience" in this document.
b) We see parameter names appear within double quotes and without quotes ===
inconsistently throughout the document. Do you want any changes to
make this consistent?
ace_profile parameter vs. "ace_profile" parameter
cnonce parameter vs. "cnonce" parameter
scope parameter vs. "scope" parameter
Note: there are instances of "cnonce" parameter tagged using <tt>.
FYI, xml2rfc no longer renders <tt> with quotation marks in the text output;
it still renders fixed-width font in the HTML and PDF outputs.
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. For example, please consider
whether the following should be updated: traditional, native, dumb, and
pronouns such as he/his/her.
--> -->
</rfc> </rfc>
 End of changes. 172 change blocks. 
417 lines changed or deleted 178 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/