rfc9200xml2.original.xml   rfc9200.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!DOCTYPE rfc [
which is available here: http://xml.resource.org. --> <!ENTITY nbsp "&#160;">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY zwsp "&#8203;">
<!-- One method to get references from the online citation libraries. <!ENTITY nbhy "&#8209;">
There has to be one entity for each item to be referenced. <!ENTITY wj "&#8288;">
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3986.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4949.xml">
<!ENTITY RFC6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6347.xml">
<!ENTITY RFC6690 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6690.xml">
<!ENTITY RFC6749 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6749.xml">
<!ENTITY RFC6750 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6750.xml">
<!ENTITY RFC6819 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6819.xml">
<!ENTITY RFC6838 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6838.xml">
<!ENTITY RFC6920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6920.xml">
<!ENTITY RFC7009 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7009.xml">
<!ENTITY RFC8949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8949.xml">
<!ENTITY RFC7228 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7228.xml">
<!ENTITY RFC7231 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7231.xml">
<!ENTITY RFC7252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7252.xml">
<!ENTITY RFC7519 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7519.xml">
<!ENTITY RFC7521 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7521.xml">
<!ENTITY RFC7540 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7540.xml">
<!ENTITY RFC7591 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7591.xml">
<!ENTITY RFC7641 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7641.xml">
<!ENTITY RFC7662 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7662.xml">
<!ENTITY RFC7744 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7744.xml">
<!ENTITY RFC7959 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7959.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8126.xml">
<!ENTITY RFC8152 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8152.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8252.xml">
<!ENTITY RFC8259 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8259.xml">
<!ENTITY RFC8392 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8392.xml">
<!ENTITY RFC8414 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8414.xml">
<!ENTITY RFC8446 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8446.xml">
<!ENTITY RFC8516 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8516.xml">
<!ENTITY RFC8613 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8613.xml">
<!ENTITY RFC8628 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8628.xml">
<!ENTITY RFC8693 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8693.xml">
<!ENTITY RFC8747 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8747.xml">
<!ENTITY I-D.ietf-ace-oauth-params SYSTEM "http://xml.resource.org/public/rfc/bi
bxml3/reference.I-D.ietf-ace-oauth-params.xml">
<!ENTITY I-D.erdtman-ace-rpcc SYSTEM "http://xml.resource.org/public/rfc/bibxml3
/reference.I-D.erdtman-ace-rpcc.xml">
<!ENTITY I-D.ietf-tls-dtls13 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/
reference.I-D.ietf-tls-dtls13.xml">
<!ENTITY I-D.ietf-quic-transport SYSTEM "http://xml.resource.org/public/rfc/bibx
ml3/reference.I-D.ietf-quic-transport.xml">
<!ENTITY I-D.ietf-ace-dtls-authorize SYSTEM "http://xml.resource.org/public/rfc/
bibxml3/reference.I-D.ietf-ace-dtls-authorize.xml">
<!ENTITY I-D.ietf-ace-oscore-profile SYSTEM "http://xml.resource.org/public/rfc/
bibxml3/reference.I-D.ietf-ace-oscore-profile.xml">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-ace-oauth-au
<!-- used by XSLT processors --> thz-45" number="9200" ipr="trust200902" obsoletes="" updates="" submissionType="
<!-- For a complete list and description of processing instructions (PIs), IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="
please see http://xml.resource.org/authoring/README.html. --> 4" symRefs="true" sortRefs="true" version="3">
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds <!--[rfced] *AD, as several new versions of the I-D were submitted after approva
might want to use. l,
(Here they are set differently than their defaults in xml2rfc v1.32) --> please review and let us know if you approve these changes:
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation --> a) the addition of the definition of "cti" in Section 5.9.2.
<!-- control the table of contents (ToC) --> b) updated text in Section 5.8.4.4
<?rfc toc="yes"?> c) RFC 4648 added as a normative reference
<!-- generate a ToC -->
<?rfc tocdepth="4"?> For all changes, please see this diff file:
<!-- the number of levels of subsections in ToC. default: 3 --> https://www.ietf.org/rfcdiff?url1=draft-ietf-ace-oauth-authz-43&url2=draft-ietf-
<!-- control references --> ace-oauth-authz-46
<?rfc symrefs="yes"?> (Note: This includes noise such as changes to the characters in bulleted lists.)
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] --> -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically --> <!-- xml2rfc v2v3 conversion 3.9.1 -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-ace-oauth-authz-43" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <!-- ***** FRONT MATTER ***** -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="ACE-OAuth">Authentication and Authorization for Constrained Envir
if the onments (ACE) Using the OAuth 2.0 Framework (ACE-OAuth)</title>
full title is longer than 39 characters -->
<title abbrev="ACE-OAuth">Authentication and Authorization for Constrained Envir <!--[rfced] Regarding the title, is "(ACE)" necessary? It seems redundant with
onments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)</title> "(ACE-OAuth)" later.
<!-- add 'role="editor"' below for the editors if appropriate --> Current:
Authentication and Authorization for Constrained Environments (ACE)
Using the OAuth 2.0 Framework (ACE-OAuth)
<!-- Another author who claims to be an editor --> Perhaps:
Authentication and Authorization for Constrained Environments
Using the OAuth 2.0 Framework (ACE-OAuth)
-->
<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> <city>Malmö</city> <code>211 35</code>
<city>Malmö</city>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>ludwig.seitz@combitech.com</email> <email>ludwig.seitz@combitech.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Göran Selander" initials="G." surname="Selander">
<author fullname="Goeran Selander" initials="G." surname="Selander">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Faroegatan 6</street> <street>Faroegatan 6</street>
<code>164 80</code> <city>Kista</city> <code>164 80</code>
<city>Kista</city>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>goran.selander@ericsson.com</email> <email>goran.selander@ericsson.com</email>
<!-- uri and facsimile elements may also be added -->
</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> <street/>
<code></code> <city></city> <code/>
<city/>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>erik@wahlstromstekniska.se</email> <email>erik@wahlstromstekniska.se</email>
</address> </address>
</author> </author>
<author fullname="Samuel Erdtman" initials="S." surname="Erdtman"> <author fullname="Samuel Erdtman" initials="S." surname="Erdtman">
<organization>Spotify AB</organization> <organization>Spotify AB</organization>
<address> <address>
<postal> <postal>
<street>Birger Jarlsgatan 61, 4tr</street> <street>Birger Jarlsgatan 61, 4tr</street>
<code>113 56</code> <city>Stockholm</city> <code>113 56</code>
<city>Stockholm</city>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>erdtman@spotify.com</email> <email>erdtman@spotify.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig"> <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>Arm Ltd.</organization> <organization>Arm Ltd.</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<code>6067</code> <city>Absam</city> <code>6067</code>
<city>Absam</city>
<country>Austria</country> <country>Austria</country>
</postal> </postal>
<email>Hannes.Tschofenig@arm.com</email> <email>Hannes.Tschofenig@arm.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date year="2021" /> <date year="2022" month="March" />
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2
rfc will fill
in the current day and month for you. If the year is not the current one
, it is necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the purpose of calculating the expiry date). With drafts it is norm
ally sufficient to specify just the year. -->
<!-- Meta-data Declarations -->
<area>Security</area> <area>Security</area>
<workgroup>ACE</workgroup>
<workgroup>ACE Working Group</workgroup> <keyword>CoAP</keyword>
<keyword>OAuth 2.0</keyword>
<!-- WG name at the upperleft corner of the doc, <keyword>Access Control</keyword>
IETF is fine for individual submissions. <keyword>Authorization</keyword>
If this element is not present, the default is "Network Working Group", <keyword>Internet of Things</keyword>
which is used by the RFC Editor as a nod to the history of the IETF. --
>
<keyword>CoAP, OAuth 2.0, Access Control, Authorization, Internet of Things<
/keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>This specification defines a framework for authentication and <t>This specification defines a framework for authentication and
authorization in Internet of Things (IoT) environments called ACE-OAuth. authorization in Internet of Things (IoT) environments called ACE&nbhy;OAu th.
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">
<name>Introduction</name>
<!-- ***************************************************** --> <t>Authorization is the process for granting approval to an entity to
access a generic resource <xref target="RFC4949" format="default"/>. The auth
<section anchor="intro" title="Introduction"> orization
task itself can best be described as granting access to a requesting client f
<t>Authorization is the process for granting approval to an entity to or
access a generic resource <xref target="RFC4949"/>. The authorization task a resource hosted on a device, i.e., the resource server (RS). This exchange
itself can best be described as granting access to a requesting client, for is
a resource hosted on a device, the resource server (RS). This exchange is mediated by one or multiple authorization servers (ASes). Managing
mediated by one or multiple authorization servers (AS). 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>
<t>While prior work on authorization solutions for the Web and for the mob
<t>While prior work on authorization solutions for the Web and for the mobile ile
environment also applies to the Internet of Things (IoT) environment, many environment also applies to the Internet of Things (IoT) environment, many
IoT devices are constrained, for example, in terms of processing IoT devices are constrained, for example, in terms of processing
capabilities, available memory, etc. For such devices the Constrained capabilities, available memory, etc. For such devices, the Constrained
Application Protocol (CoAP) <xref target="RFC7252"/> can alleviate some Application Protocol (CoAP) <xref target="RFC7252" format="default"/> can all
eviate some
resource concerns when used instead of HTTP to implement the communication resource concerns when used instead of HTTP to implement the communication
flows of this specification.</t> flows of this specification.</t>
<t><xref target="constraints" format="default"/> gives an overview of the
<t><xref target="constraints"/> gives an overview of the constraints constraints
considered in this design, and a more detailed treatment of constraints can considered in this design, and a more detailed treatment of constraints can
be found in <xref target="RFC7228"/>. This design aims to accommodate be found in <xref target="RFC7228" format="default"/>. This design aims to a
different IoT deployments and thus a continuous range of device and network ccommodate
capabilities. Taking energy consumption as an example: At one end there are different IoT deployments as well as a continuous range of device and network
energy-harvesting or battery powered devices which have a tight power capabilities. Taking energy consumption as an example, at one end, there are
budget, on the other end there are mains-powered devices, and all levels in energy-harvesting or battery-powered devices that have a tight power
budget; on the other end, there are mains-powered devices; and all levels exi
st in
between.</t> between.</t>
<t>Hence, IoT devices may be very different in terms of available processi
<t>Hence, IoT devices may be very different in terms of available processing ng
and message exchange capabilities and there is a need to support many and message exchange capabilities, and there is a need to support many
different authorization use cases <xref target="RFC7744"/>.</t> different authorization use cases <xref target="RFC7744" format="default"/>
.</t>
<t>This specification describes a framework for authentication and authorizat <t>This specification describes a framework for Authentication and Authori
ion zation
in constrained environments (ACE) built on re-use of OAuth 2.0 for Constrained Environments (ACE) built on reuse of OAuth 2.0
<xref target="RFC6749"/>, thereby extending authorization to Internet of Thin <xref target="RFC6749" format="default"/>, thereby extending authorization to
gs Internet of Things
devices. This specification contains the necessary building blocks devices. This specification contains the necessary building blocks
for adjusting OAuth 2.0 to IoT environments.</t> for adjusting OAuth 2.0 to IoT environments.</t>
<t>Profiles of this framework are available in separate specifications, su
<t>Profiles of this framework are available in separate specifications, such ch as
as <xref target="RFC9202" format="default"/> or <xref target="RFC9203" format="d
<xref target="I-D.ietf-ace-dtls-authorize"/> or <xref target="I-D.ietf-ace-os efault"/>.
core-profile"/>.
Such profiles may specify the use of the framework for a specific secu rity protocol Such profiles may specify the use of the framework for a specific secu rity protocol
and the underlying transports for use in a specific deployment environ ment to improve interoperability. and the underlying transports for use in a specific deployment environ ment to improve interoperability.
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 multi ple More powerful devices, such as mobile phones and tablets, may implement multi ple
profiles and will therefore be able to interact with a wider range of constra ined devices. profiles and will therefore be able to interact with a wider range of constra ined 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"/>. <xref target="app_profileRequirements" format="default"/>.
</t> </t>
</section>
</section> <!-- ***************************************************** -->
<!-- ***************************************************** -->
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref
target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in
all capitals, as shown here.</t>
<t>Certain security-related terms such as "authentication", <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name>
<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>RECO
MMENDED</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>
<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 authentication code", and "verify", are taken from <xref target="RFC4949" format
target="RFC4949"/>. ="default"/>.
</t> </t>
<!--[rfced] FYI, we have added this sentence to explain "RESTful".
(Similar text appears in RFC 8613 and others.)
<t>Since exchanges in this specification are described as RESTful protocol Original:
interactions, HTTP <xref target="RFC7231"/> offers useful terminology. Since exchanges in this specification are described as RESTful
</t> protocol interactions, HTTP [RFC7231] offers useful terminology.
<t>Terminology for entities in the architecture is defined in OAuth Current:
2.0 <xref target="RFC6749"/> such as client (C), resource server (RS), 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
interactions, HTTP <xref target="RFC7231" format="default"/> offers useful t
erminology.
(Note that "RESTful" refers to the Representational State Transfer (REST) ar
chitecture.)
</t>
<t>Terminology for entities in the architecture is defined in OAuth
2.0 <xref target="RFC6749" format="default"/>, such as client (C), resource se
rver (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="tokenAuthInf
introspection at the AS and authz-info at the RS (see <xref target="tokenAuthInf oEndpoint" format="default"/> for a definition of the authz-info endpoint).
oEndpoint"/> for a definition of the authz-info endpoint). The CoAP definition, which is "[a]n entity
The CoAP <xref target="RFC7252"/> definition, which is "An entity participating in the CoAP protocol" <xref target="RFC7252" format="default"/>, i
participating in the CoAP protocol" is not used in this specification.</t> s not used in this specification.</t>
<t>The specification in this document is called the "framework" or "ACE fr
<t>The specifications in this document is called the "framework" or "ACE framewo amework".
rk". When referring to "profiles of this framework", it refers to additional specific
When referring to "profiles of this framework" it refers to additional specifica ations that
tions 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 ac
<t>The term "Access Information" is used for parameters, other than the access t cess token, provided to the client by the AS to enable it to access the RS
oken, 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, 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 whe ther an access request should be granted.</t> including the claims of relevant access tokens, that an RS uses to determine whe ther an access request should be granted.</t>
</section>
<!-- ***************************************************** -->
</section> <section anchor="overview" numbered="true" toc="default">
<name>Overview</name>
<!-- ***************************************************** --> <t>This specification defines the ACE framework for authorization in the I
nternet
<section anchor="overview" title="Overview">
<t>This specification defines the ACE framework for authorization in the Inter
net
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"/>
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.
</t> </t>
<t>Another building block is the lightweight web transfer protocol CoAP
<t>Another building block is the lightweight web transfer protocol CoAP <xref target="RFC7252" format="default"/>, for those communication environment
<xref target="RFC7252"/>, for those communication environments where HTTP is s where HTTP is
not appropriate. CoAP typically runs on top of UDP, which further reduces not appropriate. CoAP typically runs on top of UDP, which further reduces
overhead and message exchanges. While this specification defines extensions overhead and message exchanges. While this specification defines extensions
for the use of OAuth over CoAP, other underlying protocols are not prohibited for the use of OAuth over CoAP, other underlying protocols are not prohibited
from being supported in the future, such as HTTP/2 <xref target="RFC7540"/>, from being supported in the future, such as HTTP/2 <xref target="RFC7540" form
Message Queuing Telemetry Transport (MQTT) <xref target="MQTT5.0"/>, at="default"/>,
Bluetooth Low Energy (BLE) <xref target="BLE"/> and QUIC <xref Message Queuing Telemetry Transport (MQTT) <xref target="MQTT5.0" format="defa
target="I-D.ietf-quic-transport"/>. Note that this document specifies ult"/>,
protocol exchanges in terms of RESTful verbs such as GET and POST. Bluetooth Low Energy (BLE) <xref target="BLE" format="default"/>, and QUIC <xr
Future profiles using protocols that do not support these verbs MUST ef target="RFC9000" format="default"/>. Note that this document specifies
protocol exchanges in terms of RESTful verbs, such as GET and POST.
Future profiles using protocols that do not support these verbs <bcp14>MUST</b
cp14>
specify how the corresponding protocol messages are transmitted instead.</t> specify how the corresponding protocol messages are transmitted instead.</t>
<t>A third building block is the Concise Binary Object Representation
<t>A third building block is the Concise Binary Object Representation (CBOR) <xref target="RFC8949" format="default"/>, for encodings where JSON
(CBOR) <xref target="RFC8949"/>, for encodings where JSON <xref target="RFC8259" format="default"/> is not sufficiently compact. CBOR i
<xref target="RFC8259"/> is not sufficiently compact. CBOR is a binary s a binary
encoding designed for small code and message size. Self-contained tokens encoding designed for small code and message size. Self-contained tokens
and protocol message payloads are encoded in CBOR when CoAP is used. When CoAP and protocol message payloads are encoded in CBOR when CoAP is used. When CoAP
is not used, the use of CBOR remains RECOMMENDED. is not used, the use of CBOR remains <bcp14>RECOMMENDED</bcp14>.
</t> </t>
<t>A fourth building block is CBOR Object Signing and Encryption (COSE)
<t>A fourth building block is CBOR Object Signing and Encryption (COSE) <xref target="RFC8152" format="default"/>, which enables object-level layer se
<xref target="RFC8152"/>, which enables object-level layer security as an curity as an
alternative or complement to transport layer security (DTLS alternative or complement to transport layer security (DTLS
<xref target="RFC6347"/> or TLS <xref target="RFC8446"/>). COSE is used to <xref target="RFC6347" format="default"/> or TLS <xref target="RFC8446" form
secure self-contained tokens such as proof-of-possession (PoP) tokens, at="default"/>). COSE is used to
secure self-contained tokens, such as proof-of-possession (PoP) tokens,
which are an extension to the OAuth bearer tokens. The default token format which are an extension to the OAuth bearer tokens. The default token format
is defined in CBOR Web Token (CWT) <xref target="RFC8392"/>. is defined in CBOR Web Token (CWT) <xref target="RFC8392" format="default"/>
Application-layer security for CoAP using COSE can be provided with OSCORE .
<xref target="RFC8613"/>.</t> Application-layer security for CoAP using COSE can be provided with Object S
ecurity for
<t>With the building blocks listed above, solutions satisfying various Constrained RESTful Environments (OSCORE)
<xref target="RFC8613" format="default"/>.</t>
<t>With the building blocks listed above, solutions satisfying various
IoT device and network constraints are possible. A list of constraints is IoT device and network constraints are possible. A list of constraints is
described in detail in <xref target="RFC7228"/> and a description described in detail in <xref target="RFC7228" format="default"/>, and a descri ption
of how the building blocks mentioned above relate to the various constraints of how the building blocks mentioned above relate to the various constraints
can be found in <xref target="constraints"/>.</t> can be found in <xref target="constraints" format="default"/>.</t>
<t>Luckily, not every IoT device suffers from all constraints. Neverthele
<t>Luckily, not every IoT device suffers from all constraints. The ACE ss, the ACE
framework nevertheless takes all these aspects into account and allows framework takes all these aspects into account and allows
several different deployment variants to co-exist, rather than mandating a several different deployment variants to coexist, rather than mandating a
one-size-fits-all solution. It is important to cover the wide one-size-fits-all solution. It is important to cover the wide
range of possible interworking use cases and the different requirements from range of possible interworking use cases and the different requirements from
a security point of view. Once IoT deployments mature, popular deployment a security point of view. Once IoT deployments mature, popular deployment
variants will be documented in the form of ACE profiles.</t> variants will be documented in the form of ACE profiles.</t>
<section anchor="oauth2Overview" numbered="true" toc="default">
<section anchor="oauth2Overview" title="OAuth 2.0"> <name>OAuth 2.0</name>
<t>The OAuth 2.0 authorization framework enables a client to obtain <t>The OAuth 2.0 authorization framework enables a client to obtain
scoped access to a resource with the permission of a resource scoped access to a resource with the permission of a resource
owner. Authorization information, or references to it, is passed between th e nodes owner. Authorization information, or references to it, is passed between th e nodes
using access tokens. These access tokens are issued to clients by an using access tokens. These access tokens are issued to clients by an
authorization server with the approval of the resource owner. The client authorization server with the approval of the resource owner. The client
uses the access token to access the protected resources hosted by the uses the access token to access the protected resources hosted by the
resource server.</t> resource server.</t>
<t>A number of OAuth 2.0 terms are used within this specification:
<t>A number of OAuth 2.0 terms are used within this specification: </t>
<dl newline="true" spacing="normal">
<list style="hanging"> <dt>Access Tokens:</dt>
<dd>
<t hangText="Access Tokens:"><vspace blankLines="0"/> <t>
Access tokens are credentials needed to access protected resources. An Access tokens are credentials needed to access protected resources. An
access token is a data structure representing authorization permissions access token is a data structure representing authorization permissions
issued by the AS to the client. Access tokens are generated by the AS issued by the AS to the client. Access tokens are generated by the AS
and consumed by the RS. The access token content is opaque and consumed by the RS. The access token content is opaque
to the client. to the client.
<vspace blankLines="1"/> </t>
Access tokens can have different formats, and various methods <t>
of utilization e.g., cryptographic properties) based on the security Access tokens can have different formats and various methods
of utilization (e.g., cryptographic properties) based on the security
requirements of the given deployment. requirements of the given deployment.
<vspace blankLines="1"/> </t>
</t> </dd>
<dt>Introspection:</dt>
<t hangText="Introspection:"><vspace blankLines="0"/> <dd>
Introspection is a method for a resource server or potentially a client, Introspection is a method for a resource server, or potentially a client,
to query the authorization server for the active state and content of a to query the authorization server for the active state and content of a
received access token. This is particularly useful in those cases where received access token. This is particularly useful in those cases where
the authorization decisions are very dynamic and/or where the received the authorization decisions are very dynamic and/or where the received
access token itself is an opaque reference rather than a self-contained access token itself is an opaque reference, rather than a self-contained
token. More information about introspection in OAuth 2.0 can be token. More information about introspection in OAuth 2.0 can be
found in <xref target="RFC7662"/>. found in <xref target="RFC7662" format="default"/>.
</t> </dd>
<dt>Refresh Tokens:</dt>
<t hangText="Refresh Tokens:"><vspace blankLines="0"/> <dd>
<t>
Refresh tokens are credentials used to obtain access tokens. Refresh tokens are credentials used to obtain access tokens.
Refresh tokens are issued to the client by the authorization Refresh tokens are issued to the client by the authorization
server and are used to obtain a new access token when the current server and are used to obtain a new access token when the current
access token expires, or to obtain additional access tokens with access token expires or to obtain additional access tokens with
identical or narrower scope (such access tokens may have a shorter identical or narrower scope (such access tokens may have a shorter
lifetime and fewer permissions than authorized by the resource owner). lifetime and fewer permissions than authorized by the resource owner).
Issuing a refresh token is optional at the discretion of the Issuing a refresh token is optional at the discretion of the
authorization server. If the authorization server issues a refresh authorization server. If the authorization server issues a refresh
token, it is included when issuing an access token (i.e., step (B) in token, it is included when issuing an access token (i.e., step (B) in
<xref target="fig:protocolFlow"/>). <xref target="fig_protocolFlow" format="default"/>).
<vspace blankLines="1"/> </t>
<t>
A refresh token in OAuth 2.0 is a string representing the authorization A refresh token in OAuth 2.0 is a string representing the authorization
granted to the client by the resource owner. The string is usually granted to the client by the resource owner. The string is usually
opaque to the client. The token denotes an identifier used to retrieve opaque to the client. The token denotes an identifier used to retrieve
the authorization information. Unlike access tokens, refresh the authorization information. Unlike access tokens, refresh
tokens are intended for use only with authorization servers and tokens are intended for use only with authorization servers and
are never sent to resource servers. In this framework, refresh are never sent to resource servers. In this framework, refresh
tokens are encoded in binary instead of strings, if used. tokens are encoded in binary instead of strings, if used.
<vspace blankLines="1"/></t> </t>
</dd>
<t hangText="Proof of Possession Tokens:"><vspace blankLines="0"/> <dt>Proof-of-Possession Tokens:</dt>
<dd>
<t>
A token may be bound to a cryptographic key, which is then used A token may be bound to a cryptographic key, which is then used
to bind the token to a request authorized by the token. Such tokens to bind the token to a request authorized by the token. Such tokens
are called proof-of-possession tokens (or PoP tokens). are called proof-of-possession tokens (or PoP tokens).
<vspace blankLines="1"/> </t>
<t>
The proof-of-possession security concept used here assumes that The proof-of-possession security concept used here assumes that
the AS acts as a trusted third party that binds keys to tokens. the AS acts as a trusted third party that binds keys to tokens.
In the case of access tokens, these so called PoP keys are then used by In the case of access tokens, these so-called PoP keys are then used by
the client to demonstrate the possession of the secret to the RS when the client to demonstrate the possession of the secret to the RS when
accessing the resource. The RS, when receiving an access token, needs accessing the resource. The RS, when receiving an access token, needs
to verify that the key used by the client matches the one bound to the to verify that the key used by the client matches the one bound to the
access token. When this specification uses the term "access token" it access token. When this specification uses the term "access token", it
is assumed to be a PoP access token unless specifically stated is assumed to be a PoP access token unless specifically stated
otherwise. otherwise.
<vspace blankLines="1"/> </t>
<t>
The key bound to the token (the PoP key) may use either symmetric or The key bound to the token (the PoP key) may use either symmetric or
asymmetric cryptography. The appropriate choice of the kind of asymmetric cryptography. The appropriate choice of the kind of
cryptography depends on the constraints of the IoT devices as well as cryptography depends on the constraints of the IoT devices as well as
on the security requirements of the use case. on the security requirements of the use case.
<vspace blankLines="1"/> </t>
<list style="hanging"> <dl newline="true" spacing="normal">
<dt>Symmetric PoP key:</dt>
<t hangText="Symmetric PoP key:"><vspace blankLines="0"/> <dd>
The AS generates a random symmetric PoP key. The key is either <t>
The AS generates a random, symmetric PoP key. The key is either
stored to be returned on introspection calls or included in the stored to be returned on introspection calls or included in the
token. Either the whole token or only the key MUST be encrypted token. Either the whole token or only the key <bcp14>MUST</bcp14> be encrypted
in the latter case. The PoP key is also returned to in the latter case. The PoP key is also returned to
client together with the token.<vspace blankLines="1"/> client together with the token.</t>
</dd>
</t> <dt>Asymmetric PoP key:</dt>
<t hangText="Asymmetric PoP key:"><vspace blankLines="0"/> <dd>
An asymmetric key pair is generated by the client and the public key An asymmetric key pair is generated by the client and the public key
is sent to the AS (if it does not already have knowledge of the is sent to the AS (if it does not already have knowledge of the
client's public key). Information about the public key, which is the client's public key). Information about the public key, which is the
PoP key in this case, is either stored to be returned on PoP key in this case, is either stored to be returned on
introspection calls or included inside the token and sent introspection calls or included inside the token and sent
back to the client. The resource server consuming the token can back to the client. The resource server consuming the token can
identify the public key from the information in the token, which identify the public key from the information in the token, which
allows the client to use the corresponding private key for the allows the client to use the corresponding private key for the
proof of possession. proof of possession.
</t> </dd>
</list> </dl>
<t> The token is either a simple reference
<vspace blankLines="1"/> The token is either a simple reference, or a structured information object (e.g., CWT <xref target="RFC8392" form
or a structured information object (e.g., CWT <xref target="RFC8392"/>) at="default"/>)
protected by a cryptographic wrapper (e.g., COSE <xref protected by a cryptographic wrapper (e.g., COSE <xref target="RFC8152" f
target="RFC8152"/>). The choice of PoP key does not necessarily imply ormat="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.<vspace blankLines="1"/> token.</t>
</t> </dd>
<dt>Scopes and Permissions:</dt>
<t hangText="Scopes and Permissions:"><vspace blankLines="0"/> <dd>
<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 scope 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 scope 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 defines the use of CBOR encoding (see <xref target="oauthProfile" format
target="oauthProfile"/>, for such requests and responses. ="default"/>) for such requests and responses.
<vspace blankLines="1"/> </t>
<t>
The values of the scope parameter in OAuth 2.0 are expressed as a list The values of the scope 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"/> <!-- <vspace blankLines="1"/>
A common misconception is that the requested scopes must A common misconception is that the requested scopes must
also be included in the returned access token, but the requested scopes 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 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 token as a separate attribute, but it's more common to assert the
requested and authorized access using claims within the access token. requested and authorized access using claims within the access token.
<vspace blankLines="1"/>--> <vspace blankLines="1"/>-->
More details about the concept of scopes is found under Section 3.3 in More details about the concept of scopes are found under
<xref target="RFC6749" />.<vspace blankLines="1"/> <xref target="RFC6749" sectionFormat="of" section="3.3"/>.</t>
</t> </dd>
<dt>Claims:</dt>
<t hangText="Claims:"><vspace blankLines="0"/> <dd>
<t>
Information carried in the access token or returned from introspection, ca lled claims, is in the form of Information carried in the access token or returned from introspection, ca lled 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 "iss" claim) and
what audience the access token is intended for (via the "aud" claim). what audience the access token is intended for (via the "aud" claim).
The audience of an access token can be a specific resource or one 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.
<vspace blankLines="1"/> </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"/> where claims are encoded as a Token (JWT) <xref target="RFC7519" format="default"/>, where claims are
JSON object. In <xref target="RFC8392"/> the CBOR Web Token (CWT) encoded as a
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.
<vspace blankLines="1"/> </t>
</t> </dd>
<dt>Token and Introspection Endpoints:</dt>
<t hangText="The token and introspection Endpoints:"><vspace blankLines="0 <dd>
"/> <t>
The AS hosts the token endpoint that allows a client to request access The AS hosts the token endpoint that allows a client to request access
tokens. The client makes a POST request to the token endpoint on the AS tokens. The client makes a POST request to the token endpoint on the AS
and receives the access token in the response (if the request was and receives the access token in the response (if the request was
successful). successful).
<vspace blankLines="0"/> </t>
<t>
In some deployments, a token introspection endpoint is provided by In some deployments, a token introspection endpoint is provided by
the AS, which can be used by the RS and potentially the client, if they the AS, which can be used by the RS and potentially the client, if they
need to request additional information regarding a received access need to request additional information regarding a received access
token. The requesting entity makes a POST request to the introspection token. The requesting entity makes a POST request to the introspection
endpoint on the AS and receives information about the access token in endpoint on the AS and receives information about the access token in
the response. (See "Introspection" above.) the response. (See "Introspection" above.)
<vspace blankLines="1"/> </t>
</t> </dd>
</dl>
</list> </section>
</t> <section anchor="coap" numbered="true" toc="default">
</section> <name>CoAP</name>
<t>
<section anchor="coap" title="CoAP"> CoAP is an application-layer protocol similar to HTTP but specifically
<t>
CoAP is an application-layer protocol similar to HTTP, but specifically
designed for constrained environments. CoAP typically uses designed for constrained environments. CoAP typically uses
datagram-oriented transport, such as UDP, where reordering and loss datagram-oriented transport, such as UDP, where reordering and loss
of packets can occur. A security solution needs to take the latter aspects of packets can occur. A security solution needs to take the latter aspects
into account.</t> into account.</t>
<t>While HTTP uses headers and query strings to convey additional
<t>While HTTP uses headers and query strings to convey additional
information about a request, CoAP encodes such information into header information about a request, CoAP encodes such information into header
parameters called 'options'.</t> parameters called 'options'.</t>
<t>CoAP supports application-layer fragmentation of the CoAP payloads
<t>CoAP supports application-layer fragmentation of the CoAP payloads through block-wise transfers <xref target="RFC7959" format="default"/>. How
through blockwise transfers <xref target="RFC7959"/>. However, ever,
blockwise transfer does not increase the size limits of CoAP options, block-wise transfer does not increase the size limits of CoAP options;
therefore data encoded in options has to be kept small. therefore, data encoded in options has to be kept small.
</t> </t>
<t>Transport layer security for CoAP can be provided by DTLS or TLS
<t>Transport layer security for CoAP can be provided by DTLS or TLS <xref target="RFC6347" format="default"/> <xref target="RFC8446" format="defau
<xref target="RFC6347"/><xref target="RFC8446"/> lt"/>
<xref target="I-D.ietf-tls-dtls13"/>. <xref target="RFC9147" format="default"/>.
CoAP defines a number of proxy operations that require transport layer CoAP defines a number of proxy operations that require transport layer
security to be terminated at the proxy. One approach for protecting CoAP com munication security to be terminated at the proxy. One approach for protecting CoAP com munication
end-to-end through proxies, and also to support security for CoAP over end-to-end through proxies, and also to support security for CoAP over
a different transport in a uniform way, is to provide security at the applic ation a different transport in a uniform way, is to provide security at the applic ation
layer using an object-based security mechanism such as COSE <xref target="RF layer using an object-based security mechanism, such as COSE <xref target="R
C8152"/>. FC8152" format="default"/>.
</t> </t>
<t>
<t>
One application of COSE is OSCORE One application of COSE is OSCORE
<xref target="RFC8613"/>, which provides end-to-end confidentiality, <xref target="RFC8613" format="default"/>, which provides end-to-end confide ntiality,
integrity and replay protection, and a secure binding between CoAP request integrity and replay protection, and a secure binding between CoAP request
and response messages. In OSCORE, the CoAP messages are wrapped in COSE and response messages. In OSCORE, the CoAP messages are wrapped in COSE
objects and sent using CoAP. objects and sent using CoAP.
</t> </t>
<t>In this framework, the use of CoAP as replacement for HTTP is <bcp14>
<t>In this framework the use of CoAP as replacement for HTTP is RECOMMENDED 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"/>, <xref target="I-D.ietf-tls-dtls13"/> and OSCORE <xref target="RFC6347" format="default"/> <xref target="RFC9147" format="defau
<xref target="RFC8613"/> are mentioned as examples, other protocols fulfilling lt"/> and OSCORE
the requirements from <xref target="minimalCommSecReq"/> are also <xref target="RFC8613" format="default"/> are mentioned as examples; other pro
tocols fulfilling
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">
<!-- ***************************************************** --> <name>Protocol Interactions</name>
<section anchor="specs" title="Protocol Interactions"> <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 ca
process the access token locally, however in some cases the RS may present n
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.
These interactions are shown in <xref target="fig:protocolFlow"/>. An These interactions are shown in <xref target="fig_protocolFlow" format="defa
overview of various OAuth concepts is provided in <xref ult"/>. An
target="oauth2Overview"/>. overview of various OAuth concepts is provided in <xref target="oauth2Overvi
ew" format="default"/>.
</t> </t>
<figure anchor="fig_protocolFlow">
<t><figure align="center" anchor="fig:protocolFlow" <name>Basic Protocol Flow</name>
title="Basic Protocol Flow."> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[
+--------+ +---------------+ +--------+ +---------------+
| |---(A)-- Token Request ------->| | | |---(A)-- Token Request ------->| |
| | | Authorization | | | | Authorization |
| |<--(B)-- Access Token ---------| Server | | |<--(B)-- Access Token ---------| Server |
| | + Access Information | | | | + Access Information | |
| | + Refresh Token (optional) +---------------+ | | + Refresh Token (optional) +---------------+
| | ^ | | | ^ |
| | Introspection Request (D)| | | | Introspection Request (D)| |
| Client | Response | |(E) | Client | Response | |(E)
| | (optional exchange) | | | | (optional exchange) | |
| | | v | | | v
| | +--------------+ | | +--------------+
| |---(C)-- Token + Request ----->| | | |---(C)-- Token + Request ----->| |
| | | Resource | | | | Resource |
| |<--(F)-- Protected Resource ---| Server | | |<--(F)-- Protected Resource ---| Server |
| | | | | | | |
+--------+ +--------------+ +--------+ +--------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<dl newline="true" spacing="normal">
<t> <dt>Requesting an Access Token (A):</dt>
<list style="hanging"> <dd>
<t hangText="Requesting an Access Token (A):"><vspace blankLines="0"/> <t>
The client makes an access token request to the token endpoint at the AS. The client makes an access token request to the token endpoint at the AS.
This framework assumes the use of PoP access tokens (see <xref This framework assumes the use of PoP access tokens (see <xref target="oau
target="oauth2Overview"/> for a short description) wherein the AS binds a th2Overview" format="default"/> for a short description) wherein the AS binds a
key to an access token. The client may include permissions it seeks to key to an access token. The client may include permissions it seeks to
obtain, and information about the credentials it wants to use for obtain and information about the credentials it wants to use for
proof-of-possession (e.g., symmetric/asymmetric cryptography or a proof of possession (e.g., symmetric/asymmetric cryptography or a
reference to a specific key) of the access token.<vspace blankLines="1"/> reference to a specific key) of the access token.</t>
</t> </dd>
<dt>Access Token Response (B):</dt>
<t hangText="Access Token Response (B):"><vspace blankLines="0"/> <dd>
<t>
If the request from the client has been successfully verified, If the request from the client has been successfully verified,
authenticated, and authorized, the AS returns an access token and optional ly a refresh authenticated, and authorized, the AS returns an access token and optional ly a refresh
token. Note that only certain grant types support refresh tokens. The AS token. Note that only certain grant types support refresh tokens. The AS
can also return additional parameters, referred to as "Access can also return additional parameters, referred to as "Access
Information". In addition to the response parameters defined by OAuth Information". In addition to the response parameters defined by OAuth
2.0 and the PoP access token extension, this framework defines parameters 2.0 and the PoP access token extension, this framework defines parameters
that can be used to inform the client about capabilities of the RS, e.g. that can be used to inform the client about capabilities of the RS, e.g.,
the profile the RS supports. More information about these parameters the profile the RS supports. More information about these parameters
can be found in <xref target="tokenParams"/>. can be found in <xref target="tokenParams" format="default"/>.
<vspace blankLines="1"/> </t>
</t> </dd>
<dt>Resource Request (C):</dt>
<t hangText="Resource Request (C):"><vspace blankLines="0"/> <dd>
<t>
The client interacts with the RS to request access to the protected The client interacts with the RS to request access to the protected
resource and provides the access token. The protocol to use resource and provides the access token. The protocol to use
between the client and the RS is not restricted to CoAP. HTTP, HTTP/2 between the client and the RS is not restricted to CoAP. HTTP, HTTP/2
<xref target="RFC7540"/>, QUIC <xref target="I-D.ietf-quic-transport"/>, <xref target="RFC7540" format="default"/>, QUIC <xref target="RFC9000" for
MQTT <xref target="MQTT5.0"/>, Bluetooth Low Energy <xref target="BLE"/>, mat="default"/>,
MQTT <xref target="MQTT5.0" format="default"/>, Bluetooth Low Energy <xref
target="BLE" format="default"/>,
etc., are also viable candidates. etc., are also viable candidates.
<vspace blankLines="1"/> </t>
<t>
Depending on the device limitations and the selected protocol, this Depending on the device limitations and the selected protocol, this
exchange may be split up into two parts: exchange may be split up into two parts:</t>
<ol type="(%d)" spacing="normal">
<list style="empty"> <li>the client sends the access token containing, or referencing, th
<t>(1) the client sends the access token containing, or referencing, the e
authorization information to the RS, that will be used for subsequent authorization information to the RS that will be used for subsequent
resource requests by the client, and </t> resource requests by the client, and </li>
<li>the client makes the resource access request using the communica
<t>(2) the client makes the resource access request, using the communication tion
security protocol and other Access Information obtained from the AS.</t> security protocol and other Access Information obtained from the AS.</li>
</list> </ol>
<t>
<vspace blankLines="1"/>
The client and the RS mutually authenticate using the security protocol The client and the RS mutually authenticate using the security protocol
specified in the profile (see step B) and the keys obtained in the access specified in the profile (see step (B)) and the keys obtained in the acces s
token or the Access Information. The RS verifies that the token is token or the Access Information. The RS verifies that the token is
integrity protected and originated by the AS. It then compares the claims integrity protected and originated by the AS. It then compares the claims
contained in the access token with the resource request. If the RS is contained in the access token with the resource request. If the RS is
online, validation can be handed over to the AS using token introspection online, validation can be handed over to the AS using token introspection
(see messages D and E) over HTTP or CoAP.<vspace blankLines="1"/> (see messages (D) and (E)) over HTTP or CoAP.</t>
</t> </dd>
<dt>Token Introspection Request (D):</dt>
<t hangText="Token Introspection Request (D):"><vspace blankLines="0"/> <dd>
<t>
A resource server may be configured to introspect the access token by A resource server may be configured to introspect the access token by
including it in a request to the introspection endpoint at that AS. including it in a request to the introspection endpoint at that AS.
Token introspection over Token introspection over
CoAP is defined in <xref target="introspectionEndpoint"/> and for HTTP in CoAP is defined in <xref target="introspectionEndpoint" format="default"/>
<xref target="RFC7662"/>. and for HTTP in
<vspace blankLines="1"/> <xref target="RFC7662" format="default"/>.
</t>
<t>
Note that token introspection is an optional step and can be omitted if Note that token introspection is an optional step and can be omitted if
the token is self-contained and the resource server is prepared to the token is self-contained and the resource server is prepared to
perform the token validation on its own.<vspace blankLines="1"/> perform the token validation on its own.</t>
</t> </dd>
<dt>Token Introspection Response (E):</dt>
<t hangText="Token Introspection Response (E):"><vspace blankLines="0"/> <dd>
<t>
The AS validates the token and returns the most recent parameters, such The AS validates the token and returns the most recent parameters, such
as scope, audience, validity etc. associated with it back to the RS. The as scope, audience, validity, etc., associated with it back to the RS. Th e
RS then uses the received parameters to process the request to either RS then uses the received parameters to process the request to either
accept or to deny it.<vspace blankLines="1"/> accept or to deny it.</t>
</t> </dd>
<dt>Protected Resource (F):</dt>
<t hangText="Protected Resource (F):"><vspace blankLines="0"/> <dd>
If the request from the client is authorized, the RS fulfills the request If the request from the client is authorized, the RS fulfills the request
and returns a response with the appropriate response code. The RS uses and returns a response with the appropriate response code. The RS uses
the dynamically established keys to protect the response, according to the dynamically established keys to protect the response according to
the communication security protocol used. the communication security protocol used.
</t> </dd>
</list> </dl>
</t> <t>The OAuth 2.0 framework defines a number of "protocol flows" via grant
types,
which have been extended
further with extensions to OAuth 2.0 (such as <xref target="RFC7521"
format="default"/> and <xref target="RFC8628" format="default"/>).
What grant type works best depends on the usage scenario; <xref
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
authorization code grant (described in <xref target="RFC7521" format="defa
ult"
sectionFormat="of" section="4.1"/>) and
<t>The OAuth 2.0 framework defines a number of "protocol flows" via grant types, <!--[rfced] Citations
which have been extended
further with extensions to OAuth 2.0 (such as <xref target="RFC7521"/> and <xref
target="RFC8628"/>).
What grant type works best depends on the usage scenario and <xref target="RFC77
44"/> describes many different IoT use cases but there are two grant types that
cover a majority of these scenarios, namely the Authorization Code Grant (descri
bed in Section 4.1 of <xref target="RFC7521"/>) and the Client Credentials Grant
(described in Section 4.4 of <xref target="RFC7521"/>). The Authorization Code
Grant is a good fit for use with apps running on smart phones and tablets that r
equest access to IoT devices, a common scenario in the smart home environment, w
here users need to go through an authentication and authorization phase (at leas
t during the initial setup phase). The native apps guidelines described in <xref
target="RFC8252"/> are applicable to this use case. The Client Credential Grant
is a good fit for use with IoT devices where the OAuth client itself is constra
ined. In such a case, the resource owner has pre-arranged access rights for the
client with the authorization server, which is often accomplished using a commis
sioning tool.</t>
<t> 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 authori
zation
code grant is a good fit for use with apps running on smartphones and tabl
ets that request access to IoT devices, a common scenario in the smart home envi
ronment, where users need to go through an authentication and authorization phas
e (at least during the initial setup phase). The native apps guidelines describe
d 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 OA
uth client itself is constrained. In such a case, the resource owner has prearra
nged access rights for the client with the authorization server, which is often
accomplished using a commissioning tool.</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 traditional OAuth flows, or it
could be pre-configured 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 owner and the requesting party (i.e., client owner) are not shown in <xref t
target="fig:protocolFlow"/>. arget="fig_protocolFlow" format="default"/>.
</t> </t>
<t>
<t> This framework supports a wide variety of communication security mechanis
This framework supports a wide variety of communication security mechanisms ms
between the ACE entities, such as 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 defi registered (also called enrolled or onboarded) to an AS using a mechanism
ned outside the scope of this document. defined
In practice, various techniques for onboarding have been used, such as factory outside the scope of this document.
-based provisioning or the use of In practice, various techniques for onboarding have been used, such as
commissioning tools. Regardless of the onboarding technique, this provisioning factory-based provisioning or the use of
procedure implies that the client and the AS exchange credentials and commissioning tools. Regardless of the onboarding technique, this provisi
configuration parameters. These credentials are used to mutually authenticate oning
each other and to protect messages exchanged between the client and the AS.</t> procedure implies that the client and the AS exchange credentials and
configuration parameters. These credentials are used to mutually authent
<t>It is also assumed that the RS has been registered with the AS, potentially icate each
in a similar way as the client has been registered with the AS. other and to protect messages exchanged between the client and the AS.</
t>
<t>It is also assumed that the RS has been registered with the AS, potenti
ally in a similar way as the client has been registered with the AS.
Established keying material between the AS and the RS allows the AS to apply Established keying material between the AS and the RS allows the AS to apply
cryptographic protection to the access token to ensure that its content cannot cryptographic protection to the access token to ensure that its content cannot
be modified, and if needed, that the content is confidentiality protected. Conf identiality protection of the access token content would be provided on top of be modified and, if needed, that the content is confidentiality protected. Conf identiality protection of the access token content would be provided on top of
confidentiality protection via a communication security protocol. </t> confidentiality protection via a communication security protocol. </t>
<t>The keying material necessary for establishing communication security
<t>The keying material necessary for establishing communication security between the C and RS is dynamically established as part of the protocol descri
between C and RS is dynamically established as part of the protocol described bed
in this document. in this document.
</t> </t>
<t>
<t>
At the start of the protocol, there is an optional discovery step where the At the start of the protocol, there is an optional discovery step where the
client discovers the resource server and the resources this server hosts. client discovers the resource server and the resources this server hosts.
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 access the protected resource. A generic procedure is described in <xref ta
target="asDiscovery"/>; profiles MAY define other procedures for rget="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"/>. standardized format, as described in <xref target="RFC6690" format="default" />.
</t> </t>
</section> </section>
<!-- ***************************************************** -->
<!-- ***************************************************** -->
<section anchor="oauthProfile" title="Framework">
<t>The following sections detail the profiling and extensions of OAuth 2.0 <section anchor="oauthProfile" numbered="true" toc="default">
<name>Framework</name>
<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">
<t> <dt>Credential Provisioning</dt>
<list style="hanging"> <dd>
<t hangText="Credential Provisioning"><vspace blankLines="0"/> <t>
In constrained environments it cannot be assumed that the client and the In constrained environments, it cannot be assumed that the client and th
RS e RS
are part of a common key infrastructure. Therefore, the AS provisions are part of a common key infrastructure. Therefore, the AS provisions
credentials and associated information to allow mutual authentication credentials and associated information to allow mutual authentication
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.
<vspace blankLines="1"/> </t>
</t> </dd>
<dt>Proof of Possession</dt>
<t hangText="Proof-of-Possession"><vspace blankLines="0"/> <dd>
The ACE framework, by default, implements proof-of-possession for <t>
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" claim the key bound to the token. The binding is provided by the "cnf" (confir
<xref target="RFC8747"/> indicating what key is used for mation)
proof-of-possession. If a client needs to submit a new access token, claim
<xref target="RFC8747" format="default"/>, indicating what key is used fo
r
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.
<vspace blankLines="1"/> </t>
</t> </dd>
<dt>ACE Profiles</dt>
<t hangText="ACE Profiles"><vspace blankLines="0"/> <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 client and RS are defined in an ACE specific interactions between the client and RS are defined in an ACE
profile. In ACE framework the AS is expected to manage the matching profile. In the ACE framework, the AS is expected to manage the matchin
g
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 "ace_profile"
parameter in the token response. parameter in the token response.
</t> </dd>
</list> </dl>
</t> <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 a
<t>OAuth 2.0 requires the use of TLS both to protect the communication nd RS
between AS and client when requesting an access token; between client and RS when accessing a resource and between the AS and RS if introspection is used.
when accessing a resource and between 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 abov
Nevertheless it is REQUIRED that the communications named above are e are
encrypted, integrity protected and protected against message replay. It is encrypted, integrity protected, and protected against message replay. It is
also REQUIRED that the communicating endpoints perform mutual authentication. also <bcp14>REQUIRED</bcp14> that the communicating endpoints perform mutual a
Furthermore it MUST be assured that responses are bound to the requests in uthentication.
Furthermore, it <bcp14>MUST</bcp14> be assured that responses are bound to the
requests in
the sense that the receiver of a response can be certain that the response the sense that the receiver of a response can be certain that the response
actually belongs to a certain request. Note that setting up such a secure actually belongs to a certain request. Note that setting up such a secure
communication may require some unprotected messages to be exchanged first communication may require some unprotected messages to be exchanged first
(e.g. sending the token from the client to the RS).</t> (e.g., sending the token from the client to the RS).</t>
<t>Profiles <bcp14>MUST</bcp14> specify a communication security protocol
<t>Profiles MUST specify a communication security protocol between client between the
and RS that provides the features required above. Profiles MUST specify a client and RS that provides the features required above. Profiles
communication security protocol RECOMMENDED to be used between client and AS <bcp14>MUST</bcp14> specify a
that provides the features required above. Profiles MUST specify for communication security protocol <bcp14>RECOMMENDED</bcp14> to be used betw
introspection a communication security protocol RECOMMENDED to be used een the
between RS and AS that provides the features required above. These client and AS that provides the features required above. Profiles <bcp14>
recommendations enable interoperability between different implementations MUST</bcp14>
without the need to define a new profile if the communication between C and specify, for introspection, a communication security protocol
AS, or between RS and AS, is protected with a different security protocol <bcp14>RECOMMENDED</bcp14> to be used
complying with the security requirements above.</t> between the RS and AS that provides the features required above. These
recommendations enable interoperability between different implementations
<t>In OAuth 2.0 the communication with the Token and the Introspection without the need to define a new profile if the communication between the
C and
AS, or between the RS and AS, is protected with a different security proto
col
complying with the security requirements above.</t>
<t>In OAuth 2.0, the communication with the Token and the Introspection
endpoints at the AS is assumed to be via HTTP and may use Uri-query endpoints at the AS is assumed to be via HTTP and may use Uri-query
parameters. When profiles of this framework use CoAP instead, it is parameters. When profiles of this framework use CoAP instead, it is
REQUIRED to use of the following alternative instead of Uri-query <bcp14>REQUIRED</bcp14> to use of the following alternative instead of Uri-que ry
parameters: The sender (client or RS) encodes the parameters of its request parameters: The sender (client or RS) encodes the parameters of its request
as a CBOR map and submits that map as the payload of the POST request. as a CBOR map and submits that map as the payload of the POST request.
The CBOR encoding for a number of OAuth 2.0 parameters is specified in this The CBOR encoding for a number of OAuth 2.0 parameters is specified in this
document, if a profile needs to use other OAuth 2.0 parameters with CoAP it document; if a profile needs to use other OAuth 2.0 parameters with CoAP, it
MUST specify their CBOR encoding.</t> <bcp14>MUST</bcp14> specify their CBOR encoding.</t>
<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 "applicati
outermost encoding layer MUST use the content format 'application/ace+cbor'. on/ace+cbor".
If CoAP is used for communication, the Content-Format MUST be abbreviated If CoAP is used for communication, the Content-Format <bcp14>MUST</bcp14> be a
with the ID: 19 (see <xref target="IANAcoapContentFormat"/>).</t> bbreviated
with the ID: 19 (see <xref target="IANAcoapContentFormat" format="default"/>).
<t>The OAuth 2.0 AS uses a JSON structure in the payload of its responses </t>
both to client and RS. If CoAP is used, it is REQUIRED to use <t>The OAuth 2.0 AS uses a JSON structure in the payload of its responses
CBOR <xref target="RFC8949"/> instead of JSON. Depending on the profile, both to the client and RS. If CoAP is used, it is <bcp14>REQUIRED</bcp14> to
the CBOR payload MAY be enclosed in a non-CBOR cryptographic wrapper.</t> use
CBOR <xref target="RFC8949" format="default"/> instead of JSON. Depending on
<section anchor="asDiscovery" title="Discovering Authorization Servers"> the profile,
<t>C must discover the AS in charge of RS to determine where to request the the CBOR payload <bcp14>MAY</bcp14> be enclosed in a non-CBOR cryptographic wr
access token. To do so, C must 1. find out the AS URI to which the token apper.</t>
request message must be sent and 2. MUST validate that the AS with this <section anchor="asDiscovery" numbered="true" toc="default">
<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
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 wit
h 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 i
<t> In order to determine the AS URI, C MAY send an initial Unauthorized nitial Unauthorized
Resource Request message to RS. 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 C (see <xref target="rreq"/>). How C validates the the address of its AS back to the C (see <xref target="rreq" format="default"/>)
AS authorization is not in scope for this document. C may, e.g., ask . How the C validates the
its owner if this AS is authorized for this RS. C may also use a AS authorization is not in scope for this document. The C may, for example, ask
mechanism that addresses both problems at once (e.g. by querying a dedicated sec its owner if this AS is authorized for this RS. The C may also use a
ure service provided by the client owner) .</t> mechanism that addresses both problems at once (e.g., by querying a dedicated se
cure service provided by the client owner) .</t>
</section><!--AS Discovery --> </section>
<!--AS Discovery -->
<section anchor="rreq" title="Unauthorized Resource Request Message">
<t>An Unauthorized Resource Request message is a request for any
resource hosted by RS for which the client does not have authorization grant
ed. RSes MUST
treat any request for a protected resource as an Unauthorized Resource
Request message when any of the following hold:
<list style="symbols">
<t>The request has been received on an unsecured channel.</t>
<t>The RS has no valid access token for the sender of the request
regarding the requested action on that resource.</t>
<t>The RS has a valid access token for the sender of the request, but
that token does not authorize the requested action on the requested
resource.</t>
</list>
</t>
<t>Note: These conditions ensure that the RS can handle requests autonomousl
y
once access was granted and a secure channel has been established between C
and RS. The authz-info endpoint, as part of the process for authorizing
to protected resources, is not itself a protected resource and MUST NOT be
protected as specified above (cf. <xref
target="tokenAuthInfoEndpoint"/>).</t>
<t>Unauthorized Resource Request messages MUST be denied with an "unauthoriz
ed_client"
error response. In this response, the Resource Server SHOULD provide proper
"AS Request Creation Hints" to enable the client to request an access token
from RS's AS as described in <xref target="asInfo"/>.</t>
<t>The handling of all client requests (including unauthorized ones)
by the RS is described in <xref target="requestC2RS"/>.</t>
</section><!-- Unauthorized Request -->
<section anchor="asInfo" title="AS Request Creation Hints"> <section anchor="rreq" numbered="true" toc="default">
<t>The "AS Request Creation Hints" message is sent by an RS as a response to <name>Unauthorized Resource Request Message</name>
an Unauthorized Resource Request message (see <xref target="rreq"/>) to help <t>An Unauthorized Resource Request message is a request for any
the sender of the Unauthorized Resource Request message acquire a valid resource hosted by the RS for which the client does not have authorizatio
access token. The "AS Request Creation Hints" message is a CBOR or JSON map, n granted.
with an OPTIONAL element "AS" specifying an absolute URI (see Section 4.3 The RSs <bcp14>MUST</bcp14>
of <xref target="RFC3986"/>) that identifies the appropriate AS for the treat any request for a protected resource as an Unauthorized Resource
RS.</t> Request message when any of the following hold:
</t>
<ul spacing="normal">
<li>The request has been received on an unsecured channel.</li>
<li>The RS has no valid access token for the sender of the request
regarding the requested action on that resource.</li>
<li>The RS has a valid access token for the sender of the request, but
that token does not authorize the requested action on the requested
resource.</li>
</ul>
<t>Note: These conditions ensure that the RS can handle requests autonom
ously
once access was granted and a secure channel has been established between
the C
and RS. The authz-info endpoint, as part of the process for authorizing
to protected resources, is not itself a protected resource and <bcp14>MUS
T
NOT</bcp14> be protected as specified above (cf. <xref
target="tokenAuthInfoEndpoint" format="default"/>).</t>
<t>Unauthorized Resource Request messages <bcp14>MUST</bcp14> be denied
with an
"unauthorized_client" error response. In this response, the resource serv
er
<bcp14>SHOULD</bcp14> provide proper
"AS Request Creation Hints" to enable the client to request an access tok
en
from the RS's AS, as described in <xref target="asInfo" format="default"/
>.</t>
<t>The handling of all client requests (including unauthorized ones)
by the RS is described in <xref target="requestC2RS" format="default"/>.</t>
</section>
<!-- Unauthorized Request -->
<t>The message can also contain the following OPTIONAL parameters: <section anchor="asInfo" numbered="true" toc="default">
<list style="symbols"> <name>AS Request Creation Hints</name>
<t>A "audience" element contains an identifier the client <t>The "AS Request Creation Hints" message is sent by an RS as a respons
e to
an Unauthorized Resource Request message (see <xref target="rreq"
format="default"/>) to help
the sender of the Unauthorized Resource Request message acquire a valid
access token. The "AS Request Creation Hints" message is a CBOR or JSON m
ap,
with an <bcp14>OPTIONAL</bcp14> element "AS" specifying an absolute URI (
see
<xref target="RFC3986" sectionFormat="of" section="4.3"/>) that identifie
s the
appropriate AS for the RS.</t>
<t>The message can also contain the following <bcp14>OPTIONAL</bcp14>
parameters:</t>
<ul spacing="normal">
<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 access token to specific RSs. See restrict the use of the access token to specific RSs. See
<xref target="audience"/> for a discussion of this parameter.</t> <xref target="audience" format="default"/> for a discussion of this parame
<t>A "kid" element containing the key identifier of a key used in ter.</li>
an existing security association between the client and the RS. <li>A "kid" (key identifier) element contains the key identifier of a
The RS expects the client to request an access token bound to this key used in
key, in order to avoid having to re-establish the security an existing security association between the client and the RS.
association.</t> The RS expects the client to request an access token bound to this
<t>A "cnonce" element containing a client-nonce. See <xref key in order to avoid having to reestablish the security
target="cnonceParam"/>.</t> association.</li>
<t>A "scope" element containing the suggested scope that the client <li>A "cnonce" element contains a client-nonce. See <xref target="cnon
should request towards the AS.</t> ceParam"
</list></t> format="default"/>.</li>
<li>A "scope" element contains the suggested scope that the client
<t><xref target="fig:asinfo"/> summarizes the parameters that may be should request towards the AS.</li>
part of the "AS Request Creation Hints". </ul>
<t><xref target="table_asinfo" format="default"/> summarizes the paramet
<figure align="center" anchor="fig:asinfo" ers that may
title="AS Request Creation Hints"> be part of the "AS Request Creation Hints".</t>
<artwork align="left"><![CDATA[ <table anchor="table_asinfo">
/-----------+----------+---------------------\ <name>AS Request Creation Hints</name>
| Name | CBOR Key | Value Type | <thead>
|-----------+----------+---------------------| <tr>
| AS | 1 | text string | <th>Name</th>
| kid | 2 | byte string | <th>CBOR Key</th>
| audience | 5 | text string | <th>Value Type</th>
| scope | 9 | text or byte string | </tr>
| cnonce | 39 | byte string | </thead>
\-----------+----------+---------------------/ <tbody>
]]></artwork></figure></t> <tr>
<td>AS</td>
<t>Note that the schema part of the AS parameter may need to be <td>1</td>
<td>text string</td>
</tr>
<tr>
<td>kid</td>
<td>2</td>
<td>byte string</td>
</tr>
<tr>
<td>audience</td>
<td>5</td>
<td>text string</td>
</tr>
<tr>
<td>scope</td>
<td>9</td>
<td>text or byte string</td>
</tr>
<tr>
<td>cnonce</td>
<td>39</td>
<td>byte string</td>
</tr>
</tbody>
</table>
<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 exampl
<t><xref target="fig:as-info-payload"/> shows an example for an "AS e for an "AS
Request Creation Hints" message payload using CBOR <xref target="RFC8949"/> Request Creation Hints" message payload using CBOR <xref target="RFC8949" fo
rmat="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
<figure title="AS Request Creation Hints payload example" in the XML file to ensure correctness. If the current list of preferred
anchor="fig:as-info-payload"><artwork><![CDATA[ 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">
<name>AS Request Creation Hints Payload Example</name>
<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'
} }
]]></artwork></figure> ]]></sourcecode>
</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
can not reliably verify the expiration time of access tokens it receives. cannot reliably verify the expiration time of access tokens it receives.
To ensure a certain level of access token freshness nevertheless, the RS has Nevertheless, to ensure a certain level of access token freshness, the RS ha
included a <spanx style="verb">cnonce</spanx> parameter (see <xref s
target="cnonceParam"/>) in the response. (The hex-sequence of the cnonce par included a <tt>cnonce</tt> parameter (see <xref target="cnonceParam" format=
ameter "default"/>) in the response. (The hex sequence of the cnonce 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 ma
<t><xref target="fig:as-info-cbor"/> illustrates the mandatory to use ndatory use
binary encoding of the message payload shown in of binary encoding of the message payload shown in
<xref target="fig:as-info-payload"/>.</t> <xref target="fig_as-info-payload" format="default"/>.</t>
<figure anchor="fig_as-info-cbor">
<figure title="AS Request Creation Hints example encoded in CBOR" <name>AS Request Creation Hints Example Encoded in CBOR</name>
anchor="fig:as-info-cbor"><artwork><![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)
636f6170733a2f2f61732e657861 636f6170733a2f2f61732e657861
6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token" 6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token"
05 # unsigned(5) (=audience) 05 # unsigned(5) (=audience)
76 # text(22) 76 # text(22)
636f6170733a2f2f72732e657861 636f6170733a2f2f72732e657861
6d706c652e636f6d # "coaps://rs.example.com" 6d706c652e636f6d # "coaps://rs.example.com"
09 # unsigned(9) (=scope) 09 # unsigned(9) (=scope)
66 # text(6) 66 # text(6)
7254656d7043 # "rTempC" 7254656d7043 # "rTempC"
18 27 # unsigned(39) (=cnonce) 18 27 # unsigned(39) (=cnonce)
45 # bytes(5) 45 # bytes(5)
e0a156bb3f # e0a156bb3f #
]]></artwork></figure> ]]></sourcecode>
</figure>
<section anchor="cnonceParam" title="The Client-Nonce Parameter"> <section anchor="cnonceParam" numbered="true" toc="default">
<t>If the RS does not synchronize its clock with the AS, it could be <name>The Client-Nonce Parameter</name>
tricked into accepting old access tokens, that are either expired or have <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
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 "cnonce" (client-nonce) parameter.
The processing requirements for this parameter are as follows: The processing requirements for this parameter are as follows:
<list style="symbols"> </t>
<t>An RS sending a "cnonce" parameter in an "AS Request Creation <ul spacing="normal">
Hints" message MUST store information to validate that a given <li>An RS sending a "cnonce" parameter in an "AS Request Creation
cnonce is fresh. How this is implemented internally is out of scope Hints" message <bcp14>MUST</bcp14> store information to validate that
for this specification. Expiration of client-nonces should be based a given
roughly on the time it would take a client to obtain an access token cnonce is fresh. How this is implemented internally is out of scope
after receiving the "AS Request Creation Hints" message, with some for this specification. Expiration of client-nonces should be based
allowance for unexpected delays.</t> roughly on the time it would take a client to obtain an access token
after receiving the "AS Request Creation Hints" message, with some
<t>A client receiving a "cnonce" parameter in an "AS Request Creation allowance for unexpected delays.</li>
Hints" message MUST include this in the parameters when requesting <li>A client receiving a "cnonce" parameter in an "AS Request Creati
an access token at the AS, using the "cnonce" parameter from on
<xref target="cnonceParamToken"/>.</t> Hints" message <bcp14>MUST</bcp14> include this in the parameters whe
n
<t>If an AS grants an access token request containing a "cnonce" requesting an access token at the AS, using the "cnonce" parameter fr
parameter, it MUST include this value in the access token, using the om
"cnonce" claim specified in <xref target="accessToken"/>.</t> <xref target="cnonceParamToken" format="default"/>.</li>
<li>If an AS grants an access token request containing a "cnonce"
<t>An RS that is using the client-nonce mechanism and that receives an parameter, it <bcp14>MUST</bcp14> include this value in the access to
access token MUST verify that this token contains a cnonce claim, with ken, using
a client-nonce value that is fresh according to the information stored the "cnonce" claim specified in <xref target="accessToken"
at the first step above. If the cnonce claim is not present or if the format="default"/>.</li>
cnonce claim value is not fresh, the RS MUST discard the access token. <li>An RS that is using the client-nonce mechanism and that receives
If this was an interaction with the authz-info endpoint the RS MUST also an
respond with an error message using a response code equivalent to the access token <bcp14>MUST</bcp14> verify that this token contains a cn
CoAP code 4.01 (Unauthorized).</t> once
</list> claim, with
</t> a client-nonce value that is fresh according to the information store
</section> d
</section><!--AS information--> at the first step above. If the cnonce claim is not present or if th
e
cnonce claim value is not fresh, the RS <bcp14>MUST</bcp14> discard t
he access
token. If this was an interaction with the authz-info endpoint, the R
S
<bcp14>MUST</bcp14> also
respond with an error message using a response code equivalent to the
CoAP code 4.01 (Unauthorized).</li>
</ul>
</section>
</section>
<!--AS information-->
<section anchor="authorizationGrants" title="Authorization Grants"> <section anchor="authorizationGrants" numbered="true" toc="default">
<t>To request an access token, the client obtains authorization from the <name>Authorization Grants</name>
<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
<t>The OAuth framework <xref target="RFC6749"/> defines four grant types. The four grant types. The grant types can
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 <xref (client credentials). Further grant types have been added later, such as an as
target="RFC7521"/> defining an assertion-based authorization grant.</t> sertion-based authorization grant defined in <xref target="RFC7521" format="defa
ult"/>.</t>
<t>The grant type is selected depending on the use case. In cases where <t>The grant type is selected depending on the use case. In cases where
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, i t is but does not have any display or has very limited interaction possibilities, i t is
recommended to use the device code grant defined in recommended to use the device code grant defined in
<xref target="RFC8628"/>. 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"
<t>For details on the different grant types, see section 1.3 of <xref sectionFormat="of" section="1.3"/>. The OAuth 2.0 framework provides an extensio
target="RFC6749"/>. The OAuth 2.0 framework provides an extension n
mechanism for defining additional grant types, so profiles of this framework mechanism for defining additional grant types, so profiles of this framework
MAY define additional grant types, if needed.</t> <bcp14>MAY</bcp14> define additional grant types, if needed.</t>
</section> <!--Grants--> </section>
<!--Grants-->
<section anchor="clientCredentials" title="Client Credentials"> <section anchor="clientCredentials" numbered="true" toc="default">
<t>Authentication of the client is mandatory independent of the grant type <name>Client Credentials</name>
<t>Authentication of the client is mandatory independent of the grant ty
pe
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 cli
<t>Client registration and provisioning of client credentials to the client ent
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 one client credential type in section 2.3.1 of <xref target="RFC6749" sectionFormat="of" section="2.3.1"/>: client id and cli
<xref target="RFC6749"/>: client id and client secret. <xref ent secret. <xref target="I-D.erdtman-oauth-rpcc" format="default"/> adds raw pu
target="I-D.erdtman-ace-rpcc"/> adds raw-public-key and pre-shared-key to the blic key and pre-shared key to the
client credentials types. Profiles of this framework MAY extend with client credentials types. Profiles of this framework <bcp14>MAY</bcp14> exten
d with
an additional client credentials type using client certificates.</t> an additional client credentials type using client certificates.</t>
</section> <!--Client Credentials--> </section>
<!--Client Credentials-->
<section anchor="ASAuthentication" title="AS Authentication"> <section anchor="ASAuthentication" numbered="true" toc="default">
<t>The client credential grant does not, by default, authenticate the AS that <name>AS Authentication</name>
the client <t>The client credentials grant does not, by default, authenticate the A
S 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 au
<t>Profiles of this framework MUST specify how clients authenticate the AS thenticate 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> <!--AS Authentication--> </section>
<!--AS Authentication-->
<section anchor="authorizeEndpoint" title="The Authorization Endpoint"> <section anchor="authorizeEndpoint" numbered="true" toc="default">
<t>The OAuth 2.0 authorization endpoint is used to interact with the resource <name>The Authorization Endpoint</name>
owner <t>The OAuth 2.0 authorization endpoint is used to interact with the res
and obtain an authorization grant, in certain grant flows. The primary use ource owner
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 d o not involve case for the ACE-OAuth framework is for machine-to-machine interactions that d o 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. Non-constrained clients interacting mechanisms for this endpoint as well. Nonconstrained clients interacting
with constrained resource servers can use the specification in section 3.1 with constrained resource servers can use the specification in
of <xref target="RFC6749"/> and the attack countermeasures suggested in <xref target="RFC6749" sectionFormat="of" section="3.1"/> and the attack count
section 4.2 of <xref target="RFC6819"/>.</t> ermeasures suggested in
</section> <!--The 'Authorize' Endpoint--> <xref target="RFC6819" sectionFormat="of" section="4.2"/>.</t>
</section>
<!--The 'Authorize' Endpoint-->
<section anchor="tokenEndpoint" title="The Token Endpoint"> <section anchor="tokenEndpoint" numbered="true" toc="default">
<t>In standard OAuth 2.0, the AS provides the token endpoint for submitting <name>The Token Endpoint</name>
<t>In standard OAuth 2.0, the AS provides the token endpoint for submitt
ing
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 to token endpoint, giving the AS the possibility to help the client and RS
establish shared keys or to 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
even other transports. A profile <bcp14>MUST</bcp14> define the details of th
e mapping
between the fields described below and these transports.
<t>The endpoint may also be exposed over HTTPS as in classical OAuth or <!--[rfced] *AD, please review and let us know if you approve this change.
even other transports. A profile MUST define the details of the mapping FYI, this text in Section 5.8 has been updated as follows per mail from
between the fields described below, and these transports. If HTTPS is used, G. Selander 2022-02-03. (In addition, we have inserted the word "the"
the semantics of Sections 4.1.3 and 4.1.4 of the OAuth 2.0 specification MUST before "payload format".)
be followed (with additions as described below). If the CoAP is some other
transport with CBOR payload format is supported, the semantics described in
this section MUST be followed.</t>
<t>For the AS to be able to issue a token, the client MUST be authenticated Original:
and present a valid grant for the scopes requested. Profiles of this If HTTPS is used, the semantics of Sections 4.1.3 and 4.1.4 of the OAuth
framework MUST specify how the AS authenticates the client and how the 2.0 specification MUST be followed (with additions as described
communication between client and AS is protected, fulfilling the below). If the CoAP is some other transport with CBOR payload format
requirements specified in <xref target="oauthProfile"/>.</t> is supported, the semantics described in this section MUST be
followed.
<t>The default name of this endpoint in an url-path SHOULD be '/token'. Current:
If HTTPS with JSON is used, the semantics of Sections 4.1.3 and 4.1.4 of
the OAuth 2.0 specification [RFC6749] MUST be followed (with
additions as described below). If CBOR is used as the payload
format, the semantics described in this section MUST be followed.
-->
If HTTPS with JSON is used,
the semantics of Sections <xref target="RFC6749" section="4.1.3" sectionFormat
="bare"/> and <xref target="RFC6749" section="4.1.4" sectionFormat="bare"/> of t
he OAuth 2.0 specification <xref target="RFC6749" format="default"/> <bcp14>MUST
</bcp14>
be followed (with additions as described below). If CBOR is used as the paylo
ad format, the semantics described in this
section <bcp14>MUST</bcp14> be followed.</t>
<t>For the AS to be able to issue a token, the client <bcp14>MUST</bcp14
> be authenticated
and present a valid grant for the scopes requested. Profiles of this
framework <bcp14>MUST</bcp14> specify how the AS authenticates the client and
how the
communication between the client and AS is protected, fulfilling the
requirements specified in <xref target="oauthProfile" format="default"/>.</t>
<t>The default name of this endpoint in a url-path <bcp14>SHOULD</bcp14>
be '/token'.
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>
<t>The figures of this section use CBOR diagnostic
<t>The figures of this section use CBOR diagnostic
notation without the integer abbreviations for the parameters or their notation without the integer abbreviations for the parameters or their
values for illustrative purposes. Note that implementations MUST use the values for illustrative purposes. Note that implementations <bcp14>MUST</bcp14
integer abbreviations and the binary CBOR encoding, if the CBOR encoding is us > use the
ed.</t> integer abbreviations and the binary CBOR encoding if the CBOR encoding is use
d.</t>
<section anchor="tokenRequest" title="Client-to-AS Request"> <section anchor="tokenRequest" numbered="true" toc="default">
<t>The client sends a POST request to the token endpoint <name>Client-to-AS Request</name>
at the AS. The profile MUST specify how the communication is protected. <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.
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 4 of the OAuth 2.0 specification in the relevant subsection of Section <xref target="RFC6749" section="4" sec
<xref target="RFC6749"/>, depending on the grant type, with the following tionFormat="bare"/> of the OAuth 2.0 specification
<xref target="RFC6749" format="default"/>, depending on the grant type, with
the following
exceptions and additions: exceptions and additions:
</t>
<list style="symbols"> <ul spacing="normal">
<t>The parameter "grant_type" is OPTIONAL in the context of this <li>The parameter "grant_type" is <bcp14>OPTIONAL</bcp14> in the con
framework (as opposed to REQUIRED in RFC6749). If that parameter is text
missing, the default value "client_credentials" is implied.</t> of this framework (as opposed to <bcp14>REQUIRED</bcp14> in <xref
<t>The "audience" parameter from <xref target="RFC8693"/> is OPTIONAL to target="RFC6749" format="default"/>). If that parameter is
request an access token bound to a specific audience.</t> missing, the default value "client_credentials" is implied.</li>
<t>The "cnonce" parameter defined in <xref target="cnonceParamToken"/> is <li>The "audience" parameter from <xref target="RFC8693"
REQUIRED if the RS provided a client-nonce in the "AS Request Creation format="default"/> is <bcp14>OPTIONAL</bcp14> to
Hints" message <xref target="asInfo"/></t> request an access token bound to a specific audience.</li>
<t>The "scope" parameter MAY be encoded as a byte string instead of <li>The "cnonce" parameter defined in <xref target="cnonceParamToken
the string encoding specified in section 3.3 of <xref target="RFC6749"/>, "
in order allow compact encoding of complex scopes. The syntax of format="default"/> is
such a binary encoding is explicitly not specified here and left <bcp14>REQUIRED</bcp14> if the RS provided a client-nonce in the "AS
to profiles or applications. Note specifically that a binary encoded Request Creation
scope does not necessarily use the space character '0x20' to delimit Hints" message (<xref target="asInfo" format="default"/>).</li>
scope-tokens.</t> <li>The "scope" parameter <bcp14>MAY</bcp14> be encoded as a byte st
<t>The client can send an empty (null value) "ace_profile" parameter to ring
indicate that it wants the AS to include the "ace_profile" parameter in instead of
the response. See <xref target="paramProfile"/>.</t> the string encoding specified in <xref target="RFC6749" sectionFormat
<t>A client MUST be able to use the parameters from <xref ="of"
target="I-D.ietf-ace-oauth-params"/> in an access token request to the section="3.3"/> or
token endpoint and the AS MUST be able to process these additional in order to allow compact encoding of complex scopes. The syntax of
parameters.</t> such a binary encoding is explicitly not specified here and left
</list></t> to profiles or applications. Note specifically that a binary encoded
scope does not necessarily use the space character '0x20' to delimit
<t>The default behavior, is that the AS generates a symmetric scope-tokens.</li>
<li>The client can send an empty (null value) "ace_profile" paramete
r to
indicate that it wants the AS to include the "ace_profile" parameter
in
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
token endpoint, and the AS <bcp14>MUST</bcp14> be able to process these ad
ditional
parameters.</li>
</ul>
<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 re-use 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 supposed to use the "req_cnf" parameter from <xref target="RFC9201" format="
target="I-D.ietf-ace-oauth-params"/>. default"/>.
</t> </t>
<t>If CoAP is used, then these parameters <bcp14>MUST</bcp14> be provi
<t>If CoAP is used then these parameters MUST be provided in a CBOR map, ded in a CBOR map
see <xref target="fig:cborTokenParameters"/>.</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
request to the token endpoint, the parameters MUST be encoded as defined as defined
in Appendix B of <xref target="RFC6749"/>.</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
<t><xref target="fig:symmATreq"/> shows a request for a token 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
CBOR diagnostic notation, without abbreviations for better readability. CBOR diagnostic notation, without abbreviations for better readability.
</t>
<figure align="center" anchor="fig:symmATreq" <figure anchor="fig_symmATreq">
title="Example request for an access token bound to a <name>Example Request for an Access Token Bound to a Symmetric Key</
symmetric key."> name>
<artwork align="left"><![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"
Payload: Payload:
{ {
"client_id" : "myclient", "client_id" : "myclient",
"audience" : "tempSensor4711" "audience" : "tempSensor4711"
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t><xref target="fig_asymmATreq" format="default"/> shows a request fo
<t><xref target="fig:asymmATreq"/> shows a request for a token with an r a token
asymmetric proof-of-possession key. Note that in this example OSCORE with an
<xref target="RFC8613"/> is used asymmetric proof-of-possession key. Note that, in this example, OSCORE
to provide object-security, therefore the Content-Format is <xref target="RFC8613" format="default"/> is used
"application/oscore" wrapping the "application/ace+cbor" type content. to provide object-security; therefore, the Content-Format is
The OSCORE option has a decoded interpretation appended in parentheses "application/oscore" wrapping the "application/ace+cbor" type content.
for the reader's convenience. Also note that in this example the audience The OSCORE option has a decoded interpretation appended in parentheses
is implicitly known by both client and AS. Furthermore note that this for the reader's convenience. Also note that, in this example, the aud
example uses the "req_cnf" parameter from <xref ience
target="I-D.ietf-ace-oauth-params"/>. is implicitly known by both the client and AS. Furthermore, note that t
his
<figure align="center" anchor="fig:asymmATreq" example uses the "req_cnf" parameter from <xref target="RFC9201"
title="Example token request bound to an asymmetric key."> format="default"/>.
<artwork align="left"><![CDATA[ </t>
<figure anchor="fig_asymmATreq">
<name>Example Token Request Bound to an Asymmetric Key</name>
<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])
Content-Format: "application/oscore" Content-Format: "application/oscore"
Payload: Payload:
0x44025d1 ... (full payload omitted for brevity) ... 68b3825e 0x44025d1 ... (full payload omitted for brevity) ... 68b3825e
Decrypted payload: Decrypted payload:
skipping to change at line 1227 skipping to change at line 1209
"req_cnf" : { "req_cnf" : {
"COSE_Key" : { "COSE_Key" : {
"kty" : "EC", "kty" : "EC",
"kid" : h'11', "kid" : h'11',
"crv" : "P-256", "crv" : "P-256",
"x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8', "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
"y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4' "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t><xref target="fig_kidATreq" format="default"/> shows a request for
<t><xref target="fig:kidATreq"/> shows a request for a token 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 "req_cnf" parameter from
<xref target="I-D.ietf-ace-oauth-params"/>. <xref target="RFC9201" format="default"/>.
<figure align="center" anchor="fig:kidATreq" </t>
title="Example request for an access token bound to a <figure anchor="fig_kidATreq">
key reference."> <name>Example Request for an Access Token Bound to a Key Reference</
<artwork align="left"><![CDATA[ name>
<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"
Payload: Payload:
{ {
"client_id" : "myclient", "client_id" : "myclient",
"audience" : "valve424", "audience" : "valve424",
"scope" : "read", "scope" : "read",
"req_cnf" : { "req_cnf" : {
"kid" : b64'6kg0dXJM13U' "kid" : b64'6kg0dXJM13U'
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t>Refresh tokens are typically not stored as securely as
<t>Refresh tokens are typically not stored as securely as proof-of-possession keys in requesting clients. Proof-of-possession-ba
proof-of-possession keys in requesting clients. Proof-of-possession based sed
refresh token requests MUST NOT request different proof-of-possession keys refresh token requests <bcp14>MUST NOT</bcp14> request different
or different audiences in token requests. Refresh token requests can only proof-of-possession keys
use to request access tokens bound to the same proof-of-possession key and or different audiences in token requests. Refresh token requests can o
the same audience as access tokens issued in the initial token request.</t> nly be
</section> used to request access tokens bound to the same proof-of-possession key
and
<section anchor="tokenResponse" title="AS-to-Client Response"> the same audience as access tokens issued in the initial token request.
<t>If the access token request has been successfully verified by the </t>
</section>
<section anchor="tokenResponse" numbered="true" toc="default">
<name>AS-to-Client Response</name>
<t>If the access token request has been successfully verified by the
AS and the client is authorized to obtain an access token corresponding AS and the client is authorized to obtain an access token corresponding
to its access token request, the AS sends a response with the response to its access token request, the AS sends a response with the response
code equivalent to the CoAP response code 2.01 (Created). If client code equivalent to the CoAP response code 2.01 (Created). If the client
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 described in <xref target="errorsToken" format="default"/>.</t>
target="errorsToken"/>.</t> <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
<t>Note that the AS decides which token type and profile to use when knowledge of the capabilities of the client and the RS (see <xref
issuing a successful response. It is assumed that the AS has prior target="app_registration" format="default"/>). This prior knowledge ma
knowledge of the capabilities of the client and the RS (see <xref y,
target="app:registration"/>). 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"/>. If the client has requested a specific <xref target="RFC7591" format="default"/>. If the client has requested
proof-of-possession key using the "req_cnf" parameter from a
<xref target="I-D.ietf-ace-oauth-params"/>, this may also influence which specific
profile the AS selects, as it needs to support the use of the key type proof-of-possession key using the "req_cnf" parameter from
requested the client.</t> <xref target="RFC9201" format="default"/>, this may also influence whic
h
<t>The content of the successful reply is the Access Information. profile the AS selects, as it needs to support the use of the key type
When using CoAP, the payload MUST be encoded as a CBOR map, when using requested by the client.</t>
HTTP the encoding is a JSON map as specified in section 5.1 of <xref <t>The content of the successful reply is the Access Information.
target="RFC6749"/>. In both cases the parameters specified in Section 5.1 When using CoAP, the payload <bcp14>MUST</bcp14> be encoded as a CBOR m
of <xref target="RFC6749"/> are used, with the following additions and ap;
changes: when using
HTTP, the encoding is a JSON map, as specified in <xref target="RFC6749
<list style="hanging"> "
<t hangText="ace_profile:"><vspace blankLines="0"/> sectionFormat="of" section="5.1"/>. In both cases, the parameters spec
OPTIONAL unless the request included an empty ace_profile parameter ified
in which case it is MANDATORY. This indicates the profile that the in <xref target="RFC6749" sectionFormat="of" section="5.1"/> are used,
client MUST use towards the RS. See <xref target="paramProfile"/> for with
the formatting of this parameter. If this parameter is absent, the AS the following additions and changes:</t>
assumes that the client implicitly knows which profile to use towards <dl newline="true" spacing="normal" indent="6">
the RS.</t> <dt>ace_profile:</dt>
<dd>This parameter is <bcp14>OPTIONAL</bcp14> unless the request inc
<t hangText="token_type:"><vspace blankLines="0"/> luded an
This parameter is OPTIONAL, as opposed to 'required' in empty ace_profile parameter,
<xref target="RFC6749"/>. By default implementations of this framework in which case it is MANDATORY. This indicates the profile that the
SHOULD assume that the token_type is "PoP". If a specific use case client <bcp14>MUST</bcp14> use towards the RS. See <xref
requires another token_type (e.g., "Bearer") to be used then this target="paramProfile" format="default"/> for
parameter is REQUIRED. the formatting of this parameter. If this parameter is absent, the A
</t> S
</list> assumes that the client implicitly knows which profile to use towards
</t> the RS.</dd>
<!--[rfced] We changed 'required' to REQUIRED because it seems to
<t>Furthermore <xref target="I-D.ietf-ace-oauth-params"/> defines be a direct mention of what appeared in RFC 6749. If this is not accurate,
additional parameters that the AS MUST be able to use when responding to a please let us know.
request to the token endpoint.</t>
<t><xref target="fig:rsinfo"/> summarizes the parameters that
can currently be part of the Access Information. Future extensions
may define additional parameters.
<figure align="center" anchor="fig:rsinfo"
title="Access Information parameters">
<artwork align="left"><![CDATA[
/-------------------+-------------------------------\
| Parameter name | Specified in |
|-------------------+-------------------------------|
| access_token | RFC 6749 |
| token_type | RFC 6749 |
| expires_in | RFC 6749 |
| refresh_token | RFC 6749 |
| scope | RFC 6749 |
| state | RFC 6749 |
| error | RFC 6749 |
| error_description | RFC 6749 |
| error_uri | RFC 6749 |
| ace_profile | [this document] |
| cnf | [I-D.ietf-ace-oauth-params] |
| rs_cnf | [I-D.ietf-ace-oauth-params] |
\-------------------+-------------------------------/
]]></artwork></figure>
</t> Original:
token_type:
This parameter is OPTIONAL, as opposed to 'required' in
[RFC6749].
<t><xref target="fig:symmATres"/> shows a response containing a token Current:
token_type:
This parameter is OPTIONAL, as opposed to REQUIRED in
[RFC6749].
-->
<dt>token_type:</dt>
<dd>This parameter is <bcp14>OPTIONAL</bcp14>, as opposed to
<bcp14>REQUIRED</bcp14> in
<xref target="RFC6749" format="default"/>. By default, implementation
s of
this framework
<bcp14>SHOULD</bcp14> assume that the token_type is "PoP". If a spec
ific
use case
requires another token_type (e.g., "Bearer") to be used, then this
parameter is <bcp14>REQUIRED</bcp14>.
</dd>
</dl>
<t>Furthermore, <xref target="RFC9201" format="default"/> defines
additional parameters that the AS <bcp14>MUST</bcp14> be able to use wh
en
responding to a request to the token endpoint.</t>
<t><xref target="table_rsinfo" format="default"/> summarizes the param
eters that
can currently be part of the Access Information. Future extensions
may define additional parameters.</t>
<table anchor="table_rsinfo">
<name>Access Information Parameters</name>
<thead>
<tr>
<th>Parameter name</th>
<th>Specified in</th>
</tr>
</thead>
<tbody>
<tr>
<td>access_token</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>token_type</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>expires_in</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>refresh_token</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>scope</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>state</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>error</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>error_description</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>error_uri</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>ace_profile</td>
<td>RFC 9200</td>
</tr>
<tr>
<td>cnf</td>
<td><xref target="RFC9201" format="default"/></td>
</tr>
<tr>
<td>rs_cnf</td>
<td><xref target="RFC9201" format="default"/></td>
</tr>
</tbody>
</table>
<t><xref target="fig_symmATres" format="default"/> shows a response co
ntaining a token
and a "cnf" parameter with a symmetric proof-of-possession key, which and a "cnf" parameter with a symmetric proof-of-possession key, which
is defined in <xref target="I-D.ietf-ace-oauth-params"/>. 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.
<figure align="center" anchor="fig:symmATres" </t>
title="Example AS response with an access token bound to a <figure anchor="fig_symmATres">
symmetric key."> <name>Example AS Response with an Access Token Bound to a Symmetric
<artwork align="left"><![CDATA[ Key</name>
<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:
{ {
"access_token" : b64'SlAV32hkKG ... "access_token" : b64'SlAV32hkKG ...
(remainder of CWT omitted for brevity; (remainder of CWT omitted for brevity;
CWT contains COSE_Key in the "cnf" claim)', CWT contains COSE_Key in the "cnf" claim)',
"ace_profile" : "coap_dtls", "ace_profile" : "coap_dtls",
"expires_in" : "3600", "expires_in" : "3600",
"cnf" : { "cnf" : {
"COSE_Key" : { "COSE_Key" : {
"kty" : "Symmetric", "kty" : "Symmetric",
"kid" : b64'39Gqlw', "kid" : b64'39Gqlw',
"k" : b64'hJtXhkV8FJG+Onbc6mxCcQh' "k" : b64'hJtXhkV8FJG+Onbc6mxCcQh'
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section> </section>
<section anchor="errorsToken" numbered="true" toc="default">
<section anchor="errorsToken" title="Error Response"> <name>Error Response</name>
<t>The error responses for interactions with the AS are generally <t>The error responses for interactions with the AS are generally
equivalent to the ones defined in Section 5.2 of <xref target="RFC6749"/>, equivalent to the ones defined in <xref target="RFC6749" sectionFormat="of"
section="5.2"/>,
with the following exceptions: with the following exceptions:
<list style="symbols"> </t>
<t>When using CoAP the payload MUST be encoded as a CBOR map, with <ul spacing="normal">
the Content-Format "application/ace+cbor". When using HTTP the <li>When using CoAP, the payload <bcp14>MUST</bcp14> be encoded as a
payload is encoded in JSON as specified in section 5.2 of <xref CBOR
target="RFC6749"/>.</t> map, with
the Content-Format "application/ace+cbor". When using HTTP, the
<t>A response code equivalent to the CoAP code 4.00 (Bad Request) MUST payload is encoded in JSON, as specified in <xref target="RFC6749"
be used for all error responses, except for invalid_client where a sectionFormat="of" section="5.2"/>.</li>
response code equivalent to the CoAP code 4.01 (Unauthorized) MAY be <li>A response code equivalent to the CoAP code 4.00 (Bad Request)
used under the same conditions as specified in Section 5.2 of <bcp14>MUST</bcp14>
<xref target="RFC6749"/>.</t> be used for all error responses, except for invalid_client, where a
response code equivalent to the CoAP code 4.01 (Unauthorized)
<t>The parameters "error", "error_description" and "error_uri" MUST <bcp14>MAY</bcp14> be
be abbreviated using the codes specified in <xref used under the same conditions as specified in
target="fig:cborTokenParameters"/>, when a CBOR encoding is used.</t> <xref target="RFC6749" sectionFormat="of" section="5.2"/>.</li>
<li>The parameters "error", "error_description", and "error_uri" <bc
<t>The error code (i.e., value of the "error" parameter) MUST be p14>MUST</bcp14>
abbreviated as specified in <xref be abbreviated using the codes specified in <xref target="table_cborToken
target="fig:cborErrorCodes"/>, when a CBOR encoding is used.</t> Parameters" format="default"/>, when a CBOR encoding is used.</li>
</list> <li>The error code (i.e., value of the "error" parameter) <bcp14>MUS
T</bcp14> be
<figure align="center" anchor="fig:cborErrorCodes" abbreviated, as specified in <xref target="table_cborErrorCodes" format="
title="CBOR abbreviations for common error codes"> default"/>, when a CBOR encoding is used.</li>
<artwork align="left"><![CDATA[ </ul>
/---------------------------+-------------\
| Name | CBOR Values |
|---------------------------+-------------|
| invalid_request | 1 |
| invalid_client | 2 |
| invalid_grant | 3 |
| unauthorized_client | 4 |
| unsupported_grant_type | 5 |
| invalid_scope | 6 |
| unsupported_pop_key | 7 |
| incompatible_ace_profiles | 8 |
\---------------------------+-------------/
]]></artwork>
</figure>
</t>
<t>In addition to the error responses defined in OAuth 2.0, the following
behavior MUST be implemented by the AS:
<list style="symbols"> <!--[rfced] Please review whether "abbreviations" is an accurate term
<t>If the client submits an asymmetric key in the token request that the as used in this document. For example: Section 5.8 refers to "integer
RS cannot process, the AS MUST reject that request with a response code abbreviations for the parameters or their values".
equivalent to the CoAP code 4.00 (Bad Request) including the error code
"unsupported_pop_key" specified in
<xref target="fig:cborErrorCodes"/>.</t>
<t>If the client and the RS it has requested an access token for do Specifically, in the cases below, perhaps "values" would be more
not share a common profile, the AS MUST reject that request with a precise than "abbreviations"? (where "CBOR Value" is the column title
response code equivalent to the CoAP code 4.00 (Bad Request) including in the corresponding IANA registry)
the error code "incompatible_ace_profiles" specified in
<xref target="fig:cborErrorCodes"/>.</t>
</list></t>
</section>
<section anchor="tokenParams" Current:
title="Request and Response Parameters"> Table 3: CBOR Abbreviations for Common Error Codes
<t>This section provides more detail about the new parameters that can be Perhaps:
used in access token requests and responses, as well as abbreviations for Table 3: CBOR Values for Common Error Codes
more compact encoding of existing parameters and common parameter
values.</t>
<section anchor="paramGrantType" title="Grant Type"> Current:
<t>The abbreviations specified in the registry defined in Table 4: CBOR Abbreviations for Common Grant Types
<xref target="IANAGrantTypeMappings"/> MUST be Perhaps:
Table 4: CBOR Values for Common Grant Types
-->
<table anchor="table_cborErrorCodes">
<name>CBOR Abbreviations for Common Error Codes</name>
<thead>
<tr>
<th>Name</th>
<th>CBOR Values</th>
<th>Original Specification</th>
</tr>
</thead>
<tbody>
<tr>
<td>invalid_request</td>
<td>1</td>
<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td
>
</tr>
<tr>
<td>invalid_client</td>
<td>2</td>
<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td
>
</tr>
<tr>
<td>invalid_grant</td>
<td>3</td>
<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td
>
</tr>
<tr>
<td>unauthorized_client</td>
<td>4</td>
<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td
>
</tr>
<tr>
<td>unsupported_grant_type</td>
<td>5</td>
<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td
>
</tr>
<tr>
<td>invalid_scope</td>
<td>6</td>
<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td
>
</tr>
<tr>
<td>unsupported_pop_key</td>
<td>7</td>
<td>RFC 9200</td>
</tr>
<tr>
<td>incompatible_ace_profiles</td>
<td>8</td>
<td>RFC 9200</td>
</tr>
</tbody>
</table>
<t>In addition to the error responses defined in OAuth 2.0, the follow
ing
behavior <bcp14>MUST</bcp14> be implemented by the AS:
</t>
<ul spacing="normal">
<li>If the client submits an asymmetric key in the token request tha
t the
RS cannot process, the AS <bcp14>MUST</bcp14> reject that request wit
h a
response code equivalent to the CoAP code 4.00 (Bad Request), includi
ng the
error code "unsupported_pop_key" specified in
<xref target="table_cborErrorCodes" format="default"/>.</li>
<li>If the client and the RS it has requested an access token for do
not share a common profile, the AS <bcp14>MUST</bcp14> reject that re
quest with
a response code equivalent to the CoAP code 4.00 (Bad Request), inclu
ding
the error code "incompatible_ace_profiles" specified in
<xref target="table_cborErrorCodes" format="default"/>.</li>
</ul>
</section>
<section anchor="tokenParams" numbered="true" toc="default">
<name>Request and Response Parameters</name>
<t>This section provides more detail about the new parameters that can
be
used in access token requests and responses, as well as abbreviations f
or
more compact encoding of existing parameters and common parameter
values.</t>
<section anchor="paramGrantType" numbered="true" toc="default">
<name>Grant Type</name>
<t>The abbreviations specified in the registry defined in
<xref target="IANAGrantTypeMappings" format="default"/> <bcp14>MUST</bcp14
> be
used in CBOR encodings instead of the string values defined used in CBOR encodings instead of the string values defined
in <xref target="RFC6749"/>, if CBOR payloads are used. in <xref target="RFC6749" format="default"/> if CBOR payloads are used.
<figure align="center" anchor="fig:grant_types"
title="CBOR abbreviations for common grant types ">
<artwork align="left"><![CDATA[
/--------------------+------------+------------------------\
| Name | CBOR Value | Original Specification |
|--------------------+------------+------------------------|
| password | 0 | s. 4.3.2 of [RFC6749] |
| authorization_code | 1 | s. 4.1.3 of [RFC6749] |
| client_credentials | 2 | s. 4.4.2 of [RFC6749] |
| refresh_token | 3 | s. 6 of [RFC6749] |
\--------------------+------------+------------------------/
]]></artwork>
</figure></t>
</section>
<section anchor="paramTokenType" title="Token Type">
<t>The "token_type" parameter, defined in section 5.1 of <xref
target="RFC6749"/>, allows the AS to indicate to the client which type of
access token it is receiving (e.g., a bearer token). </t>
<t>This document registers the new value "PoP" for the OAuth Access
Token Types registry, specifying a proof-of-possession token. How the
proof-of-possession by the client to the RS is performed MUST be specified
by the profiles.</t>
<t>The values in the "token_type" parameter MUST use the CBOR
abbreviations defined in the registry specified by
<xref target="IANATokenTypeMappings"/>, if a CBOR encoding is used. </t>
<t>In this framework the "pop" value for the "token_type" parameter is
the default. The AS may, however, provide a different value from those
registered in <xref target="IANA.OAuthAccessTokenTypes"/>.</t>
</section>
<section anchor="paramProfile" title="Profile">
<t>Profiles of this framework MUST define the communication </t>
protocol and the communication security protocol between the client <table anchor="table_grant_types">
and the RS. The security protocol MUST provide encryption, integrity and <name>CBOR Abbreviations for Common Grant Types</name>
replay protection. It MUST also provide a binding between requests and <thead>
responses. Furthermore profiles MUST define a list of <tr>
allowed proof-of-possession methods, if they support proof-of-possession <th>Name</th>
tokens.</t> <th>CBOR Value</th>
<th>Original Specification</th>
</tr>
</thead>
<tbody>
<tr>
<td>password</td>
<td>0</td>
<td><xref target="RFC6749" sectionFormat="of" section="4.3.2"/>
</td>
</tr>
<tr>
<td>authorization_code</td>
<td>1</td>
<td><xref target="RFC6749" sectionFormat="of" section="4.1.3"/>
</td>
</tr>
<tr>
<td>client_credentials</td>
<td>2</td>
<td><xref target="RFC6749" sectionFormat="of" section="4.4.2"/>
</td>
</tr>
<tr>
<td>refresh_token</td>
<td>3</td>
<td><xref target="RFC6749" sectionFormat="of" section="6"/></td
>
</tr>
</tbody>
</table>
</section>
<section anchor="paramTokenType" numbered="true" toc="default">
<name>Token Type</name>
<t>The "token_type" parameter, defined in <xref target="RFC6749"
sectionFormat="of" section="5.1"/>, allows the AS to indicate to the
client which type of
access token it is receiving (e.g., a bearer token). </t>
<t>A profile MUST specify an identifier that MUST be used to uniquely <t>This document registers the new value "PoP" for the "OAuth Access
Token Types" registry, specifying a proof-of-possession token. How
the
proof of possession by the client to the RS is performed
<bcp14>MUST</bcp14> be specified by the profiles.</t>
<t>The values in the "token_type" parameter <bcp14>MUST</bcp14> use
the
CBOR abbreviations defined in the registry specified by
<xref target="IANATokenTypeMappings" format="default"/> if a CBOR
encoding is used.</t>
<t>In this framework, the "pop" value for the "token_type" parameter
is
the default. The AS may, however, provide a different value from thos
e
registered in <xref target="IANA.OAuthAccessTokenTypes" format="defau
lt"/>.</t>
</section>
<section anchor="paramProfile" numbered="true" toc="default">
<name>Profile</name>
<t>Profiles of this framework <bcp14>MUST</bcp14> define the communi
cation
protocol and the communication security protocol between the client
and the RS. The security protocol <bcp14>MUST</bcp14> provide encryp
tion,
integrity, and
replay protection. It <bcp14>MUST</bcp14> also provide a binding betw
een
requests and
responses. Furthermore, profiles <bcp14>MUST</bcp14> define a list o
f
allowed proof-of-possession methods if they support proof-of-possessi
on
tokens.</t>
<t>A profile <bcp14>MUST</bcp14> specify an identifier that <bcp14>M
UST</bcp14> be used to uniquely
identify itself in the "ace_profile" parameter. The textual identify itself in the "ace_profile" 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 MUST NOT be used for readability and for JSON-based interactions; it <bcp14>MUST NOT</bcp14> be
CBOR-based interactions. Profiles MUST register their identifier in the used for
registry defined in <xref target="IANAProfile"/>. CBOR-based interactions. Profiles <bcp14>MUST</bcp14> register their iden
</t> tifier in the
registry defined in <xref target="IANAProfile" format="default"/>.
<t>Profiles MAY define additional parameters for both the token request </t>
<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 "ace_profile" parameter in the access token response can indicate that by sending a
parameter in the access token response can indicate that by sending a ace_profile parameter with a null value for CBOR-based interactions,
ace_profile 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">
<name>Client-Nonce</name>
<section anchor="cnonceParamToken" title="Client-Nonce"> <t>This parameter <bcp14>MUST</bcp14> be sent from the client to the
<t>This parameter MUST be sent from the client to the AS, AS
if it previously received a "cnonce" parameter in the "AS Request if it previously received a "cnonce" parameter in the "AS Request
Creation Hints" <xref target="asInfo"/>. The parameter Creation Hints" (<xref target="asInfo" format="default"/>). The para
is encoded as a byte string for CBOR-based interactions, and as a meter
string (Base64 encoded binary) if CBOR is not used. is encoded as a byte string for CBOR-based interactions and as a
It MUST copy the value from the cnonce parameter in the "AS Request string (base64url without padding encoded binary <xref target="RFC464
Creation Hints".</t> 8"
</section> format="default"/>) if CBOR is not used.
</section> <!--Parameters --> It <bcp14>MUST</bcp14> copy the value from the cnonce parameter in th
e "AS
Request Creation Hints".</t>
</section>
</section>
<!--Parameters -->
<section anchor="tokenCborParams" title="Mapping Parameters to CBOR"> <section anchor="tokenCborParams" numbered="true" toc="default">
<t>If CBOR encoding is used, all OAuth parameters in access token requests <name>Mapping Parameters to CBOR</name>
and responses MUST be mapped to CBOR types as specified in the registry <t>If CBOR encoding is used, all OAuth parameters in access token requ
defined by <xref target="IANAOAuthParameterMappingsRegistry"/>, using the ests
and responses <bcp14>MUST</bcp14> be mapped to CBOR types, as specified in t
he registry
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"/>.</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
size in CBOR. We have thus chosen to assign abbreviations in that size in CBOR. We have thus chosen to assign abbreviations in that
range to parameters we expect to be used most frequently in constrained range to parameters we expect to be used most frequently in constrained
scenarios.</t> scenarios.</t>
<table anchor="table_cborTokenParameters">
<name>CBOR Mappings Used in Token Requests and Responses</name>
<thead>
<tr>
<th>Name</th>
<th>CBOR Key</th>
<th>Value Type</th>
<th>Original Specification</th>
</tr>
</thead>
<tbody>
<tr>
<td>access_token</td>
<td>1</td>
<td>byte string</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>expires_in</td>
<td>2</td>
<td>unsigned integer</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>audience</td>
<td>5</td>
<td>text string</td>
<td><xref target="RFC8693" format="default"/></td>
</tr>
<tr>
<td>scope</td>
<td>9</td>
<td>text or byte string</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>client_id</td>
<td>24</td>
<td>text string</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>client_secret</td>
<td>25</td>
<td>byte string</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>response_type</td>
<td>26</td>
<td>text string</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>redirect_uri</td>
<td>27</td>
<td>text string</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>state</td>
<td>28</td>
<td>text string</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>code</td>
<td>29</td>
<td>byte string</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>error</td>
<td>30</td>
<td>integer</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>error_description</td>
<td>31</td>
<td>text string</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>error_uri</td>
<td>32</td>
<td>text string</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>grant_type</td>
<td>33</td>
<td>unsigned integer</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>token_type</td>
<td>34</td>
<td>integer</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>username</td>
<td>35</td>
<td>text string</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>password</td>
<td>36</td>
<td>text string</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>refresh_token</td>
<td>37</td>
<td>byte string</td>
<td><xref target="RFC6749" format="default"/></td>
</tr>
<tr>
<td>ace_profile</td>
<td>38</td>
<td>integer</td>
<td>RFC 9200</td>
</tr>
<tr>
<td>cnonce</td>
<td>39</td>
<td>byte string</td>
<td>RFC 9200</td>
</tr>
</tbody>
</table>
</section>
</section>
<!-- Token endpoint -->
<t> <section anchor="introspectionEndpoint" numbered="true" toc="default">
<figure align="center" anchor="fig:cborTokenParameters" <name>The Introspection Endpoint</name>
title="CBOR mappings used in token requests and responses"> <t>Token introspection <xref target="RFC7662" format="default"/> <bcp14>
<artwork align="left"><![CDATA[ MAY</bcp14>
/-------------------+----------+---------------------\ be implemented by the AS and the RS. When implemented, it <bcp14>MAY</bcp
| Name | CBOR Key | Value Type | 14> be
|-------------------+----------+---------------------| used by the RS and to query the
| access_token | 1 | byte string | AS for metadata about a given token, e.g., validity or scope. Analogous t
| expires_in | 2 | unsigned integer | o the
| audience | 5 | text string | protocol defined in <xref target="RFC7662" format="default"/> for HTTP an
| scope | 9 | text or byte string | d JSON,
| client_id | 24 | text string | this section defines adaptations to more constrained environments using
| client_secret | 25 | byte string | CBOR and
| response_type | 26 | text string | leaving the choice of the application protocol to the profile.</t>
| redirect_uri | 27 | text string | <t>Communication between the requesting entity and the introspection end
| state | 28 | text string | point
| code | 29 | byte string | at the AS <bcp14>MUST</bcp14> be integrity protected and encrypted. The commu
| error | 30 | integer | nication
| error_description | 31 | text string | security protocol <bcp14>MUST</bcp14> also provide a binding between requests
| error_uri | 32 | text string | and
| grant_type | 33 | unsigned integer | responses. Furthermore, the two interacting parties <bcp14>MUST</bcp14> perfo
| token_type | 34 | integer | rm mutual
| username | 35 | text string | authentication. Finally, the AS <bcp14>SHOULD</bcp14> verify that the request
| password | 36 | text string | ing entity has
| refresh_token | 37 | byte string |
| ace_profile | 38 | integer |
| cnonce | 39 | byte string |
\-------------------+----------+---------------------/
]]></artwork>
</figure>
</t>
</section>
</section><!-- Token endpoint -->
<section anchor="introspectionEndpoint" title="The Introspection Endpoint">
<t>Token introspection <xref target="RFC7662"/> MAY be implemented by the AS,
and the RS. When implemented, it MAY be used by the RS and to query the AS
for metadata about a given token, e.g., validity or scope. Analogous to the
protocol defined in <xref target="RFC7662"/> for HTTP and JSON, this
section defines adaptations to more constrained environments using CBOR and
leaving the choice of the application protocol to the profile.</t>
<t>Communication between the requesting entity and the introspection endpoint
at the AS MUST be integrity protected and encrypted. The communication
security protocol MUST also provide a binding between requests and
responses. Furthermore, the two interacting parties MUST perform mutual
authentication. Finally, the AS SHOULD verify that the requesting entity has
the right to access introspection information about the provided token. the right to access introspection information about the provided token.
Profiles of this framework that support introspection MUST specify how Profiles of this framework that support introspection <bcp14>MUST</bcp14> spec ify how
authentication and communication security between the requesting authentication and communication security between the requesting
entity and the AS is implemented.</t> entity and the AS is implemented.</t>
<t> The default name of this endpoint in a url-path <bcp14>SHOULD</bcp14
<t> The default name of this endpoint in an url-path SHOULD be '/introspect'. > be '/introspect'.
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>
<t>The figures of this section use the CBOR diagnostic
<t>The figures of this section use the CBOR diagnostic
notation without the integer abbreviations for the parameters and their notation without the integer abbreviations for the parameters and their
values for better readability. values for better readability.
</t> </t>
<section anchor="introReq" numbered="true" toc="default">
<section anchor="introReq" title="Introspection Request"> <name>Introspection Request</name>
<t>The requesting entity sends a POST request to the introspection endpoint <t>The requesting entity sends a POST request to the introspection end
at the AS. The profile MUST specify how the communication is protected. point
If CoAP is used, the payload MUST be encoded as a CBOR map with a "token" at the AS. The profile <bcp14>MUST</bcp14> specify how the communication is
protected.
If CoAP is used, the payload <bcp14>MUST</bcp14> be encoded as a CBOR map wi
th a "token"
entry containing the access token. Further optional parameters entry containing the access token. Further optional parameters
representing additional context that is known by the requesting entity to representing additional context that is known by the requesting entity to
aid the AS in its response MAY be included.</t> aid the AS in its response <bcp14>MAY</bcp14> be included.</t>
<t>For CoAP-based interaction, all messages <bcp14>MUST</bcp14> use th
<t>For CoAP-based interaction, all messages MUST use the content type e content
"application/ace+cbor". For HTTP the encoding defined in section 2.1 type "application/ace+cbor". For HTTP, the encoding defined in
of <xref target="RFC7662"/> is used.</t> <xref target="RFC7662" sectionFormat="of" section="2.1"/> is used.</t>
<t>The same parameters are required and optional as in
<t>The same parameters are required and optional as in Section 2.1 <xref target="RFC7662" sectionFormat="of" section="2.1"/>.</t>
of <xref target="RFC7662"/>.</t> <t>For example, <xref target="fig_introReq" format="default"/> shows a
n RS
<t>For example, <xref target="fig:introReq"/> shows an RS calling the token calling the token
introspection endpoint at the AS to query about an OAuth 2.0 introspection endpoint at the AS to query about an OAuth 2.0
proof-of-possession token. Note that object security based on OSCORE proof-of-possession token. Note that object security based on OSCORE
<xref target="RFC8613"/> is assumed in this example, <xref target="RFC8613" format="default"/> is assumed in this example;
therefore the Content-Format is "application/oscore". <xref therefore, the Content-Format is "application/oscore". <xref
target="fig:introReq-payl"/> shows the decoded payload. target="fig_introReq-payl" format="default"/> shows the decoded payload
.</t>
<figure align="center" anchor="fig:introReq" <figure anchor="fig_introReq">
title="Example introspection request."> <name>Example Introspection Request</name>
<artwork align="left"><![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: "introspect" Uri-Path: "introspect"
OSCORE: 0x09, 0x05, 0x25 OSCORE: 0x09, 0x05, 0x25
Content-Format: "application/oscore" Content-Format: "application/oscore"
Payload: Payload:
... COSE content ... ... COSE content ...
]]></artwork> ]]></sourcecode>
</figure> </figure>
<figure align="center" anchor="fig:introReq-payl" <figure anchor="fig_introReq-payl">
title="Decoded payload."> <name>Decoded Payload</name>
<artwork align="left"><![CDATA[ <sourcecode name="" type="cbor-diag"><![CDATA[
{ {
"token" : b64'7gj0dXJQ43U', "token" : b64'7gj0dXJQ43U',
"token_type_hint" : "PoP" "token_type_hint" : "PoP"
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section>
</section> <section anchor="introRes" numbered="true" toc="default">
<name>Introspection Response</name>
<section anchor="introRes" title="Introspection Response"> <t>If the introspection request is authorized and successfully process
<t>If the introspection request is authorized and successfully processed, ed,
the AS sends a response with the response code equivalent to the CoAP code the AS sends a response with the response code equivalent to the CoAP c
2.01 (Created). If the introspection request was invalid, not authorized ode
or couldn't be processed the AS returns an error response as described in 2.01 (Created). If the introspection request was invalid, not authoriz
<xref target="errorsIntro"/>.</t> ed,
or couldn't be processed, the AS returns an error response, as describe
<t>In a successful response, the AS encodes the response parameters in d in
a map. If CoAP is used, this MUST be encoded as a CBOR map, if HTTP is <xref target="errorsIntro" format="default"/>.</t>
used the JSON encoding specified in section 2.2 of <xref target="RFC7662"/> <t>In a successful response, the AS encodes the response parameters in
is used. The map containing the response payload includes the same a map. If CoAP is used, this <bcp14>MUST</bcp14> be encoded as a CBOR
required and optional parameters as in Section 2.2 of map; if
<xref target="RFC7662"/> with the following additions: HTTP is used, the JSON encoding specified in <xref target="RFC7662"
sectionFormat="of" section="2.2"/>
<list style="hanging"> is used. The map containing the response payload includes the same
<t hangText="ace_profile"> required and optional parameters as in
OPTIONAL. This indicates the profile that the RS MUST use with the <xref target="RFC7662" sectionFormat="of" section="2.2"/>, with the fol
client. See <xref target="paramProfile"/> for more details on the lowing
formatting of this parameter. If this parameter is absent, the AS additions:</t>
assumes that the RS implicitly knows which profile to use towards <dl newline="true" spacing="normal">
the client.</t> <dt>ace_profile:</dt>
<t hangText="cnonce"> <dd>This parameter is <bcp14>OPTIONAL</bcp14>. This indicates the p
OPTIONAL. A client-nonce provided to the AS by the client. rofile that
The RS MUST verify that this corresponds to the client-nonce the RS <bcp14>MUST</bcp14> use with the
previously provided to the client in the "AS Request Creation client. See <xref target="paramProfile" format="default"/> for more
Hints". See <xref target="asInfo"/> and details on
<xref target="cnonceParamToken"/>. the formatting of this parameter. If this parameter is absent, the AS
</t> assumes that the RS implicitly knows which profile to use towards
<t hangText="exi"> the client.</dd>
OPTIONAL. The "expires-in" claim associated to this access token. <dt>cnonce:</dt>
See <xref target="tokenExpiration"/>. <dd>This parameter is <bcp14>OPTIONAL</bcp14>. This is a
</t> client-nonce provided to the AS by the client.
</list> The RS <bcp14>MUST</bcp14> verify that this corresponds to the
</t> client-nonce
previously provided to the client in the "AS Request Creation
<t>Furthermore <xref target="I-D.ietf-ace-oauth-params"/> defines Hints". See Sections <xref target="asInfo" format="counter"/> and
more parameters that the AS MUST be able to use when responding to a <xref target="cnonceParamToken" format="counter"/>. Its value is a
byte string when encoded in CBOR and is the base64url encoding of thi
s
byte string without padding when encoded in JSON <xref
target="RFC4648" format="default"/>.
</dd>
<dt>cti:</dt>
<dd>This parameter is <bcp14>OPTIONAL</bcp14>. This is the "cti" cla
im associated to
this access token.
This parameter has the same meaning and processing rules as the
"jti" parameter defined in <xref target="RFC7662" sectionFormat="of"
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
padding when encoded in JSON <xref target="RFC4648"
format="default"/>.</dd>
<dt>exi:</dt>
<dd>This parameter is <bcp14>OPTIONAL</bcp14>. This is the
"expires-in" claim associated to this access token.
See <xref target="tokenExpiration" format="default"/>.
</dd>
</dl>
<t>Furthermore, <xref target="RFC9201" format="default"/> defines
more parameters that the AS <bcp14>MUST</bcp14> be able to use when respondi
ng to a
request to the introspection endpoint.</t> request to the introspection endpoint.</t>
<t>For example, <xref target="fig_introRes" format="default"/> shows a
<t>For example, <xref target="fig:introRes"/> shows an AS n AS
response to the introspection request in <xref target="fig:introReq"/>. 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 "cnf" parameter defined in
<xref target="I-D.ietf-ace-oauth-params"/>. <xref target="RFC9201" format="default"/>.
<figure align="center" anchor="fig:introRes" </t>
title="Example introspection response."> <figure anchor="fig_introRes">
<artwork align="left"><![CDATA[ <name>Example Introspection Response</name>
<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:
{ {
"active" : true, "active" : true,
"scope" : "read", "scope" : "read",
"ace_profile" : "coap_dtls", "ace_profile" : "coap_dtls",
"cnf" : { "cnf" : {
"COSE_Key" : { "COSE_Key" : {
"kty" : "Symmetric", "kty" : "Symmetric",
"kid" : b64'39Gqlw', "kid" : b64'39Gqlw',
"k" : b64'hJtXhkV8FJG+Onbc6mxCcQh' "k" : b64'hJtXhkV8FJG+Onbc6mxCcQh'
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
</section> </section>
<section anchor="errorsIntro" numbered="true" toc="default">
<section anchor="errorsIntro" title="Error Response"> <name>Error Response</name>
<t>The error responses for CoAP-based interactions with the AS <t>The error responses for CoAP-based interactions with the AS
are equivalent to the ones for HTTP-based interactions as defined in are equivalent to the ones for HTTP-based interactions, as defined in
Section 2.3 of <xref target="RFC7662"/>, with the following differences: <xref target="RFC7662" sectionFormat="of" section="2.3"/>, with the
following differences:</t>
<list style="symbols"> <ul spacing="normal">
<t>If content is sent and CoAP is used the payload MUST be encoded as a <li>If content is sent and CoAP is used, the payload <bcp14>MUST</bc
CBOR map and the Content-Format "application/ace+cbor" MUST be used. p14> be
For HTTP the encoding defined in section 2.3 of <xref target="RFC6749"/> encoded as a
is used.</t> CBOR map and the Content-Format "application/ace+cbor" <bcp14>MUST</b
cp14>
<t>If the credentials used by the requesting entity (usually the RS) be used.
are invalid the AS MUST respond with the response code equivalent to the For HTTP, the encoding defined in <xref target="RFC6749" sectionForma
CoAP code 4.01 (Unauthorized) and use the required and optional t="of"
parameters from Section 2.3 in <xref target="RFC7662"/>.</t> section="2.3"/> is used.</li>
<li>If the credentials used by the requesting entity (usually the RS
<t>If the requesting entity does not have the right to perform this )
introspection request, the AS MUST respond with a response code are invalid, the AS <bcp14>MUST</bcp14> respond with the response cod
equivalent to the CoAP code 4.03 (Forbidden). In this case no payload is e
returned.</t> equivalent to the
CoAP code 4.01 (Unauthorized) and use the required and optional
<t>The parameters "error", "error_description" and "error_uri" MUST parameters from <xref target="RFC7662" sectionFormat="of"
be abbreviated using the codes specified in <xref section="2.3"/>.</li>
target="fig:cborTokenParameters"/>.</t> <li>If the requesting entity does not have the right to perform this
introspection request, the AS <bcp14>MUST</bcp14> respond with a response
<t>The error codes MUST be abbreviated using the codes specified in code
the registry defined by <xref target="IANAErrorCBORMappings"/>.</t> equivalent to the CoAP code 4.03 (Forbidden). In this case, no payload is
</list> returned.</li>
</t> <li>The parameters "error", "error_description", and "error_uri" <bc
p14>MUST</bcp14>
<t>Note that a properly formed and authorized query for an inactive or be abbreviated using the codes specified in <xref target="table_cborTokenP
arameters" format="default"/>.</li>
<li>The error codes <bcp14>MUST</bcp14> be abbreviated using the cod
es specified in
the registry defined by <xref target="IANAErrorCBORMappings" format="defau
lt"/>.</li>
</ul>
<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 MUST 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 "active" field set to
"false".</t> "false".</t>
</section> </section>
<section anchor="introParamsCbor" numbered="true" toc="default">
<section anchor="introParamsCbor" <name>Mapping Introspection Parameters to CBOR</name>
title="Mapping Introspection Parameters to CBOR"> <t>If CBOR is used, the introspection request and response parameters
<t>If CBOR is used, the introspection request and response parameters MUST <bcp14>MUST</bcp14>
be mapped to CBOR types as specified in the registry defined by <xref be mapped to CBOR types, as specified in the registry defined by <xref targe
target="IANAIntrospectionEndpointCBORMappingsRegistry"/>, using the given t="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="defau
claim with the abbreviations defined in <xref target="RFC8392"/> lt"/>
and the abbreviations of parameters with the same name from and the abbreviations of parameters with the same name from
<xref target="tokenCborParams"/>. <xref target="tokenCborParams" format="default"/>.
</t>
<figure align="center" anchor="fig:cborIntrospectionParameters" <table anchor="table_cborIntrospectionParameters">
title="CBOR Mappings to Token Introspection Parameters."> <name>CBOR Mappings for Token Introspection Parameters</name>
<artwork align="left"><![CDATA[ <thead>
/-------------------+----------+-------------------------\ <tr>
| Parameter name | CBOR Key | Value Type | <th>Parameter name</th>
|-------------------+----------+-------------------------| <th>CBOR Key</th>
| iss | 1 | text string | <th>Value Type</th>
| sub | 2 | text string | <th>Original Specification</th>
| aud | 3 | text string | </tr>
| exp | 4 | integer or | </thead>
| | | floating-point number | <tbody>
| nbf | 5 | integer or | <tr>
| | | floating-point number | <td>iss</td>
| iat | 6 | integer or | <td>1</td>
| | | floating-point number | <td>text string</td>
| cti | 7 | byte string | <td><xref target="RFC7662" format="default"/></td>
| scope | 9 | text or byte string | </tr>
| active | 10 | True or False | <tr>
| token | 11 | byte string | <td>sub</td>
| client_id | 24 | text string | <td>2</td>
| error | 30 | integer | <td>text string</td>
| error_description | 31 | text string | <td><xref target="RFC7662" format="default"/></td>
| error_uri | 32 | text string | </tr>
| token_type_hint | 33 | text string | <tr>
| token_type | 34 | integer | <td>aud</td>
| username | 35 | text string | <td>3</td>
| ace_profile | 38 | integer | <td>text string</td>
| cnonce | 39 | byte string | <td><xref target="RFC7662" format="default"/></td>
| exi | 40 | unsigned integer | </tr>
\-------------------+----------+-------------------------/ <tr>
]]></artwork> <td>exp</td>
</figure> <td>4</td>
</t> <td>integer or floating-point number</td>
</section> <td><xref target="RFC7662" format="default"/></td>
</tr>
<tr>
<td>nbf</td>
<td>5</td>
<td>integer or floating-point number</td>
<td><xref target="RFC7662" format="default"/></td>
</tr>
<tr>
<td>iat</td>
<td>6</td>
<td>integer or floating-point number</td>
<td><xref target="RFC7662" format="default"/></td>
</tr>
<tr>
<td>cti</td>
<td>7</td>
<td>byte string</td>
<td>RFC 9200</td>
</tr>
<tr>
<td>scope</td>
<td>9</td>
<td>text or byte string</td>
<td><xref target="RFC7662" format="default"/></td>
</tr>
<tr>
<td>active</td>
<td>10</td>
<td>True or False</td>
<td><xref target="RFC7662" format="default"/></td>
</tr>
<tr>
<td>token</td>
<td>11</td>
<td>byte string</td>
<td><xref target="RFC7662" format="default"/></td>
</tr>
<tr>
<td>client_id</td>
<td>24</td>
<td>text string</td>
<td><xref target="RFC7662" format="default"/></td>
</tr>
<tr>
<td>error</td>
<td>30</td>
<td>integer</td>
<td><xref target="RFC7662" format="default"/></td>
</tr>
<tr>
<td>error_description</td>
<td>31</td>
<td>text string</td>
<td><xref target="RFC7662" format="default"/></td>
</tr>
<tr>
<td>error_uri</td>
<td>32</td>
<td>text string</td>
<td><xref target="RFC7662" format="default"/></td>
</tr>
<tr>
<td>token_type_hint</td>
<td>33</td>
<td>text string</td>
<td><xref target="RFC7662" format="default"/></td>
</tr>
<tr>
<td>token_type</td>
<td>34</td>
<td>integer</td>
<td><xref target="RFC7662" format="default"/></td>
</tr>
<tr>
<td>username</td>
<td>35</td>
<td>text string</td>
<td><xref target="RFC7662" format="default"/></td>
</tr>
<tr>
<td>ace_profile</td>
<td>38</td>
<td>integer</td>
<td>RFC 9200</td>
</tr>
<tr>
<td>cnonce</td>
<td>39</td>
<td>byte string</td>
<td>RFC 9200</td>
</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.
</section><!-- introspection endpoint --> Original:
| exi | 40 | unsigned integer |[this document]|
<section anchor="accessToken" title="The Access Token"> Current:
<t>In this framework the use of CBOR Web Token (CWT) as | exi | 40 | integer | RFC 9200 |
specified in <xref target="RFC8392"/> is RECOMMENDED. -->
</t> <tr>
<td>exi</td>
<td>40</td>
<td>integer</td>
<td>RFC 9200</td>
</tr>
</tbody>
</table>
</section>
</section>
<!-- introspection endpoint -->
<t>In order to facilitate offline processing of access tokens, <section anchor="accessToken" numbered="true" toc="default">
this document uses the "cnf" claim from <xref <name>The Access Token</name>
target="RFC8747"/> and the "scope" claim from <xref target="RFC8693"/> for <t>In this framework, the use of CBOR Web Token (CWT) as
specified in <xref target="RFC8392" format="default"/> is <bcp14>RECOMMENDED
</bcp14>.
</t>
<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
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 MAY be used. The syntax of such an the "scope" claim, a binary encoding <bcp14>MAY</bcp14> be used. The syntax o f 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 a
should use to communicate with the client, the AS MAY include an n
"ace_profile" claim in the access token, with the same syntax and semantics "ace_profile" claim in the access token, with the same syntax and semantics
as defined in <xref target="paramProfile"/>.</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 client-nonce parameter in the access token request (<xref target="cnonceParamToken" format="default"/>), the AS
request <xref target="cnonceParamToken"/>, the AS MUST 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 "cnonce" claim specified here. The "cnonce" claim
uses binary encoding.</t> uses binary encoding.</t>
<section anchor="tokenAuthInfoEndpoint" numbered="true" toc="default">
<section anchor="tokenAuthInfoEndpoint" <name>The Authorization Information Endpoint</name>
title="The Authorization Information Endpoint"> <t>The access token, containing authorization information and informat
<t>The access token, containing authorization information and information ion
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
<t>This section defines a method for transporting the access token to the RS the RS
using a RESTful protocol such as CoAP. Profiles of this framework MAY 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>
<t>The method consists of an authz-info endpoint, implemented by the
<t>The method consists of an authz-info endpoint, implemented by the RS. A client using this method <bcp14>MUST</bcp14> make a POST request to the
RS. A client using this method MUST make a POST request to the authz-info authz-info
endpoint at the RS with the access token in the payload. The CoAP endpoint at the RS with the access token in the payload. The CoAP
Content-Format or HTTP Media Type MUST reflect the format of the token, Content-Format or HTTP media type <bcp14>MUST</bcp14> reflect the format of th
e.g. application/cwt for CBOR Web Tokens, if no Content-Format or Media e token,
Type is defined for the token format, application/octet-stream MUST be e.g., "application/cwt", for CBOR Web Tokens; if no Content-Format or media
type is defined for the token format, "application/octet-stream" <bcp14>MUST</
bcp14> be
used.</t> used.</t>
<t>The RS receiving the token <bcp14>MUST</bcp14> verify the validity
<t>The RS receiving the token MUST verify the validity of the token. If the of the
token is valid, the RS MUST respond to the POST request with a response code token. If the
equivalent to CoAP's 2.01 (Created). token is valid, the RS <bcp14>MUST</bcp14> respond to the POST request
<xref target="verifyToken"/> outlines how an RS MUST proceed to verify the with a
response code equivalent to CoAP code 2.01 (Created).
<xref target="verifyToken" format="default"/> outlines how an RS <bcp14>MUST</
bcp14> proceed to verify the
validity of an access token.</t> validity of an access token.</t>
<t>The RS <bcp14>MUST</bcp14> be prepared to store at least one access
<t>The RS MUST be prepared to store at least one access token for future token for future
use. This is a difference to how access tokens are handled in OAuth 2.0, use. This is a difference as to how access tokens are handled in OAuth 2.0,
where the access token is typically sent along with each request, and where the access token is typically sent along with each request and
therefore not stored at the RS.</t> therefore not stored at the RS.</t>
<t>When using this framework, it is <bcp14>RECOMMENDED</bcp14> that an
<t>When using this framework it is RECOMMENDED that an RS stores only one RS stores
token per proof-of-possession key. This means that an additional token linked only one token per proof-of-possession key. This means that an additio
to the same key will supersede any existing token at the RS, by replacing nal token
the corresponding authorization information. The reason is that linked to the same key will supersede any existing token at the RS by r
this greatly simplifies (constrained) implementations, with respect to eplacing
required storage and resolving a request to the applicable token. The use of the corresponding authorization information. The reason is that
multiple access tokens for a single client increases the strain on the this greatly simplifies (constrained) implementations, with respect to
resource server as it must consider every access token and calculate the required storage and resolving a request to the applicable token. The
actual permissions of the client. Also, tokens may contradict each other use of
which may lead the server to enforce wrong permissions. If one of the access multiple access tokens for a single client increases the strain on the
tokens expires earlier than others, the resulting permissions may offer resource server, as it must consider every access token and calculate t
insufficient protection. he
</t> actual permissions of the client. Also, tokens may contradict each oth
er,
<t>If the payload sent to the authz-info endpoint does not parse which may lead the server to enforce wrong permissions. If one of the
to a token, the RS MUST respond with a response code equivalent to the CoAP access
tokens expires earlier than others, the resulting permissions may offer
insufficient protection.
</t>
<t>If the payload sent to the authz-info endpoint does not parse
to a token, the RS <bcp14>MUST</bcp14> respond with a response code equivalent
to the CoAP
code 4.00 (Bad Request).</t> code 4.00 (Bad Request).</t>
<t>The RS <bcp14>MAY</bcp14> make an introspection request to validate
<t>The RS MAY make an introspection request to validate the token before the token before
responding to the POST request to the authz-info endpoint, e.g. if the responding to the POST request to the authz-info endpoint, e.g., if the
token is an opaque reference. Some transport protocols may provide a way to token is an opaque reference. Some transport protocols may provide a way to
indicate that the RS is busy and the client should retry after an interval; indicate that the RS is busy and the client should retry after an interval;
this type of status update would be appropriate while the RS is waiting for this type of status update would be appropriate while the RS is waiting for
an introspection response. an introspection response.
</t> </t>
<t>Profiles <bcp14>MUST</bcp14> specify whether the authz-info endpoin
<t>Profiles MUST specify whether the authz-info endpoint is protected, t is protected,
including whether error responses from this endpoint are protected. Note that including whether error responses from this endpoint are protected. Note that
since the token contains information that allow the client and the RS to since the token contains information that allows the client and the RS to
establish a security context in the first place, mutual authentication may establish a security context in the first place, mutual authentication may
not be possible at this point.</t> not be possible at this point.</t>
<t>The default name of this endpoint in a url-path is '/authz-info';
<t>The default name of this endpoint in an url-path is '/authz-info', however, implementations are not required to use this name and can defi
however implementations are not required to use this name and can define ne
their own instead.</t> their own instead.</t>
<section anchor="verifyToken" numbered="true" toc="default">
<section anchor="verifyToken" title="Verifying an Access Token"> <name>Verifying an Access Token</name>
<t>When an RS receives an access token, it MUST verify it before storing <t>When an RS receives an access token, it <bcp14>MUST</bcp14> verif
y 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 JOSE. The type of token also has an uses COSE, while a JWT token uses JSON Object Signing and Encryption (JOSE).
influence on the verification procedure since tokens may be self-contained <!--[rfced] Should "token-by-reference" be "reference token" in this sentence?
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. Self-contained tokens MUST, at
least be integrity protected but they MAY also be encrypted.</t>
<t>For self-contained tokens the RS MUST process the security
protection of the token first, as specified by the respective token format.
For CWT the description can be found in <xref target="RFC8392"/> and for
JWT the relevant specification is <xref target="RFC7519"/>. This MUST
include a verification that security protection (and thus the token) was
generated by an AS that has the right to issue access tokens for this
RS.</t>
<t>In case the token is communicated by reference the RS needs to obtain
the claims first. When the RS uses token introspection the relevant
specification is <xref target="RFC7662"/> with CoAP transport specified in
<xref target="introspectionEndpoint"/>. </t>
<t>Errors may happen during this initial processing stage:
<list style="symbols">
<t>If the verification of the security wrapper fails, or the token 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
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. Self-contained tokens <bcp14>MUST</bcp
14> at
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
protection of the token first, as specified by the respective token f
ormat.
For CWT, the description can be found in <xref target="RFC8392"
format="default"/>; for
JWT, the relevant specification is <xref target="RFC7519" format="def
ault"/>.
This <bcp14>MUST</bcp14>
include a verification that security protection (and thus the token)
was
generated by an AS that has the right to issue access tokens for this
RS.</t>
<t>In case the token is communicated by reference, the RS needs to o
btain
the claims first. When the RS uses token introspection, the relevant
specification is <xref target="RFC7662" format="default"/> with CoAP transpo
rt specified in
<xref target="introspectionEndpoint" format="default"/>. </t>
<t>Errors may happen during this initial processing stage:
</t>
<ul spacing="normal">
<li>If the verification of the security wrapper fails, or the toke
n
was issued by an AS that does not have the right to issue tokens was issued by an AS that does not have the right to issue tokens
for the receiving RS, the RS MUST discard the token for the receiving RS, the RS <bcp14>MUST</bcp14> discard the token
and, if this was an interaction with authz-info, return an error and, if this was an interaction with authz-info, return an error
message with a response code equivalent to the CoAP code 4.01 message with a response code equivalent to the CoAP code 4.01
(Unauthorized).</t> (Unauthorized).</li>
<li>If the claims cannot be obtained, the RS <bcp14>MUST</bcp14> d
<t>If the claims cannot be obtained the RS MUST discard the token and, iscard the token and,
in case of an interaction via the authz-info endpoint, return an error in case of an interaction via the authz-info endpoint, return an error
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).</t> Request).</li>
</list> </ul>
</t> <t>Next, the RS <bcp14>MUST</bcp14> verify claims, if present, conta
ined in the
<t>Next, the RS MUST 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>
<list style="hanging"> <dl newline="true" spacing="normal">
<t hangText="iss">The issuer claim (if present) must identify the AS that <dt>iss</dt>
has produced the security protection for the access token. If that is <dd>The issuer claim (if present) must identify the AS that
not the case the RS MUST discard the token. If this was an interaction has produced the security protection for the access token. If that
with authz-info, the RS MUST also respond with a response code equivalent is
to the CoAP code 4.01 (Unauthorized).</t> not the case, the RS <bcp14>MUST</bcp14> discard the token. If thi
<t hangText="exp">The expiration date must be in the future. s was an
If that is not the case the RS MUST discard the token. If this was an interaction with authz-info, the RS <bcp14>MUST</bcp14> also respon
interaction with authz-info the RS MUST also respond with a response code d with a
equivalent to the CoAP code 4.01 (Unauthorized). Note that the RS has to response code equivalent
terminate access rights to the protected resources at the time when the to the CoAP code 4.01 (Unauthorized).</dd>
tokens expire. </t> <dt>exp</dt>
<t hangText="aud">The audience claim must refer to an audience that <dd>The expiration date must be in the future.
the RS identifies with. If that is not the case the RS MUST discard the If that is not the case, the RS <bcp14>MUST</bcp14> discard the tok
token. If this was an interaction with authz-info, the RS MUST also en. If
respond with a response code equivalent to the CoAP code 4.03 this was an
(Forbidden).</t> interaction with authz-info, the RS <bcp14>MUST</bcp14> also respon
<t hangText="scope">The RS must recognize value of the scope claim. d with a
If that is not the case the RS MUST discard the token. If this was an response code
interaction with authz-info, the RS MUST also respond with a response code equivalent to the CoAP code 4.01 (Unauthorized). Note that the RS h
equivalent to the CoAP code 4.00 (Bad Request). The RS MAY provide as to
additional information in the error response, to clarify what terminate access rights to the protected resources at the time when
went wrong.</t> the
</list></t> tokens expire. </dd>
<dt>aud</dt>
<t>Additional processing may be needed for other claims in a way <dd>The audience claim must refer to an audience that
the RS identifies with. If that is 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 response code equivalent to the CoAP code 4.03
(Forbidden).</dd>
<dt>scope</dt>
<dd>The RS must recognize value of the scope claim.
If that is not the case, the RS <bcp14>MUST</bcp14> discard the tok
en. If
this was an
interaction with authz-info, the RS <bcp14>MUST</bcp14> also respon
d with a
response code
equivalent to the CoAP code 4.00 (Bad Request). The RS <bcp14>MAY<
/bcp14>
provide
additional information in the error response to clarify what
went wrong.</dd>
</dl>
<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 (sub) 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 (exi) claim
MUST 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 e
<t>When sending error responses, the RS MAY use the error codes from rror
Section 3.1 of <xref target="RFC6750"/>, to provide additional codes from <xref target="RFC6750" sectionFormat="of" section="3.1"/>
details to the client.</t> to
</section> provide additional details to the client.</t>
</section>
<section anchor="protAuthzInfo" title="Protecting the Authorization <section anchor="protAuthzInfo" numbered="true" toc="default">
Information Endpoint"> <name>Protecting the Authorization Information Endpoint</name>
<t>As this framework can be used in RESTful environments, it is important <t>As this framework can be used in RESTful environments, it is impo
to make sure that attackers cannot perform unauthorized requests on the rtant
authz-info endpoints, other than submitting access tokens.</t> to make sure that attackers cannot perform unauthorized requests on t
he
<t>Specifically it SHOULD NOT be possible to perform GET, DELETE or authz-info endpoints, other than submitting access tokens.</t>
PUT on the authz-info endpoint.</t> <t>Specifically, it <bcp14>SHOULD NOT</bcp14> be possible to perform
GET,
<t>The RS SHOULD implement rate limiting measures to mitigate attacks aiming DELETE, or PUT on the authz-info endpoint.</t>
to overload the processing capacity of the RS by repeatedly submitting <t>The RS <bcp14>SHOULD</bcp14> implement rate-limiting measures to
tokens. For CoAP-based communication the RS could use the mechanisms from mitigate
<xref target="RFC8516"/> to indicate that it is overloaded.</t> attacks aiming
</section> to overload the processing capacity of the RS by repeatedly submittin
g
</section> tokens. For CoAP-based communication, the RS could use the mechanisms
from
<section anchor="requestC2RS" title="Client Requests to the RS"> <xref target="RFC8516" format="default"/> to indicate that it is over
<t>Before sending a request to an RS, the client MUST verify that the keys loaded.</t>
used to protect this communication are still valid. See <xref </section>
target="keyExpiration"/> for details on how the client determines the </section>
<section anchor="requestC2RS" numbered="true" toc="default">
<name>Client Requests to the RS</name>
<t>Before sending a request to an RS, the client <bcp14>MUST</bcp14> v
erify that the keys
used to protect this communication are still valid. See <xref target="keyExpir
ation" format="default"/> for details on how the client determines the
validity of the keys used.</t> validity of the keys used.</t>
<t>If an RS receives a request from a client and the target resource
<t>If an RS receives a request from a client, and the target resource requires authorization, the RS <bcp14>MUST</bcp14> first verify that it has an
requires authorization, the RS MUST first verify that it has an access token access token
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 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 cas
<t>The response code MUST be 4.01 (Unauthorized) in case the client has e the client has
not performed the proof-of-possession, or if RS has no valid access token for not performed the proof of possession or if the RS has no valid access token f
the client. If RS has an access token for the client but the token does not or
authorize access for the resource that was requested, RS MUST reject the the client. If the RS has an access token for the client but the token does no
request with a 4.03 (Forbidden). If RS has an access token for the client but t
it does not cover the action that was requested on the resource, RS MUST authorize access for the resource that was requested, the RS <bcp14>MUST</bcp1
4> reject the
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>
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 pr
<t>Note: The use of the response codes 4.03 and 4.05 is intended to prevent event
infinite loops where a dumb client optimistically tries to access a infinite loops where a dumb 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 C to determine C's privileges, these detailed clients could pretend to be the C to determine the C's privileges, these detai led
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 valida
<t>Note: The RS MAY use introspection for timely validation of an tion 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 sp
<t>Note: Matching the claims of the access token (e.g., scope) to a specific ecific
request is application specific.</t> request is application specific.</t>
<t>If the request matches a valid token and the client has performed t
<t>If the request matches a valid token and the client has performed the he
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" title="Token Expiration"> <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. Here follows which it can verify the expiration of a received access token. The fol
a list of the possibilities including what functionality they require of the lowing is
RS.</t> a list of the possibilities including what functionality they require o
f the
<t><list style="symbols"> RS.</t>
<t>The token is a CWT and includes an "exp" claim and possibly the <ul spacing="normal">
"nbf" claim. The RS verifies these by comparing them to values from <li>The token is a CWT and includes an "exp" claim and possibly the
its internal clock as defined in <xref target="RFC7519"/>. In this "nbf" claim. The RS verifies these by comparing them to values from
case the RS's internal clock must reflect the current date and time, or its internal clock, as defined in <xref target="RFC7519" format="defa
at least be synchronized with the AS's clock. How this clock ult"/>. In
synchronization would be performed is out of scope for this this case, the RS's internal clock must reflect the current date and
specification.</t> time or
at least be synchronized with the AS's clock. How this clock
<t>The RS verifies the validity of the token by performing an synchronization would be performed is out of scope for this
introspection request as specified in <xref specification.</li>
target="introspectionEndpoint"/>. This requires the RS to have a <li>The RS verifies the validity of the token by performing an
reliable network connection to the AS and to be able to handle two introspection request, as specified in <xref target="introspectionEnd
secure sessions in parallel (C to RS and RS to AS).</t> point"
format="default"/>. This requires the RS to have a
<t>In order to support token expiration for devices that have no reliable reliable network connection to the AS and to be able to handle two
way of synchronizing their internal clocks, this specification defines the secure sessions in parallel (C to RS and RS to AS).</li>
following approach: The claim "exi" ("expires in") can be used, to provide <li>In order to support token expiration for devices that have no re
the RS with the lifetime of the token in seconds from the time the RS first liable
receives the token. This mechanism only works for self-contained tokens, way of synchronizing their internal clocks, this specification define
i.e. CWTs and JWTs. For CWTs this parameter is encoded as unsigned integer, s the
while JWTs encode this as JSON number.</t> following approach: The claim "exi" ("expires in") can be used to pro
vide
<t> Processing this claim requires that the RS does the following: the RS with the lifetime of the token in seconds from the time the RS
<list style="symbols"> first
<t>For each token the RS receives, that contains an "exi" claim: receives the token. This mechanism only works for self-contained tok
Keep track of the time it received that token and revisit that list ens,
regularly to expunge expired tokens.</t> i.e., CWTs and JWTs. For CWTs, this parameter is encoded as an unsign
<t>Keep track of the identifiers of tokens containing the "exi" ed integer,
while JWTs encode this as JSON number.</li>
<li>
<t> Processing this claim requires that the RS does the following:
</t>
<ul spacing="normal">
<li>For each token the RS receives that contains an "exi" claim,
keep track of the time it received that token and revisit that li
st
regularly to expunge expired tokens.</li>
<li>
<t>Keep track of the identifiers of tokens containing the "exi
"
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 MUST be In order to avoid an unbounded memory usage growth, this <bcp14>MUST</bcp1 4> be
implemented in the following way when the "exi" claim is used: implemented in the following way when the "exi" claim is used:
<list style="symbols"> </t>
<t>When creating the token, the AS MUST add a 'cti' claim ( <ul spacing="normal">
<li>When creating the token, the AS <bcp14>MUST</bcp14> add
a 'cti' claim (
or 'jti' for JWTs) to the access token. The value of this claim or 'jti' for JWTs) to the access token. The value of this claim
MUST be created as the binary representation of the concatenation <bcp14>MUST</bcp14> be created as the binary representation of the concat enation
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 'exi' claim, issued by this AS for the
RS.</t> RS.</li>
<t>The RS MUST store the highest sequence number of an expired <li>The RS <bcp14>MUST</bcp14> store the highest sequence nu
token containing the "exi" claim that it has seen, and treat mber of an expired
token containing the "exi" 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.</t> all have the same validity time.</li>
</list></t> </ul>
</list></t> </li>
</list></t> </ul>
</li>
<t>If a token that authorizes a long running request such as a CoAP </ul>
Observe <xref target="RFC7641"/> expires, the RS MUST send an error <t>If a token that authorizes a long-running request, such as a CoAP
Observe <xref target="RFC7641" format="default"/>, expires, the RS <bcp14>MUST
</bcp14> send an error
response with the response code equivalent to the CoAP code 4.01 response with the response code equivalent to the CoAP code 4.01
(Unauthorized) to the client and then terminate processing the long running (Unauthorized) to the client and then terminate processing the long-running
request.</t> request.</t>
</section> </section>
<section anchor="keyExpiration" numbered="true" toc="default">
<section anchor="keyExpiration" title="Key Expiration"> <name>Key Expiration</name>
<t>The AS provides the client with key material that the RS uses. This can <t>The AS provides the client with key material that the RS uses. This
either be a common symmetric PoP-key, or an asymmetric key used by the RS to can
either be a common symmetric PoP key or an asymmetric key used by the RS to
authenticate towards the client. Since there is currently no expiration authenticate towards the client. Since there is currently no expiration
metadata associated to those keys, the client has no way of knowing if these metadata associated to those keys, the client has no way of knowing if these
keys are still valid. This may lead to situations where the client sends keys are still valid. This may lead to situations where the client sends
requests containing sensitive information to the RS using a key that is requests containing sensitive information to the RS using a key that is
expired and possibly in the hands of an attacker, or accepts responses from expired and possibly in the hands of an attacker or where the client accepts r esponses from
the RS that are not properly protected and could possibly have been forged by the RS that are not properly protected and could possibly have been forged by
an attacker. an attacker.
</t> </t>
<t>In order to prevent this, the client must assume that those keys ar
<t>In order to prevent this, the client must assume that those keys are e
only valid as long as the related access token is. Since the access token only valid as long as the related access token is. Since the access token
is opaque to the client, one of the following methods MUST be used to is opaque to the client, one of the following methods <bcp14>MUST</bcp14> be u sed to
inform the client about the validity of an access token: inform the client about the validity of an access token:
<list style="symbols"> </t>
<t>The client knows a default validity time for all tokens it is <ul spacing="normal">
using (i.e. how long a token is valid after being issued). This <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
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.</t> AS or published by the AS in a way that the client can query.</li>
<t>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.</t> "expires_in" parameter in the Access Information.</li>
</list> </ul>
</t> <t>A client that is not able to obtain information about the expiratio
n of a
token <bcp14>MUST NOT</bcp14> use this token.</t>
</section>
</section>
<!-- access token -->
<t>A client that is not able to obtain information about the expiration of a
token MUST NOT use this token.</t>
</section> </section>
<!--Framework-->
</section><!-- access token --> <section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
</section> <!--Framework--> <t>Security considerations applicable to authentication and authorization
in RESTful environments provided in OAuth 2.0 <xref target="RFC6749" format="d
<section anchor="security" title="Security Considerations"> efault"/> apply
to this work. Furthermore, <xref target="RFC6819" format="default"/>
<t>Security considerations applicable to authentication and authorization provides additional security considerations for OAuth, which apply to IoT
in RESTful environments provided in OAuth 2.0 <xref target="RFC6749"/> apply
to this work. Furthermore <xref target="RFC6819"/>
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"/> also apply.</t> the security considerations from <xref target="RFC7662" format="default"/> als
o apply.</t>
<t>The following subsections address issues specific to this document and <t>The following subsections address issues specific to this document and
it's use in constrained environments.</t> its use in constrained environments.</t>
<section anchor="tokenProtection" numbered="true" toc="default">
<section anchor="tokenProtection" title="Protecting Tokens"> <name>Protecting Tokens</name>
<t>A large range of threats can be mitigated by protecting the contents <t>A large range of threats can be mitigated by protecting the contents
of the access token by using a digital signature or a keyed message of the access token by using a digital signature or a keyed message
digest (MAC) or an Authenticated Encryption with Associated Data (AEAD) digest, e.g., a Message Authentication Code (MAC) or an Authenticated
algorithm. Consequently, the token integrity protection MUST be applied Encryption with Associated Data (AEAD)
to prevent the token from being modified, particularly since it contains algorithm. Consequently, the token integrity protection <bcp14>MUST</bcp
a reference to the symmetric key or the asymmetric key used for 14> be
proof-of-possession. If the access token contains the symmetric key, applied to prevent the token from being modified, particularly since it c
this symmetric key MUST be encrypted by the authorization server so that ontains
only the resource server can decrypt it. Note that using an AEAD a reference to the symmetric key or the asymmetric key used for
algorithm is preferable over using a MAC unless the token needs to be proof of possession. If the access token contains the symmetric key,
publicly readable.</t> this symmetric key <bcp14>MUST</bcp14> be encrypted by the authorization
server so
<t>If the token is intended for multiple recipients (i.e. an audience that only the resource server can decrypt it. Note that using an AEAD
algorithm is preferable over using a MAC unless the token needs to be
publicly readable.</t>
<t>If the token is intended for multiple recipients (i.e., an audience
that is a group), integrity protection of the token with a symmetric key, that is a group), integrity protection of the token with a symmetric key,
shared between the AS and the recipients, is not sufficient, since any of shared between the AS and the recipients, is not sufficient, since any of
the recipients could modify the token undetected by the other recipients. the recipients could modify the token undetected by the other recipients.
Therefore a token with a multi-recipient audience MUST be protected with Therefore, a token with a multirecipient audience <bcp14>MUST</bcp14> be p
an asymmetric signature. rotected
</t> with an asymmetric signature.</t>
<t>It is important for the authorization server to include the identity
<t>It is important for the authorization server to include the identity
of the intended recipient (the audience), typically a single resource of the intended recipient (the audience), typically a single resource
server (or a list of resource servers), in the token. The same server (or a list of resource servers), in the token. The same
shared secret MUST NOT be used as proof-of-possession key with multiple shared secret <bcp14>MUST NOT</bcp14> be used as a proof-of-possession key
resource servers since the benefit from using the proof-of-possession with
multiple resource servers, since the benefit from using the proof-of-posse
ssion
concept is then significantly reduced.</t> concept is then significantly reduced.</t>
<t>If clients are capable of doing so, they should frequently request
<t>If clients are capable of doing so, they should frequently request
fresh access tokens, as this allows the AS to keep the lifetime of the fresh access tokens, as this allows the AS to keep the lifetime of the
tokens short. This allows the AS to use shorter proof-of-possession key tokens short. This allows the AS to use shorter proof-of-possession key
sizes, which translate to a performance benefit for the client and for sizes, which translate to a performance benefit for the client and for
the resource server. Shorter keys also lead to shorter messages the resource server. Shorter keys also lead to shorter messages
(particularly with asymmetric keying material).</t> (particularly with asymmetric keying material).</t>
<t>When authorization servers bind symmetric keys to access tokens,
they <bcp14>SHOULD</bcp14> scope these access tokens to a specific permiss
ion.</t>
<t>In certain situations, it may be necessary to revoke an access
token that is still valid. Client-initiated revocation is specified
in <xref target="RFC7009" format="default"/> for OAuth 2.0. Other revoca
tion
mechanisms
are currently not specified, as the underlying assumption in OAuth
is that access tokens are issued with a relatively short lifetime.
This may not hold true for disconnected constrained devices needing
access tokens with relatively long lifetimes and would therefore
necessitate further standardization work that is out of scope for
this document.</t>
</section>
<!--token protection-->
<t>When authorization servers bind symmetric keys to access tokens, <section anchor="commSec" numbered="true" toc="default">
they SHOULD scope these access tokens to a specific permission.</t> <name>Communication Security</name>
<t>Communication with the authorization server <bcp14>MUST</bcp14> use c
<t>In certain situations it may be necessary to revoke an access onfidentiality
token that is still valid. Client-initiated revocation is specified
in <xref target="RFC7009"/> for OAuth 2.0. Other revocation mechanisms
are currently not specified, as the underlying assumption in OAuth
is that access tokens are issued with a relatively short lifetime.
This may not hold true for disconnected constrained devices, needing
access tokens with relatively long lifetimes, and would therefore
necessitate further standardization work that is out of scope for
this document.</t>
</section><!--token protection-->
<section anchor="commSec" title="Communication Security">
<t>Communication with the authorization server MUST use confidentiality
protection. This step is extremely important since the client or the protection. This step is extremely important since the client or the
RS may obtain the proof-of-possession key from the authorization 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"/>.</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 Section 5.1 <xref target="RFC8392" sectionFormat="of" section="5.1"/>. Such addition
of <xref target="RFC8392"/>. Such additional protection can be necessary al
if the token is later transferred over an insecure connection protection can be necessary
(e.g. when it is sent to the authz-info endpoint).</t> if the token is later transferred over an insecure connection
(e.g., when it is sent to the authz-info endpoint).</t>
<t>Care must by 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 s frequently, by using software isolation techniques, and by using hardware
ecurity.</t> security.</t>
</section><!--communication security--> </section>
<!--communication security-->
<section anchor="keys" title="Long-Term Credentials"> <section anchor="keys" numbered="true" toc="default">
<t>Both clients and RSs have long-term credentials that are used to <name>Long-Term Credentials</name>
secure communications, and authenticate to the AS. These credentials <t>Both the clients and RSs have long-term credentials that are used to
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
devices needs to have procedures to invalidate any access these devices needs to have procedures to invalidate any access these
credentials give and to revoke tokens linked to such credentials. The credentials give and needs to revoke tokens linked to such credentials. T
loss of a credential linked to a specific device MUST NOT lead to a he
compromise of other credentials not linked to that device, therefore loss of a credential linked to a specific device <bcp14>MUST NOT</bcp14> l
secret keys used for authentication MUST NOT be shared between more than ead to a
compromise of other credentials not linked to that device; therefore,
secret keys used for authentication <bcp14>MUST NOT</bcp14> be shared betw
een more than
two parties.</t> two parties.</t>
<t>Operators of the clients or RSs <bcp14>SHOULD</bcp14> have procedures
<t>Operators of clients or RS SHOULD have procedures in place to 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 decommission
<t>Operators also SHOULD have procedures for decommissioning devices, ing 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><!--credential livecycle--> </section>
<!--credential livecycle-->
<section anchor="unprotected-as-information"
title="Unprotected AS Request Creation Hints">
<t>Initially, no secure channel exists to protect the communication <section anchor="unprotected-as-information" numbered="true" toc="default">
between C and RS. Thus, C cannot determine if the "AS Request <name>Unprotected AS Request Creation Hints</name>
Creation Hints" contained in an unprotected response from RS to an <t>Initially, no secure channel exists to protect the communication
unauthorized request (see <xref target="asInfo"/>) are authentic. C between the C and RS. Thus, the C cannot determine if the "AS Request
therefore MUST determine if an AS is authorized to provide access Creation Hints" contained in an unprotected response from the RS to an
unauthorized request (see <xref target="asInfo" format="default"/>) are
authentic. Therefore, the C
<bcp14>MUST</bcp14> determine if an AS is authorized to provide
access
tokens for a certain RS. How this determination is implemented is out tokens for a certain RS. How this determination is implemented is out
of scope for this document and left to the applications.</t> of scope for this document and left to the applications.</t>
</section> </section>
<section anchor="minimalCommSecReq" numbered="true" toc="default">
<section anchor="minimalCommSecReq" title="Minimal Security Requirements <name>Minimal Security Requirements for Communication</name>
for Communication"> <t>This section summarizes the minimal requirements for the
<t>This section summarizes the minimal requirements for the
communication security of the different protocol interactions. communication security of the different protocol interactions.
</t>
<list style="hanging"> <dl newline="true" spacing="normal">
<t hangText="C-AS">All communication between the client and the <dt>C-AS</dt>
Authorization Server MUST be encrypted, integrity and replay <dd>All communication between the client and the
protected. Furthermore responses from the AS to the client MUST be authorization server <bcp14>MUST</bcp14> be encrypted and integrity and
replay
protected. Furthermore, responses from the AS to the client <bcp14>MUST
</bcp14> be
bound to the client's request to avoid attacks where the attacker bound to the client's request to avoid attacks where the attacker
swaps the intended response for an older one valid for a previous swaps the intended response for an older one valid for a previous
request. This requires that the client and the Authorization Server request. This requires that the client and the authorization server
have previously exchanged either a shared secret or their public have previously exchanged either a shared secret or their public
keys in order to negotiate a secure communication. Furthermore the keys in order to negotiate a secure communication. Furthermore, the
client MUST be able to determine whether an AS has the authority client <bcp14>MUST</bcp14> be able to determine whether an AS has the a
to issue access tokens for a certain RS. This can for example be uthority
done through pre-configured lists, or through an online lookup to issue access tokens for a certain RS. This can, for example, be
done through preconfigured lists or through an online lookup
mechanism that in turn also must be secured. mechanism that in turn also must be secured.
</t> </dd>
<dt>RS-AS</dt>
<t hangText="RS-AS">The communication between the Resource <dd>The communication between the resource
Server and the Authorization Server via the introspection endpoint server and the authorization server via the introspection endpoint
MUST be encrypted, integrity and replay protected. Furthermore <bcp14>MUST</bcp14> be encrypted and integrity and replay protected. Fu
responses from the AS to the RS MUST be bound to the RS's request. rthermore,
This requires that the RS and the Authorization Server responses from the AS to the RS <bcp14>MUST</bcp14> be bound to the RS'
have previously exchanged either a shared secret, or their public s request.
keys in order to negotiate a secure communication. Furthermore the This requires that the RS and the authorization server
RS MUST be able to determine whether an AS has the authority have previously exchanged either a shared secret or their public
keys in order to negotiate a secure communication. Furthermore, the
RS <bcp14>MUST</bcp14> be able to determine whether an AS has the autho
rity
to issue access tokens itself. This is usually configured out of to issue access tokens itself. This is usually configured out of
band, but could also be performed through an online lookup mechanism band but could also be performed through an online lookup mechanism,
provided that it is also secured in the same way.</t> provided that it is also secured in the same way.</dd>
<dt>C-RS</dt>
<t hangText="C-RS">The initial communication between the client <dd>The initial communication between the client
and the Resource Server can not be secured in general, since and the resource server cannot be secured in general, since
the RS is not in possession of on access token for that client, the RS is not in possession of on access token for that client,
which would carry the necessary parameters. If both parties which would carry the necessary parameters. If both parties
support DTLS without client authentication it is RECOMMEND to use support DTLS without client authentication, it is <bcp14>RECOMMENDED</b cp14> to use
this mechanism for protecting the initial communication. this mechanism for protecting the initial communication.
After the client has successfully transmitted the access token to the After the client has successfully transmitted the access token to the
RS, a secure communication protocol MUST be established between RS, a secure communication protocol <bcp14>MUST</bcp14> be established
client and RS for the actual resource request. This protocol MUST between the
provide confidentiality, integrity and replay protection as well as a client and RS for the actual resource request. This protocol <bcp14>MU
ST</bcp14>
provide confidentiality, integrity, and replay protection, as well as a
binding between requests and responses. This requires that the binding between requests and responses. This requires that the
client learned either the RS's public key or received a symmetric client learned either the RS's public key or received a symmetric
proof-of-possession key bound to the access token from the AS. proof-of-possession key bound to the access token from the AS.
The RS must have learned either the client's public key or a shared The RS must have learned either the client's public key, a shared
symmetric key from the claims in the token or an introspection symmetric key from the claims in the token, or an introspection
request. Since ACE does not provide profile negotiation between request. Since ACE does not provide profile negotiation between the
C and RS, the client MUST have learned what profile the RS C and RS, the client <bcp14>MUST</bcp14> have learned what profile the
supports (e.g. from the AS or pre-configured) and initiate the RS
communication accordingly.</t> supports (e.g., from the AS or preconfigured) and initiated the
</list></t> communication accordingly.</dd>
</section> </dl>
<section anchor="nonce" title="Token Freshness and Expiration"> </section>
<t>An RS that is offline faces the problem of clock drift. Since it <section anchor="nonce" numbered="true" toc="default">
<name>Token Freshness and Expiration</name>
<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"/> 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 "exp" 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 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 "exi" 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 "exi" approach has some drawbacks that
need to be considered: need to be considered:
<list> </t>
<t>A malicious client may hold back tokens with the "exi" claim in <ul spacing="normal">
order to prolong their lifespan.</t> <li>A malicious client may hold back tokens with the "exi" claim in
<t>If an RS loses state (e.g. due to an unscheduled reboot), it order to prolong their lifespan.</li>
<li>
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 "exi" claims of
tokens it is storing.</t> tokens it is storing.</li>
</list> </ul>
<t>
The first drawback is inherent to the deployment scenario and the "exi" The first drawback is inherent to the deployment scenario and the "exi"
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 "exi" counters to persistent memory.</t>
</section> </section>
<section anchor="mixnmatch" numbered="true" toc="default">
<section anchor="mixnmatch" title="Combining Profiles"> <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
new profile that combines existing profiles MUST specify how the new profile that combines existing profiles <bcp14>MUST</bcp14> specify ho
existing profiles' security properties are achieved. Any profile w the
therefore MUST clearly specify its security requirements and MUST existing profiles' security properties are achieved. Therefore, any profil
e
<bcp14>MUST</bcp14> clearly specify its security requirements and <bcp14>M
UST</bcp14>
document if its security depends on the combination of various document if its security depends on the combination of various
protocol interactions.</t> protocol interactions.</t>
</section> </section>
<section anchor="infoLeak" numbered="true" toc="default">
<section anchor="infoLeak" title="Unprotected Information"> <name>Unprotected Information</name>
<t>Communication with the authz-info endpoint, as well as the <t>Communication with the authz-info endpoint, as well as the
various error responses defined in this framework, all potentially various error responses defined in this framework, potentially
include sending information over an unprotected channel. includes sending information over an unprotected channel.
These messages may leak information to an adversary, or may be These messages may leak information to an adversary or may be
manipulated by active attackers to induce incorrect behavior. For manipulated by active attackers to induce incorrect behavior. For
example error responses for requests to the Authorization Information example, error responses for requests to the authorization information
endpoint can reveal information about an otherwise opaque access token endpoint can reveal information about an otherwise opaque access token
to an adversary who has intercepted this token.</t> to an adversary who has intercepted this token.</t>
<t>As far as error messages are concerned, this framework is written
<t>As far as error messages are concerned, this framework is written
under the assumption that, in general, the benefits of detailed error under the assumption that, in general, the benefits of detailed error
messages outweigh the risk due to information leakage. For particular messages outweigh the risk due to information leakage. For particular
use cases, where this assessment does not apply, detailed error use cases where this assessment does not apply, detailed error
messages can be replaced by more generic ones.</t> messages can be replaced by more generic ones.</t>
<t>In some scenarios, it may be possible to protect the
<t>In some scenarios it may be possible to protect the communication with the authz-info endpoint (e.g., through
communication with the authz-info endpoint (e.g. through
DTLS with only server-side authentication). In cases where DTLS with only server-side authentication). In cases where
this is not possible, it is RECOMMENDED to use encrypted this is not possible, it is <bcp14>RECOMMENDED</bcp14> to use encrypted
CWTs or tokens that are opaque references and need to be subjected to CWTs or tokens that are opaque references and need to be subjected to
introspection by the RS.</t> introspection by the RS.</t>
<t>If the initial Unauthorized Resource Request message (see <xref targe
<t>If the initial unauthorized resource request message (see <xref t="rreq" format="default"/>) is used, the client <bcp14>MUST</bcp14> make sure t
target="rreq"/>) is used, the client MUST make sure that it is hat 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 "ace_profile"
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 RS's 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" title="Identifying Audiences"> <name>Identifying Audiences</name>
<t>The audience claim as defined in <xref target="RFC7519"/> <t>The audience claim, as defined in <xref target="RFC7519" format="defa
ult"/>,
and the equivalent "audience" parameter from and the equivalent "audience" parameter from
<xref target="RFC8693"/> 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 RECOMMENDED to apply the If this approach is used, it is <bcp14>RECOMMENDED</bcp14> to apply the
procedure from section 3 of <xref target="RFC6920"/>.</t> procedure from <xref target="RFC6920" sectionFormat="of" section="3"/>.</
t>
<t>If the audience addresses a group of resource servers, the mapping <t>If the audience addresses a group of resource servers, the mapping
of group identifier to individual RS has to be provisioned to each RS of a group identifier to an individual RS has to be provisioned to each R
S
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 NOT RECOMMENDED 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 "audience" 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 "audience" 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 th
e
directory data must be assured. Note that the "audience" hint directory data must be assured. Note that the "audience" 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"/> is not typically source authenticated and integrity target="asInfo" format="default"/>) is not typically source authenticated
protected, and should therefore not be treated a trusted value.</t> and
</section> integrity protected and should therefore not be treated a trusted value.<
/t>
<section anchor="introDos" title="Denial of Service Against or with </section>
Introspection"> <section anchor="introDos" numbered="true" toc="default">
<t> <name>Denial of Service Against or with Introspection</name>
<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>
<t>First, an attacker could perform a denial-of-service attack against
<t>First, an attacker could perform a denial of service attack against
the introspection endpoint at the AS in order to prevent validation of the introspection endpoint at the AS in order to prevent validation of
access tokens. To maintain the security of the system, an RS that is access tokens. To maintain the security of the system, an RS that is
configured to use introspection MUST NOT allow access based on a token configured to use introspection <bcp14>MUST NOT</bcp14> allow access base d on a token
for which it couldn't reach the introspection endpoint.</t> for which it couldn't reach the introspection endpoint.</t>
<t>Second, an attacker could use the fact that an RS performs
<t>Second, an attacker could use the fact that an RS performs introspection to perform a denial-of-service attack against that RS by
introspection to perform a denial of service attack against that RS by
repeatedly sending tokens to its authz-info endpoint that require an repeatedly sending tokens to its authz-info endpoint that require an
introspection call. RS can mitigate such attacks by implementing rate introspection call. The RS can mitigate such attacks by implementing rate
limits on how many introspection requests they perform in a given time limits on how many introspection requests they perform in a given time
interval for a certain client IP address submitting tokens to interval for a certain client IP address submitting tokens to
/authz-info. When that limit has been reached, incoming requests from /authz-info. When that limit has been reached, incoming requests from
that address are rejected for a certain amount of time. A general rate that address are rejected for a certain amount of time. A general rate
limit on the introspection requests should also be considered, to limit on the introspection requests should also be considered in order to
mitigate distributed attacks.</t> mitigate distributed attacks.</t>
</section>
</section> </section>
</section> <section anchor="privacy" numbered="true" toc="default">
<name>Privacy Considerations</name>
<section anchor="privacy" title="Privacy Considerations">
<t>Implementers and users should be aware of the privacy implications <t>Implementers and users should be aware of the privacy implications
of the different possible deployments of this framework.</t> of the different possible deployments of this framework.</t>
<t>The AS is in a very central position and can potentially learn sensitiv e <t>The AS is in a very central position and can potentially learn sensitiv e
information about the clients requesting access tokens. If the client information about the clients requesting access tokens. If the client
credentials grant is used, the AS can track what kind of access credentials grant is used, the AS can track what kind of access
the client intends to perform. With other grants this can be prevented the client intends to perform. With other grants, this can be prevented
by the Resource Owner. To do so, the resource owner needs to bind the by the resource owner. To do so, the resource owner needs to bind the
grants it issues to anonymous, ephemeral credentials that do not allow grants it issues to anonymous, ephemeral credentials that do not allow
the AS to link different grants and thus different access token requests the AS to link different grants and thus different access token requests
by the same client.</t> by the same client.</t>
<t>The claims contained in a token can reveal privacy-sensitive
<t>The claims contained in a token can reveal privacy sensitive
information about the client and the RS to any party having access to information about the client and the RS to any party having access to
them (whether by processing the content of a self-contained token or by them (whether by processing the content of a self-contained token or by
introspection). The AS SHOULD be configured to minimize the information introspection). The AS <bcp14>SHOULD</bcp14> be configured to minimize th e information
about clients and RSs disclosed in the tokens it issues.</t> about clients and RSs disclosed in the tokens it issues.</t>
<t>If tokens are only integrity protected and not encrypted, they <t>If tokens are only integrity protected and not encrypted, they
may reveal information to attackers listening on the wire, or able to may reveal information to attackers listening on the wire or be able to
acquire the access tokens in some other way. In the case of CWTs acquire the access tokens in some other way. In the case of CWTs,
the token may, e.g., reveal the audience, the scope and the confirmation the token may, e.g., reveal the audience, the scope, and the confirmation
method used by the client. The latter may reveal the identity of the method used by the client. The latter may reveal the identity of the
device or application running the client. This may be linkable to device or application running the client. This may be linkable to
the identity of the person using the client (if there is a person and the identity of the person using the client (if there is a person and
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"/>) may disclose information about RS and/or its <xref target="asInfo" format="default"/>) may disclose information about t
existing relationship with C. It is advisable to include as little he RS
information as possible in an unencrypted response. Even the absolute URI and/or its
of the AS may reveal sensitive information about the service that RS provides. D existing relationship with the C. It is advisable to include as little
evelopers must ensure that the RS does not disclose information that has an impa information as possible in an unencrypted response. Even the absolute URI
ct on the privacy of the stakeholders in the "AS Request Creation Hints". They m of the AS may reveal sensitive information about the service that the RS provide
ay choose to use a different mechanism for the discovery of the AS if necessary. s. Developers must ensure that the RS does not disclose information that has an
If means of encrypting impact on the privacy of the stakeholders in the "AS Request Creation Hints". Th
communication between C and RS already exist, more detailed information ey may choose to use a different mechanism for the discovery of the AS if necess
may be included with an error response to provide C with sufficient ary. If means of encrypting
communication between the C and RS already exist, more detailed informatio
n
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 anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
</section> <!--[rfced] May the titles of these subsections be made consistent?
The original is inconsistent about including the word "Registration" or
<section anchor="iana" title="IANA Considerations"> "Registry" vs. no additional word. Is the following option acceptable
<t>This document creates several registries with a registration policy of (no additional word)? (The title of 8.15 was changed to singular because
"Expert Review"; guidelines to the experts are given in it contains one registration.)
<xref target="IANAinstructions"/>.</t>
<section anchor="IANAASInformation"
title="ACE Authorization Server Request Creation Hints">
<t>This specification establishes the IANA "ACE Authorization Server
Request Creation Hints" registry. The registry has been created to use the
"Expert Review" registration procedure <xref target="RFC8126"/>.
It should be noted that, in addition to the expert review, some portions of
the registry require a specification, potentially a Standards Track RFC, be
supplied as well.</t>
<t>The columns of the registry are: 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
<list style='hanging'> Perhaps:
<t hangText='Name'>The name of the parameter</t> 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 hangText='CBOR Key'>CBOR map key for the parameter. Different ranges <t>This document creates several registries with a registration policy of
of values use different registration policies <xref target="RFC8126"/>. Expert Review; guidelines to the experts are given in
<xref target="IANAinstructions" format="default"/>.</t>
<section anchor="IANAASInformation" numbered="true" toc="default">
<name>ACE Authorization Server Request Creation Hints</name>
<t>This specification establishes the IANA "ACE Authorization Server
Request Creation Hints" registry.</t>
<t>The columns of the registry are:</t>
<dl newline="false">
<dt>Name:</dt>
<dd>The name of the parameter.</dd>
<dt>CBOR Key:</dt>
<dd>CBOR map key for the parameter. Different ranges
of values use different registration policies <xref target="RFC8126" forma
t="default"/>.
Integer values from -256 to 255 are designated as Standards Integer values from -256 to 255 are designated as Standards
Action. Integer values from -65536 to -257 and from 256 to 65535 Action. Integer values from -65536 to -257 and from 256 to 65535
are designated as Specification Required. Integer values greater than are designated as Specification Required. Integer values greater than
65535 are designated as Expert Review. Integer values less than -65536 65535 are designated as Expert Review. Integer values less than -65536
are marked as Private Use.</t> are marked as Private Use.</dd>
<dt>Value Type:</dt>
<t hangText='Value Type'>The CBOR data types allowable for the values of <dd>The CBOR data types allowable for the values of
this parameter.</t> this parameter.</dd>
<dt>Reference:</dt>
<t hangText='Reference'>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.</t> exists.</dd>
</list></t> </dl>
<t>This registry has been initially populated by the values in <xref targ
<t>This registry will be initially populated by the values in et="table_asinfo"/>. The Reference column for all of these entries is this docum
<xref target="fig:asinfo"/>. The Reference column for all of ent.</t>
these entries will be this document.</t> </section>
</section> <section anchor="IANAcoreRT" numbered="true" toc="default">
<name>CoRE Resource Type Registry</name>
<section anchor="IANAcoreRT" title="CoRE Resource Type Registry"> <t>IANA has registered a new Resource Type (rt=) Link Target
<t>IANA is requested to register 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"/> registry:</t> Parameters" <xref target="IANA.CoreParameters" format="default"/> registry:<
/t>
<t><?rfc subcompact="yes"?> <dl newline="false" spacing="compact">
<list style='symbols'> <dt>Value:</dt>
<t>Value: <spanx style="verb">ace.ai</spanx></t> <dd><tt>ace.ai</tt></dd>
<t>Description: ACE-OAuth authz-info endpoint resource.</t> <dt>Description:</dt>
<t>Reference: [this document]</t> <dd>ACE-OAuth authz-info endpoint resource.</dd>
</list></t> <dt>Reference:</dt>
<t>Specific ACE-OAuth profiles can use this common resource type for <dd>RFC 9200</dd>
</dl>
<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" <name>OAuth Extensions Error Registration</name>
title="OAuth Extensions Error Registration"> <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"/>.</t> <xref target="IANA.OAuthExtensionsErrorRegistry" format="default"/>.</t>
<dl newline="false" spacing="compact">
<t><?rfc subcompact="yes"?> <dt>Error name:</dt>
<list style='symbols'> <dd><tt>unsupported_pop_key</tt></dd>
<t>Error name: <spanx style="verb">unsupported_pop_key</spanx></t> <dt>Error usage location:</dt>
<t>Error usage location: token error response</t> <dd>token error response</dd>
<t>Related protocol extension: [this document]</t> <dt>Related protocol extension:</dt>
<t>Change Controller: IESG</t> <dd>RFC 9200</dd>
<t>Specification document(s): <xref target="errorsToken"/> of <dt>Change Controller:</dt>
[this document]</t> <dd>IETF</dd>
</list></t> <dt>Specification document(s):</dt>
<dd><xref target="errorsToken" format="default"/> of RFC 9200</dd>
<t><?rfc subcompact="yes"?> </dl>
<list style='symbols'> <dl newline="false" spacing="compact">
<t>Error name: <spanx style="verb">incompatible_ace_profiles</spanx></t> <dt>Error name:</dt>
<t>Error usage location: token error response</t> <dd><tt>incompatible_ace_profiles</tt></dd>
<t>Related protocol extension: [this document]</t> <dt>Error usage location:</dt>
<t>Change Controller: IESG</t> <dd>token error response</dd>
<t>Specification document(s): <xref target="errorsToken"/> of <dt>Related protocol extension:</dt>
[this document]</t> <dd>RFC 9200</dd>
</list></t> <dt>Change Controller:</dt>
</section> <dd>IETF</dd>
<section anchor="IANAErrorCBORMappings" <dt>Specification document(s):</dt>
title="OAuth Error Code CBOR Mappings Registry"> <dd><xref target="errorsToken" format="default"/> of RFC 9200</dd>
<t>This specification establishes the IANA "OAuth Error Code </dl>
CBOR Mappings" registry. The registry has been created to use the "Expert </section>
Review" registration procedure <xref target="RFC8126"/>, except <section anchor="IANAErrorCBORMappings" numbered="true" toc="default">
for the value range designated for private use.</t> <name>OAuth Error Code CBOR Mappings Registry</name>
<t>This specification establishes the IANA "OAuth Error Code
<t>The columns of the registry are: CBOR Mappings" registry.</t>
<list style='hanging'>
<t hangText='Name'>The OAuth Error Code name, refers to the name in
Section 5.2. of <xref target="RFC6749"/>, e.g., "invalid_request".</t>
<t hangText='CBOR Value'>CBOR abbreviation for this error code. Integer
values less than -65536 are marked as "Private Use", all other values use
the registration policy "Expert Review" <xref target="RFC8126"/>.</t>
<t hangText='Reference'>This contains a pointer to the public
specification of the error code abbreviation, if one exists.</t>
</list></t>
<t>This registry will be initially populated by the values in
<xref target="fig:cborErrorCodes"/>. The Reference column for all of
these entries will be this document.</t>
</section>
<section anchor="IANAGrantTypeMappings"
title="OAuth Grant Type CBOR Mappings">
<t>This specification establishes the IANA "OAuth Grant Type CBOR Mappings"
registry. The registry has been created to use the "Expert Review"
registration procedure <xref target="RFC8126"/>, except for the value range
designated for private use. </t>
<t>The columns of this registry are:
<list style='hanging'>
<t hangText='Name'>The name of the grant type as specified in
Section 1.3 of <xref target="RFC6749"/>.</t>
<t hangText='CBOR Value'>CBOR abbreviation for this grant type. Integer
values less than -65536 are marked as "Private Use", all other values use
the registration policy "Expert Review" <xref target="RFC8126"/>.</t>
<t hangText='Reference'>This contains a pointer to the public
specification of the grant type abbreviation, if one exists.</t>
<t hangText='Original Specification'>This contains a pointer to
the public specification of the grant type, if one exists.</t>
</list></t>
<t>This registry will be initially populated by the values in
<xref target="fig:grant_types"/>. The Reference column for all of
these entries will be this document.</t>
</section>
<section anchor="IANAOAuthTokenType" title="OAuth Access Token Types">
<t>This section registers the following new token type in the
"OAuth Access Token Types" registry <xref
target="IANA.OAuthAccessTokenTypes"/>.</t>
<t><?rfc subcompact="yes"?>
<list style='symbols'>
<t>Type name: <spanx style="verb">PoP</spanx></t>
<t>Additional Token Endpoint Response Parameters: "cnf", "rs_cnf"
see section 3.3 of <xref target="I-D.ietf-ace-oauth-params"/>.</t>
<t>HTTP Authentication Scheme(s): N/A</t>
<t>Change Controller: IETF</t>
<t>Specification document(s): [this document]</t>
</list></t>
</section>
<section anchor="IANATokenTypeMappings"
title="OAuth Access Token Type CBOR Mappings">
<t>This specification established the IANA "OAuth Access Token Type CBOR
Mappings" registry. The registry has been created to use the "Expert
Review" registration procedure <xref target="RFC8126"/>, except for the
value range designated for private use. </t>
<t>The columns of this registry are:
<list style='hanging'>
<t hangText='Name'>The name of token type as registered in the
OAuth Access Token Types registry, e.g., "Bearer".</t>
<t hangText='CBOR Value'>CBOR abbreviation for this token type. Integer
values less than -65536 are marked as "Private Use", all other values use
the registration policy "Expert Review" <xref target="RFC8126"/>.</t>
<t hangText='Reference'>This contains a pointer to the public
specification of the OAuth token type abbreviation, if one exists.</t>
<t hangText='Original Specification'>This contains a pointer to
the public specification of the OAuth token type, if one exists.</t>
</list></t>
<section anchor="IANATokenTypeMappingsInitial" title="Initial Registry Conte
nts">
<t>
<?rfc subcompact="yes"?>
<list style='symbols'>
<t>Name: <spanx style="verb">Bearer</spanx></t>
<t>Value: 1</t>
<t>Reference: [this document]</t>
<t>Original Specification: <xref target="RFC6749"/></t>
</list>
</t>
<t>
<?rfc subcompact="yes"?>
<list style='symbols'>
<t>Name: <spanx style="verb">PoP</spanx></t>
<t>Value: 2</t>
<t>Reference: [this document]</t>
<t>Original Specification: [this document]</t>
</list>
</t>
</section>
</section>
<section anchor="IANAProfile"
title="ACE Profile Registry">
<t>This specification establishes the IANA "ACE Profile" registry. The
registry has been created to use the "Expert Review" registration
procedure <xref target="RFC8126"/>. It should be noted that, in addition to
the expert review, some portions of the registry require a specification,
potentially a Standards Track RFC, be supplied as well.</t>
<t>The columns of this registry are:
<list style='hanging'>
<t hangText='Name'> The name of the profile, to be used as value of
the profile attribute.</t>
<t hangText='Description'> Text giving an overview of the profile and
the context it is developed for.</t>
<t hangText='CBOR Value'>CBOR abbreviation for this profile name.
Different ranges of values use different registration policies <xref
target="RFC8126"/>. Integer values from -256 to 255 are designated as
Standards Action. Integer values from -65536 to -257 and from 256 to
65535 are designated as Specification Required. Integer values greater
than 65535 are designated as "Expert Review". Integer values less than
-65536 are marked as Private Use.</t>
<t hangText='Reference'>This contains a pointer to the public
specification of the profile abbreviation, if one exists.</t>
</list></t>
<t>This registry will be initially empty and will be populated by the
registrations from the ACE framework profiles.</t>
</section>
<section anchor="IANAOAuthParameter"
title="OAuth Parameter Registration">
<t>This specification registers the following parameter in the "OAuth
Parameters" registry <xref target="IANA.OAuthParameters"/>:</t>
<t><?rfc subcompact="yes"?>
<list style='symbols'>
<t>Name: <spanx style="verb">ace_profile</spanx></t>
<t>Parameter Usage Location: token response</t>
<t>Change Controller: IESG</t>
<t>Reference: <xref target="tokenResponse"/> and
<xref target="paramProfile"/> of [this document]</t>
</list></t>
</section>
<section anchor="IANAOAuthParameterMappingsRegistry"
title="OAuth Parameters CBOR Mappings Registry">
<t>This specification establishes the IANA "OAuth Parameters CBOR Mappings"
registry. The registry has been created to use the "Expert Review"
registration procedure <xref target="RFC8126"/>, except for the value range
designated for private use.</t>
<t>The columns of this registry are: <!--[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>
<dl newline="false">
<dt>Name:</dt>
<dd>The OAuth Error Code name, refers to the name in
<xref target="RFC6749" sectionFormat="of" section="5.2"/>, e.g.,
"invalid_request".</dd>
<dt>CBOR Value:</dt>
<dd>CBOR abbreviation for this error code.
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>
<dt>Reference:</dt>
<dd>This contains a pointer to the public
specification of the error code abbreviation, if one exists.</dd>
<dt>Original Specification:</dt>
<dd>This contains a pointer to the public
specification of the error code, if one exists.</dd>
</dl>
<list style='hanging'> <t>This registry has been initially populated by the values in <xref targ
<t hangText='Name'>The OAuth Parameter name, refers to the name in et="table_cborErrorCodes"/>. The Reference column for all of these entries is th
the OAuth parameter registry, e.g., "client_id".</t> is document.</t>
<t hangText='CBOR Key'>CBOR map key for this parameter. Integer </section>
values less than -65536 are marked as "Private Use", all other values use <section anchor="IANAGrantTypeMappings" numbered="true" toc="default">
the registration policy "Expert Review" <xref target="RFC8126"/>.</t> <name>OAuth Grant Type CBOR Mappings</name>
<t>This specification establishes the IANA "OAuth Grant Type CBOR Mappin
gs"
registry.</t>
<t>The columns of this registry are:</t>
<dl newline="false">
<dt>Name:</dt>
<dd>The name of the grant type, as specified in
<xref target="RFC6749" sectionFormat="of" section="1.3"/>.</dd>
<dt>CBOR Value:</dt>
<dd>CBOR abbreviation for this grant type. Integer
values less than -65536 are marked as Private Use; all other values use
the registration policy Expert Review <xref target="RFC8126" format="defau
lt"/>.</dd>
<dt>Reference:</dt>
<dd>This contains a pointer to the public
specification of the grant type abbreviation, if one exists.</dd>
<dt>Original Specification:</dt>
<dd>This contains a pointer to
the public specification of the grant type, if one exists.</dd>
</dl>
<t hangText='Value Type'>The allowable CBOR data types for values <t>This registry has been initially populated by the values in <xref targ
of this parameter.</t> et="table_grant_types"/>. The Reference column for all of these entries is this
document.</t>
<t hangText='Reference'>This contains a pointer to the public </section>
specification of the OAuth parameter abbreviation, if one exists.</t> <section anchor="IANAOAuthTokenType" numbered="true" toc="default">
</list></t> <name>OAuth Access Token Types</name>
<t>This section registers the following new token type in the
"OAuth Access Token Types" registry <xref target="IANA.OAuthAccessTokenTypes
" format="default"/>.</t>
<dl newline="false" spacing="compact">
<dt>Type name:</dt>
<dd><tt>PoP</tt></dd>
<dt>Additional Token Endpoint Response Parameters:</dt>
<dd>"cnf", "rs_cnf" (see <xref target="RFC8747" sectionFormat="of" sect
ion="3.1"/> <xref target="RFC9201"
sectionFormat="of" section="3.2"/>).</dd>
<dt>HTTP Authentication Scheme(s):</dt>
<dd>N/A</dd>
<dt>Change Controller:</dt>
<dd>IETF</dd>
<dt>Specification document(s):</dt>
<dd>RFC 9200</dd>
</dl>
</section>
<section anchor="IANATokenTypeMappings" numbered="true" toc="default">
<name>OAuth Access Token Type CBOR Mappings</name>
<t>This specification establishes the IANA "OAuth Access Token Type CBOR
Mappings" registry.</t>
<t>The columns of this registry are:</t>
<dl newline="false">
<dt>Name:</dt>
<dd>The name of the token type, as registered in the
"OAuth Access Token Types" registry, e.g., "Bearer".</dd>
<dt>CBOR Value:</dt>
<dd>CBOR abbreviation for this token type. Integer
values less than -65536 are marked as Private Use; all other values use
the registration policy Expert Review <xref target="RFC8126" format="defau
lt"/>.</dd>
<dt>Reference:</dt>
<dd>This contains a pointer to the public
specification of the OAuth token type abbreviation, if one exists.</dd>
<dt>Original Specification:</dt>
<dd>This contains a pointer to
the public specification of the OAuth token type, if one exists.</dd>
</dl>
<section anchor="IANATokenTypeMappingsInitial" numbered="true" toc="defa
ult">
<name>Initial Registry Contents</name>
<dl newline="false" spacing="compact">
<dt>Name:</dt>
<dd><tt>Bearer</tt></dd>
<dt>Value:</dt>
<dd>1</dd>
<dt>Reference:</dt>
<dd>RFC 9200</dd>
<dt>Original Specification:</dt>
<dd><xref target="RFC6749" format="default"/></dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Name:</dt>
<dd><tt>PoP</tt></dd>
<dt>Value:</dt>
<dd>2</dd>
<dt>Reference:</dt>
<dd>RFC 9200</dd>
<dt>Original Specification:</dt>
<dd>RFC 9200</dd>
</dl>
</section>
</section>
<section anchor="IANAProfile" numbered="true" toc="default">
<name>ACE Profile Registry</name>
<t>This specification establishes the IANA "ACE Profile" registry. </t>
<t>The columns of this registry are:</t>
<dl newline="false">
<dt>Name:</dt>
<dd> The name of the profile to be used as the value of
the profile attribute.</dd>
<dt>Description:</dt>
<dd> Text giving an overview of the profile and
the context it is developed for.</dd>
<dt>CBOR Value:</dt>
<dd>CBOR abbreviation for this profile name. Different ranges of value
s use different registration policies <xref
target="RFC8126" format="default"/>. Integer values from -256 to 255 a
re
designated as Standards Action. Integer values from -65536 to -257 and
from 256
to 65535 are designated as Specification Required. Integer values grea
ter
than 65535 are designated as Expert Review. Integer values less than
-65536 are marked as Private Use.</dd>
<dt>Reference:</dt>
<dd>This contains a pointer to the public
specification of the profile abbreviation, if one exists.</dd>
</dl>
</section>
<section anchor="IANAOAuthParameter" numbered="true" toc="default">
<name>OAuth Parameter Registration</name>
<t>This specification registers the following parameter in the "OAuth
Parameters" registry <xref target="IANA.OAuthParameters" format="default"/>:
</t>
<dl newline="false" spacing="compact">
<dt>Name:</dt>
<dd><tt>ace_profile</tt></dd>
<dt>Parameter Usage Location:</dt>
<dd>token response</dd>
<dt>Change Controller:</dt>
<dd>IETF</dd>
<dt>Reference:</dt>
<dd>Sections <xref target="tokenResponse" format="counter"/> and
<xref target="paramProfile" format="counter"/> of RFC 9200</dd>
</dl>
</section>
<section anchor="IANAOAuthParameterMappingsRegistry" numbered="true" toc="
default">
<name>OAuth Parameters CBOR Mappings Registry</name>
<t>This specification establishes the IANA "OAuth Parameters CBOR Mappin
gs"
registry.</t>
<t>The columns of this registry are:</t>
<dl newline="false">
<dt>Name:</dt>
<dd>The OAuth Parameter name, refers to the name in
the OAuth parameter registry, e.g., "client_id".</dd>
<dt>CBOR Key:</dt>
<dd>CBOR map key for this parameter. Integer
values less than -65536 are marked as Private Use; all other values use
the registration policy Expert Review <xref target="RFC8126" format="defau
lt"/>.</dd>
<dt>Value Type:</dt>
<dd>The allowable CBOR data types for values
of this parameter.</dd>
<dt>Reference:</dt>
<dd>This contains a pointer to the public
specification of the OAuth parameter abbreviation, if one exists.</dd>
<dt>Original Specification</dt>
<dd>This contains a pointer to the public
specification of the OAuth parameter, if one exists.</dd>
</dl>
<t>This registry will be initially populated by the values in <t>This registry has been initially populated by the values in <xref targ
<xref target="fig:cborTokenParameters"/>. The Reference column for all of et="table_cborTokenParameters"/>. The Reference column for all of these entries
these entries will be this document.</t> is this document.</t>
</section>
<section anchor="IANAOAuthIntrospectionResponseParameterRegistration" </section>
title="OAuth Introspection Response Parameter Registration"> <section anchor="IANAOAuthIntrospectionResponseParameterRegistration" numb
<t>This specification registers the following parameters in the OAuth ered="true" toc="default">
Token Introspection Response registry <xref <name>OAuth Introspection Response Parameter Registration</name>
target="IANA.TokenIntrospectionResponse"/>.</t> <t>This specification registers the following parameters in the OAuth
<t> Token Introspection Response registry <xref target="IANA.TokenIntrospectionR
<?rfc subcompact="yes"?> esponse" format="default"/>.</t>
<list style='symbols'> <dl newline="false" spacing="compact">
<t>Name: <spanx style="verb">ace_profile</spanx></t> <dt>Name:</dt>
<t>Description: The ACE profile used between client and RS.</t> <dd><tt>ace_profile</tt></dd>
<t>Change Controller: IESG</t> <dt>Description:</dt>
<t>Reference: <xref target="introRes"/> of [this document]</t> <dd>The ACE profile used between the client and RS.</dd>
</list> <dt>Change Controller:</dt>
</t> <dd>IETF</dd>
<t> <dt>Reference:</dt>
<?rfc subcompact="yes"?> <dd><xref target="introRes" format="default"/> of RFC 9200</dd>
<list style='symbols'> </dl>
<t>Name: <spanx style="verb">cnonce</spanx></t> <dl newline="false">
<t>Description: "client-nonce". A nonce previously provided <dt>Name:</dt>
<dd><tt>cnonce</tt></dd>
<dt>Description:</dt>
<dd>"client-nonce". A nonce previously provided
to the AS by the RS via the client. Used to verify token freshness to the AS by the RS via the client. Used to verify token freshness
when the RS cannot synchronize its clock with the AS.</t> when the RS cannot synchronize its clock with the AS.</dd>
<t>Change Controller: IESG</t> <dt>Change Controller:</dt>
<t>Reference: <xref target="introRes"/> of [this document]</t> <dd>IETF</dd>
</list> <dt>Reference:</dt>
</t> <dd><xref target="introRes" format="default"/> of RFC 9200</dd>
<t> </dl>
<?rfc subcompact="yes"?> <dl newline="false" spacing="compact">
<list style='symbols'> <dt>Name</dt>
<t>Name: <spanx style="verb">exi</spanx></t> <dd><tt>cti</tt></dd>
<t>Description: "Expires in". Lifetime of the token in seconds <dt>Description</dt>
from the time the RS first sees it. Used to implement a weaker from of <dd>"CWT ID". The identifier of a CWT as defined in
<xref target="RFC8392" format="default"/>.</dd>
<dt>Change Controller</dt>
<dd>IETF</dd>
<dt>Reference</dt>
<dd><xref target="introRes" format="default"/> of RFC 9200</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Name:</dt>
<dd><tt>exi</tt></dd>
<dt>Description:</dt>
<dd>"Expires in". Lifetime of the token in seconds
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.</t> clocks.</dd>
<t>Change Controller: IESG</t> <dt>Change Controller:</dt>
<t>Reference: <xref target="introRes"/> of [this document]</t> <dd>IETF</dd>
</list> <dt>Reference:</dt>
</t> <dd><xref target="introRes" format="default"/> of RFC 9200</dd>
</section> </dl>
</section>
<section anchor="IANAIntrospectionEndpointCBORMappingsRegistry" <section anchor="IANAIntrospectionEndpointCBORMappingsRegistry" numbered="
title="OAuth Token Introspection Response CBOR Mappings Registry"> true" toc="default">
<t>This specification establishes the IANA "OAuth Token Introspection <name>OAuth Token Introspection Response CBOR Mappings Registry</name>
Response CBOR Mappings" registry. The registry has been created to use the <t>This specification establishes the IANA "OAuth Token Introspection
"Expert Review" registration procedure <xref target="RFC8126"/>, except for Response CBOR Mappings" registry.</t>
the value range designated for private use.</t> <t>The columns of this registry are:</t>
<dl newline="false">
<t>The columns of this registry are: <dt>Name:</dt>
<dd>The OAuth Parameter name, refers to the name in
<list style='hanging'> the OAuth parameter registry, e.g., "client_id".</dd>
<t hangText='Name'>The OAuth Parameter name, refers to the name in <dt>CBOR Key:</dt>
the OAuth parameter registry, e.g., "client_id".</t> <dd>CBOR map key for this parameter. Integer
values less than -65536 are marked as Private Use; all other values use
<t hangText='CBOR Key'>CBOR map key for this parameter. Integer the registration policy Expert Review <xref target="RFC8126" format="defau
values less than -65536 are marked as "Private Use", all other values use lt"/>.</dd>
the registration policy "Expert Review" <xref target="RFC8126"/>.</t> <dt>Value Type:</dt>
<dd>The allowable CBOR data types for values
<t hangText='Value Type'>The allowable CBOR data types for values of this parameter.</dd>
of this parameter.</t> <dt>Reference:</dt>
<dd>This contains a pointer to the public
<t hangText='Reference'>This contains a pointer to the public specification of the introspection response parameter abbreviation, if
specification of the introspection response parameter abbreviation, if one exists.</dd>
one exists.</t> <dt>Original Specification</dt>
</list></t> <dd>This contains a pointer to the public
specification of the OAuth Token Introspection parameter, if one
<t>This registry will be initially populated by the values in exists.</dd>
<xref target="fig:cborIntrospectionParameters"/>. The Reference column for </dl>
all of these entries will be this document.</t> <t>
This registry has been initially populated by the values in <xref
<t>Note that the mappings of parameters corresponding to claim names target="table_cborIntrospectionParameters"/>. The Reference column for all of th
intentionally coincide with the CWT claim name mappings from <xref ese entries is this document.</t>
target="RFC8392"/>.</t>
</section>
<section anchor="IANAJWTClaims" title="JSON Web Token Claims">
<t>This specification registers the following new claims in the JSON
Web Token (JWT) registry of JSON Web Token Claims <xref
target="IANA.JsonWebTokenClaims"/>:</t>
<t><?rfc subcompact="yes"?>
<list style='symbols'>
<t>Claim Name: <spanx style="verb">ace_profile</spanx></t>
<t>Claim Description: The ACE profile a token is supposed to be used
with.</t>
<t>Change Controller: IESG</t>
<t>Reference: <xref target="accessToken"/> of [this document]</t>
</list></t>
<t><?rfc subcompact="yes"?> <t>Note that the mappings of parameters corresponding to claim names
<list style='symbols'> intentionally coincide with the CWT claim name mappings from <xref target="R
<t>Claim Name: <spanx style="verb">cnonce</spanx></t> FC8392" format="default"/>.</t>
<t>Claim Description: "client-nonce". A nonce previously provided </section>
<section anchor="IANAJWTClaims" numbered="true" toc="default">
<name>JSON Web Token Claims</name>
<t>This specification registers the following new claims in the JSON
Web Token (JWT) registry of JSON Web Token Claims <xref target="IANA.JsonWebT
okenClaims" format="default"/>:</t>
<dl newline="false" spacing="compact">
<dt>Claim Name:</dt>
<dd><tt>ace_profile</tt></dd>
<dt>Claim Description:</dt>
<dd>The ACE profile a token is supposed to be used with.</dd>
<dt>Change Controller:</dt>
<dd>IETF</dd>
<dt>Reference:</dt>
<dd><xref target="accessToken" format="default"/> of RFC 9200</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Claim Name:</dt>
<dd><tt>cnonce</tt></dd>
<dt>Claim Description:</dt>
<dd>"client-nonce". A nonce previously provided
to the AS by the RS via the client. Used to verify token freshness to the AS by the RS via the client. Used to verify token freshness
when the RS cannot synchronize its clock with the AS.</t> when the RS cannot synchronize its clock with the AS.</dd>
<t>Change Controller: IESG</t> <dt>Change Controller:</dt>
<t>Reference: <xref target="accessToken"/> of [this document]</t> <dd>IETF</dd>
</list></t> <dt>Reference:</dt>
<dd><xref target="accessToken" format="default"/> of RFC 9200</dd>
<t><?rfc subcompact="yes"?> </dl>
<list style='symbols'> <dl newline="false" spacing="compact">
<t>Claim Name: <spanx style="verb">exi</spanx></t> <dt>Claim Name:</dt>
<t>Claim Description: "Expires in". Lifetime of the token in seconds <dd><tt>exi</tt></dd>
from the time the RS first sees it. Used to implement a weaker from of <dt>Claim Description:</dt>
<dd>"Expires in". Lifetime of the token in seconds
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.</t> clocks.</dd>
<t>Change Controller: IESG</t> <dt>Change Controller:</dt>
<t>Reference: <xref target="tokenExpiration"/> of [this document]</t> <dd>IETF</dd>
</list></t> <dt>Reference:</dt>
<dd><xref target="tokenExpiration" format="default"/> of RFC 9200</dd>
</section> </dl>
</section>
<section anchor="IANACWTClaims" title="CBOR Web Token Claims"> <section anchor="IANACWTClaims" numbered="true" toc="default">
<t>This specification registers the following new claims in the "CBOR <name>CBOR Web Token Claims</name>
Web Token (CWT) Claims" registry <xref <t>This specification registers the following new claims in the "CBOR
target="IANA.CborWebTokenClaims"/>.</t> Web Token (CWT) Claims" registry <xref target="IANA.CborWebTokenClaims" form
at="default"/>.</t>
<t><?rfc subcompact="yes"?> <dl newline="false" spacing="compact">
<list style='symbols'> <dt>Claim Name:</dt>
<t>Claim Name: <spanx style="verb">ace_profile</spanx></t> <dd><tt>ace_profile</tt></dd>
<t>Claim Description: The ACE profile a token is supposed to be used <dt>Claim Description:</dt>
with.</t> <dd>The ACE profile a token is supposed to be used with.</dd>
<t>JWT Claim Name: ace_profile</t> <dt>JWT Claim Name:</dt>
<t>Claim Key: TBD (suggested: 38)</t> <dd>ace_profile</dd>
<t>Claim Value Type(s): integer</t> <dt>Claim Key:</dt>
<t>Change Controller: IESG</t> <dd>38</dd>
<t>Specification Document(s): <xref target="accessToken"/> of [this <dt>Claim Value Type(s):</d