draft-ietf-ace-oauth-authz.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-ace-oauth-authz-45" number="9200" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<!--[rfced] *AD, as several new versions of the I-D were submitted after approval,
please review and let us know if you approve these changes:
      
a) the addition of the definition of "cti" in Section 5.9.2.
b) updated text in Section 5.8.4.4
c) RFC 4648 added as a normative reference

For all changes, please see this diff file:
https://www.ietf.org/rfcdiff?url1=draft-ietf-ace-oauth-authz-43&url2=draft-ietf-ace-oauth-authz-46
(Note: This includes noise such as changes to the characters in bulleted lists.)
-->

  <!-- xml2rfc v2v3 conversion 3.9.1 -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
<title abbrev="ACE-OAuth">Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)</title>

<!--[rfced] Regarding the title, is "(ACE)" necessary?  It seems redundant with
"(ACE-OAuth)" later.

Current:
  Authentication and Authorization for Constrained Environments (ACE)
               Using the OAuth 2.0 Framework (ACE-OAuth)

Perhaps:
    Authentication and Authorization for Constrained Environments 
               Using the OAuth 2.0 Framework (ACE-OAuth)
			   

Ludwig: Agreed fixed
-->

    <seriesInfo name="RFC" value="9200"/>

    <author fullname="Ludwig Seitz" initials="L." surname="Seitz">
      <organization>Combitech</organization>
      <address>
        <postal>
          <street>Djäknegatan 31</street>
          <code>211 35</code>
          <city>Malmö</city>
          <country>Sweden</country>
        </postal>
        <email>ludwig.seitz@combitech.com</email>
      </address>
    </author>
    <author fullname="Göran Selander" initials="G." surname="Selander">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Faroegatan 6</street>
          <code>164 80</code>
          <city>Kista</city>
          <country>Sweden</country>
        </postal>
        <email>goran.selander@ericsson.com</email>
      </address>
    </author>
    <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?

Ludwig: Erik preferes "oe" for consistency with previously published RFCs
-->
      <organization/>
      <address>
        <postal>
          <street/>
          <code/>
          <city/>
          <country>Sweden</country>
        </postal>
        <email>erik@wahlstromstekniska.se</email>
      </address>
    </author>
    <author fullname="Samuel Erdtman" initials="S." surname="Erdtman">
      <organization>Spotify AB</organization>
      <address>
        <postal>
          <street>Birger Jarlsgatan 61, 4tr</street>
          <code>113 56</code>
          <city>Stockholm</city>
          <country>Sweden</country>
        </postal>
        <email>erdtman@spotify.com</email>
      </address>
    </author>
    <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
      <organization>Arm Ltd.</organization>
      <address>
        <postal>
          <street/>
          <code>6067</code>
          <city>Absam</city>
          <country>Austria</country>
        </postal>
        <email>Hannes.Tschofenig@arm.com</email>
      </address>
    </author>
    <date year="2022" month="March" />

    <area>Security</area>
    <workgroup>ACE</workgroup>

    <keyword>CoAP</keyword>
    <keyword>OAuth 2.0</keyword>
    <keyword>Access Control</keyword>
    <keyword>Authorization</keyword>
    <keyword>Internet of Things</keyword>
    <abstract>
      <t>This specification defines a framework for authentication and
      authorization in Internet of Things (IoT) environments called ACE&nbhy;OAuth.
      The framework is based on a set of building blocks including OAuth 2.0
      and the Constrained Application Protocol (CoAP), thus transforming a
      well-known and widely used authorization solution into a form suitable
      for IoT devices.  Existing specifications are used where possible, but
      extensions are added and profiles are defined to better serve the IoT use
      cases.
      </t>
    </abstract>
  </front>
  <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 authorization
   task itself can best be described as granting access to a requesting client for
   a resource hosted on a device, i.e., the resource server (RS).  This exchange is
   mediated by one or multiple authorization servers (ASes). Managing
   authorization for a large number of devices and users can be a complex task.
      </t>
      <t>While prior work on authorization solutions for the Web and for the mobile
   environment also applies to the Internet of Things (IoT) environment, many
   IoT devices are constrained, for example, in terms of processing
   capabilities, available memory, etc. For such devices, the Constrained
   Application Protocol (CoAP) <xref target="RFC7252" format="default"/> can alleviate some
   resource concerns when used instead of HTTP to implement the communication
   flows of this specification.</t>
      <t><xref target="constraints" format="default"/> gives an overview of the constraints
   considered in this design, and a more detailed treatment of constraints can
   be found in <xref target="RFC7228" format="default"/>.  This design aims to accommodate
   different IoT deployments as well as a continuous range of device and network
   capabilities.  Taking energy consumption as an example, at one end, there are
   energy-harvesting or  battery-powered devices that have a tight power
   budget; on the other end, there are mains-powered devices; and all levels exist in
   between.</t>
      <t>Hence, IoT devices may be very different in terms of available processing
   and message exchange capabilities, and there is a need to support many
     different authorization use cases <xref target="RFC7744" format="default"/>.</t>
      <t>This specification describes a framework for Authentication and Authorization
   for Constrained Environments (ACE) built on reuse of OAuth 2.0
   <xref target="RFC6749" format="default"/>, thereby extending authorization to Internet of Things
   devices.  This specification contains the necessary building blocks
   for adjusting OAuth 2.0 to IoT environments.</t>
      <t>Profiles of this framework are available in separate specifications, such as
   <xref target="RFC9202" format="default"/> or <xref target="RFC9203" format="default"/>. 
	   Such profiles may specify the use of the framework for a specific security protocol 
	   and the underlying transports for use in a specific deployment environment to improve interoperability.
   Implementations may claim conformance with a specific profile, whereby
   implementations utilizing the same profile interoperate, while
   implementations of different profiles are not expected to be interoperable.
   More powerful devices, such as mobile phones and tablets, may implement multiple
   profiles and will therefore be able to interact with a wider range of constrained devices. 
	   Requirements on profiles are described at contextually
   appropriate places throughout this specification and also summarized in
   <xref target="app_profileRequirements" format="default"/>.
      </t>
    </section>
    <!-- ***************************************************** -->

<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>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.</t>
      <t>Certain security-related terms, such as "authentication",
"authorization", "confidentiality", "(data) integrity", "message
authentication code", and "verify", are taken from <xref target="RFC4949" format="default"/>.
      </t>
<!--[rfced] FYI, we have added this sentence to explain "RESTful".
(Similar text appears in RFC 8613 and others.)

Original: 
   Since exchanges in this specification are described as RESTful
   protocol interactions, HTTP [RFC7231] offers useful terminology.

Current:
   Since exchanges in this specification are described as RESTful
   protocol interactions, HTTP [RFC7231] offers useful terminology.
   (Note that "RESTful" refers to the Representational State Transfer
   (REST) architecture.)
   
   
Ludwig: Good catch! Agreed.
-->
      <t>Since exchanges in this specification are described as RESTful protocol
    interactions, HTTP <xref target="RFC7231" format="default"/> offers useful terminology.
    (Note that "RESTful" refers to the Representational State Transfer (REST) architecture.)
      </t>
      <t>Terminology for entities in the architecture is defined in OAuth
  2.0 <xref target="RFC6749" format="default"/>, such as client (C), resource server (RS),
  and authorization server (AS).</t>
      <t>Note that the term "endpoint" is used here following its OAuth
definition, which is to denote resources, such as token and
introspection at the AS and authz-info at the RS (see <xref target="tokenAuthInfoEndpoint" format="default"/> for a definition of the authz-info endpoint).
The CoAP definition, which is "[a]n entity
participating in the CoAP protocol" <xref target="RFC7252" format="default"/>, is not used in this specification.</t>
      <t>The specification in this document is called the "framework" or "ACE framework".
When referring to "profiles of this framework", it refers to additional specifications that
define the use of this specification with concrete transport and communication
security protocols (e.g., CoAP over DTLS).
</t>
      <t>The term "Access Information" is used for parameters, other than the access token, provided to the client by the AS to enable it to access the RS
(e.g., public key of the RS or profile supported by RS).</t>
      <t>The term "authorization information" is used to denote all information,
including the claims of relevant access tokens, that an RS uses to determine whether an access request should be granted.</t>
      <t>Throughout this document, examples for CBOR data items are expressed in
         CBOR extended diagnostic notation as defined in
         <xref section="8" sectionFormat="of" target="RFC8949"/> and
         <xref section="G" sectionFormat="of" target="RFC8610"/>
         ("diagnostic notation"), unless noted otherwise.
         We often use diagnostic notation comments to provide
         a textual representation of the numeric parameter names and values.</t>
    </section>
    <!-- ***************************************************** -->

<section anchor="overview" numbered="true" toc="default">
      <name>Overview</name>
      <t>This specification defines the ACE framework for authorization in the Internet
      of Things environment. It consists of a set of building blocks.</t>
      <t>
  The basic block is the OAuth 2.0 <xref target="RFC6749" format="default"/>
  framework, which enjoys widespread deployment.  Many IoT devices can support
  OAuth 2.0 without any additional extensions, but for certain constrained
  settings, additional profiling is needed.
      </t>
      <t>Another building block is the lightweight web transfer protocol CoAP
  <xref target="RFC7252" format="default"/>, for those communication environments where HTTP is
  not appropriate.  CoAP typically runs on top of UDP, which further reduces
  overhead and message exchanges. While this specification defines extensions
  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" format="default"/>,
  Message Queuing Telemetry Transport (MQTT) <xref target="MQTT5.0" format="default"/>,
  Bluetooth Low Energy (BLE) <xref target="BLE" format="default"/>, and QUIC <xref 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</bcp14>
  specify how the corresponding protocol messages are transmitted instead.</t>
      <t>A third building block is the Concise Binary Object Representation
  (CBOR) <xref target="RFC8949" format="default"/>, for encodings where JSON
  <xref target="RFC8259" format="default"/> is not sufficiently compact.  CBOR is a binary
  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
  is not used, the use of CBOR remains <bcp14>RECOMMENDED</bcp14>.
      </t>
      <t>A fourth building block is CBOR Object Signing and Encryption (COSE)
  <xref target="RFC8152" format="default"/>, which enables object-level layer security as an
  alternative or complement to transport layer security (DTLS
    <xref target="RFC6347" format="default"/> or TLS <xref target="RFC8446" format="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
    is defined in CBOR Web Token (CWT) <xref target="RFC8392" format="default"/>.
    Application-layer security for CoAP using COSE can be provided with Object Security for
    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
  described in detail in <xref target="RFC7228" format="default"/>, and a description
  of how the building blocks mentioned above relate to the various constraints
  can be found in <xref target="constraints" format="default"/>.</t>
      <t>Luckily, not every IoT device suffers from all constraints.  Nevertheless, the ACE
  framework takes all these aspects into account and allows
  several different deployment variants to coexist, rather than mandating a
  one-size-fits-all solution.  It is important to cover the wide
  range of possible interworking use cases and the different requirements from
  a security point of view.  Once IoT deployments mature, popular deployment
  variants will be documented in the form of ACE profiles.</t>
      <section anchor="oauth2Overview" numbered="true" toc="default">
        <name>OAuth 2.0</name>
        <t>The OAuth 2.0 authorization framework enables a client to obtain
    scoped access to a resource with the permission of a resource
    owner.  Authorization information, or references to it, is passed between the nodes
    using access tokens.  These access tokens are issued to clients by an
    authorization server with the approval of the resource owner.  The client
    uses the access token to access the protected resources hosted by the
    resource server.</t>
        <t>A number of OAuth 2.0 terms are used within this specification:

        </t>
        <dl newline="true" spacing="normal">
          <dt>Access Tokens:</dt>
          <dd>
            <t>
        Access tokens are credentials needed to access protected resources.  An
        access token is a data structure representing authorization permissions
        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
        to the client.
            </t>
            <t>
        Access tokens can have different formats and various methods
        of utilization (e.g., cryptographic properties) based on the security
        requirements of the given deployment.
            </t>
          </dd>
          <dt>Introspection:</dt>
          <dd>
	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
	received access token.  This is particularly useful in those cases where
	the authorization decisions are very dynamic and/or where the received
	access token itself is an opaque reference, rather than a self-contained
	token.  More information about introspection in OAuth 2.0 can be
	found in <xref target="RFC7662" format="default"/>.
	</dd>
          <dt>Refresh Tokens:</dt>
          <dd>
            <t>
	Refresh tokens are credentials used to obtain access tokens.
	Refresh tokens are issued to the client by the authorization
	server and are used to obtain a new access token when the current
	access token expires or to obtain additional access tokens with
	identical or narrower scope (such access tokens may have a shorter
	lifetime and fewer permissions than authorized by the resource owner).
	Issuing a refresh token is optional at the discretion of the
	authorization server.  If the authorization server issues a refresh
	token, it is included when issuing an access token (i.e., step (B) in
	<xref target="fig_protocolFlow" format="default"/>).
            </t>
            <t>
	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
	opaque to the client.  The token denotes an identifier used to retrieve
	the authorization information.  Unlike access tokens, refresh
	tokens are intended for use only with authorization servers and
	are never sent to resource servers.  In this framework, refresh
	tokens are encoded in binary instead of strings, if used.
            </t>
          </dd>
          <dt>Proof-of-Possession Tokens:</dt>
          <dd>
            <t>
        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
	are called proof-of-possession tokens (or PoP tokens).
            </t>
            <t>
        The proof-of-possession security concept used here assumes that
	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
	the client to demonstrate the possession of the secret to the RS when
	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
	access token.  When this specification uses the term "access token", it
	is assumed to be a PoP access token unless specifically stated
	otherwise.

            </t>
            <t>
        The key bound to the token (the PoP key) may use either symmetric or
	asymmetric cryptography.  The appropriate choice of the kind of
	cryptography depends on the constraints of the IoT devices as well as
	on the security requirements of the use case.
            </t>
            <dl newline="true" spacing="normal">
              <dt>Symmetric PoP key:</dt>
              <dd>
                <t>
              The AS generates a random, symmetric PoP key.  The key is either
              stored to be returned on introspection calls or included in the
	      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
	      client together with the token, protected by the secure channel.</t>
              </dd>
              <dt>Asymmetric PoP key:</dt>
              <dd>
          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
	  client's public key).  Information about the public key, which is the
	  PoP key in this case, is either stored to be returned on 
	  introspection calls or included inside the token and sent
	  back to the client.  The resource server consuming the token can
	  identify the public key from the information in the token, which
	  allows the client to use the corresponding private key for the
	  proof of possession.
          </dd>
            </dl>
            <t> The token is either a simple reference
	or a structured information object (e.g., CWT <xref target="RFC8392" format="default"/>)
	protected by a cryptographic wrapper (e.g., COSE <xref target="RFC8152" format="default"/>).  The choice of PoP key does not necessarily imply
	a specific credential type for the integrity protection of the
	token.</t>
          </dd>
          <dt>Scopes and Permissions:</dt>
          <dd>
            <t>
         In OAuth 2.0, the client specifies the type of permissions it is
         seeking to obtain (via the <tt>scope</tt> parameter) in the access token
	 request.  In turn, the AS may use the <tt>scope</tt> response parameter to
	 inform the client of the scope of the access token issued.  As the
	 client could be a constrained device as well, this specification
	 defines the use of CBOR encoding (see <xref target="oauthProfile" format="default"/>) for such requests and responses.
            </t>
            <t>
         The values of the <tt>scope</tt> parameter in OAuth 2.0 are expressed as a list
	 of space-delimited, case-sensitive strings with a semantic that is
	 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.

Ludwig: This comment contains text that we removed by didn't want to delete yet.
The other comments were added to help the authors navigate the document while editing
and can also be deleted
-->
         More details about the concept of scopes are found under
         <xref target="RFC6749" sectionFormat="of" section="3.3"/>.</t>
          </dd>
          <dt>Claims:</dt>
          <dd>
            <t>
      Information carried in the access token or returned from introspection, called claims, is in the form of
      name-value pairs.  An access token may, for example, include a claim
      identifying the AS that issued the token (via the <tt>iss</tt> claim) and
      what audience the access token is intended for (via the <tt>aud</tt> claim).
	The audience of an access token can be a specific resource, one resource, or
	many resource servers.  The resource owner policies influence what
	claims are put into the access token by the authorization server.
            </t>
            <t>
        While the structure and encoding of the access token varies throughout
        deployments, a standardized format has been defined with the JSON Web
        Token (JWT) <xref target="RFC7519" format="default"/>, where claims are encoded as a
	JSON object.  In <xref target="RFC8392" format="default"/>, the CBOR Web Token (CWT)
	has been defined as an equivalent format using CBOR encoding.
            </t>
          </dd>
          <dt>Token and Introspection Endpoints:</dt>
          <dd>
            <t>
      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
      and receives the access token in the response (if the request was
      successful).
            </t>
            <t>
      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
      need to request additional information regarding a received access
      token.  The requesting entity makes a POST request to the introspection
      endpoint on the AS and receives information about the access token in
      the response. (See "Introspection" above.)
            </t>
          </dd>
        </dl>
      </section>
      <section anchor="coap" numbered="true" toc="default">
        <name>CoAP</name>
        <t>
    CoAP is an application-layer protocol similar to HTTP but specifically
    designed for constrained environments.  CoAP typically uses
    datagram-oriented transport, such as UDP, where reordering and loss
    of packets can occur.  A security solution needs to take the latter aspects
    into account.</t>
        <t>While HTTP uses headers and query strings to convey additional
    information about a request, CoAP encodes such information into header
    parameters called 'options'.</t>
        <t>CoAP supports application-layer fragmentation of the CoAP payloads
    through block-wise transfers <xref target="RFC7959" format="default"/>.  However,
    block-wise transfer does not increase the size limits of CoAP options;
    therefore, data encoded in options has to be kept small.
        </t>
        <t>Transport layer security for CoAP can be provided by DTLS or TLS
  <xref target="RFC6347" format="default"/> <xref target="RFC8446" format="default"/>
          <xref target="RFC9147" format="default"/>.
    CoAP defines a number of proxy operations that require transport layer
    security to be terminated at the proxy. One approach for protecting CoAP communication
    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 application
    layer using an object-based security mechanism, such as COSE <xref target="RFC8152" format="default"/>.
        </t>
        <t>
    One application of COSE is OSCORE
    <xref target="RFC8613" format="default"/>, which provides end-to-end confidentiality,
    integrity and replay protection, and a secure binding between CoAP request
    and response messages. In OSCORE, the CoAP messages are wrapped in COSE
    objects and sent using CoAP.
        </t>
        <t>In this framework, the use of CoAP as replacement for HTTP is <bcp14>RECOMMENDED</bcp14>
  for use in constrained environments.  For communication security, this
  framework does not make an explicit protocol recommendation, since the choice
  depends on the requirements of the specific application.  DTLS
  <xref target="RFC6347" format="default"/> <xref target="RFC9147" format="default"/> and OSCORE
  <xref target="RFC8613" format="default"/> are mentioned as examples; other protocols fulfilling
  the requirements from <xref target="minimalCommSecReq" format="default"/> are also
  applicable.</t>
      </section>
    </section>
    <!-- ***************************************************** -->
<section anchor="specs" numbered="true" toc="default">
      <name>Protocol Interactions</name>
      <t>
    The ACE framework is based on the OAuth 2.0 protocol interactions using
    the token endpoint and optionally the introspection endpoint.
    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
    an RS to gain access to a protected resource. In most deployments, the RS can
    process the access token locally; however, in some cases, the RS may present
    it to the AS via the introspection endpoint to get fresh information.
    These interactions are shown in <xref target="fig_protocolFlow" format="default"/>.  An
    overview of various OAuth concepts is provided in <xref target="oauth2Overview" format="default"/>.
</t>
      <figure anchor="fig_protocolFlow">
        <name>Basic Protocol Flow</name>
        <artwork align="left" name="" type="" alt=""><![CDATA[
+--------+                               +---------------+
|        |---(A)-- Token Request ------->|               |
|        |                               | Authorization |
|        |<--(B)-- Access Token ---------|    Server     |
|        |    + Access Information       |               |
|        |    + Refresh Token (optional) +---------------+
|        |                                      ^ |
|        |            Introspection Request  (D)| |
| Client |                         Response     | |(E)
|        |            (optional exchange)       | |
|        |                                      | v
|        |                               +--------------+
|        |---(C)-- Token + Request ----->|              |
|        |                               |   Resource   |
|        |<--(F)-- Protected Resource ---|    Server    |
|        |                               |              |
+--------+                               +--------------+
  ]]></artwork>
      </figure>
      <dl newline="true" spacing="normal">
        <dt>Requesting an Access Token (A):</dt>
        <dd>
          <t>
      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 target="oauth2Overview" format="default"/> for a short description) wherein the AS binds a
      key to an access token.  The client may include permissions it seeks to
      obtain and information about the credentials it wants to use for
      proof of possession (e.g., symmetric/asymmetric cryptography or a
      reference to a specific key) of the access token.</t>
        </dd>
        <dt>Access Token Response (B):</dt>
        <dd>
          <t>
      If the request from the client has been successfully verified, 
      authenticated, and authorized, the AS returns an access token and optionally a refresh
      token. Note that only certain grant types support refresh tokens.  The AS
      can also return additional parameters, referred to as "Access
      Information".  In addition to the response parameters defined by OAuth
      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.,
      the profile the RS supports.  More information about these parameters
      can be found in <xref target="tokenParams" format="default"/>.
          </t>
        </dd>
        <dt>Resource Request (C):</dt>
        <dd>
          <t>
      The client interacts with the RS to request access to the protected
      resource and provides the access token.  The protocol to use
      between the client and the RS is not restricted to CoAP. HTTP, HTTP/2
      <xref target="RFC7540" format="default"/>, QUIC <xref target="RFC9000" format="default"/>,
      MQTT <xref target="MQTT5.0" format="default"/>, Bluetooth Low Energy <xref target="BLE" format="default"/>,
      etc., are also viable candidates.
          </t>
          <t>
      Depending on the device limitations and the selected protocol, this
      exchange may be split up into two parts:</t>
          <ol type="(%d)" spacing="normal">
            <li>the client sends the access token containing, or referencing, the
  authorization information to the RS that will be used for subsequent
  resource requests by the client, and </li>
            <li>the client makes the resource access request using the communication
  security protocol and other Access Information obtained from the AS.</li>
          </ol>
          <t>
      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
      token or the Access Information.  The RS verifies that the token is
      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
      online, validation can be handed over to the AS using token introspection
      (see messages (D) and (E)) over HTTP or CoAP.</t>
        </dd>
        <dt>Token Introspection Request (D):</dt>
        <dd>
          <t>
      A resource server may be configured to introspect the access token by
      including it in a request to the introspection endpoint at that AS.
      Token introspection over
      CoAP is defined in <xref target="introspectionEndpoint" format="default"/> and for HTTP in
      <xref target="RFC7662" format="default"/>.
          </t>
          <t>
      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
      perform the token validation on its own.</t>
        </dd>
        <dt>Token Introspection Response (E):</dt>
        <dd>
          <t>
      The AS validates the token and returns the most recent parameters, such
      as <tt>scope</tt>, <tt>audience</tt>, validity, etc., associated with it back to the RS.  The
      RS then uses the received parameters to process the request to either
      accept or to deny it.</t>
        </dd>
        <dt>Protected Resource (F):</dt>
        <dd>
      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
      the dynamically established keys to protect the response according to
      the communication security protocol used.
    </dd>
      </dl>
      <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="RFC6749" format="default"
      sectionFormat="of" section="4.1"/>) and 

<!--[rfced] Citations

a) Note that as RFC 7521 does not have a Section 4.4, we
have updated this citation to be Section 4.4 of RFC 6749. Please 
let us know if this is not correct.

Original:
   and the Client Credentials
   Grant (described in Section 4.4 of [RFC7521]). 

Current:
   and the client credentials
   grant (described in Section 4.4 of [RFC6749]). 
===
Ludwig: Agreed. Note that the previous citation is also wrong and should refer to RFC6749 as well
Original:
   namely the
      authorization code grant (described in <xref target="RFC7521"

Current:
 namely the
      authorization code grant (described in <xref target="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].
===  
Ludwig: Probably a reference to a draft version of the RFC. 

Current:
   Additional protection for the access token can be applied by
   encrypting it, for example encryption of CWTs is specified in
   Section 7.1 of [RFC8392].
===
-->

      the client credentials grant (described
      in <xref target="RFC6749" sectionFormat="of" section="4.4"/>). The authorization
      code grant is a good fit for use with apps running on smartphones and tablets that request access to IoT devices, a common scenario in the smart home environment, where users need to go through an authentication and authorization phase (at least during the initial setup phase). The native apps guidelines described in <xref target="RFC8252" format="default"/> are applicable to this use case. The client credentials grant is a good fit for use with IoT devices where the OAuth client itself is constrained. In such a case, the resource owner has prearranged access rights for the client with the authorization server, which is often accomplished using a commissioning tool.</t>
      <t>
    The consent of the resource owner, for giving a client access to a protected
    resource, can be provided dynamically as in the classical OAuth flows, or it
    could be preconfigured by the resource owner as authorization policies at
    the AS, which the AS evaluates when a token request arrives.  The resource
    owner and the requesting party (i.e., client owner) are not shown in <xref target="fig_protocolFlow" format="default"/>.
</t>
      <t>
	This framework supports a wide variety of communication security mechanisms
	between the ACE entities, such as the client,
	AS, and RS. It is assumed that the client has been
	registered (also called enrolled or onboarded) to an AS using a mechanism defined
	outside the scope of this document.
	In practice, various techniques for onboarding have been used, such as
	factory-based provisioning or the use of
	commissioning tools. Regardless of the onboarding technique, this provisioning
	procedure implies that the client and the AS exchange credentials and
	configuration parameters.  These credentials are used to mutually authenticate each
        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, potentially 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
 cryptographic protection to the access token to ensure that its content cannot
 be modified and, if needed, that the content is confidentiality protected. Confidentiality protection of the access token content would be provided on top of 
 confidentiality protection via a communication security protocol. </t>
      <t>The keying material necessary for establishing communication security
  between the C and RS is dynamically established as part of the protocol described
  in this document.
</t>
      <t>
    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.
    In this step, the client might also determine what permissions are needed to
    access the protected resource.  A generic procedure is described in <xref target="asDiscovery" format="default"/>; profiles <bcp14>MAY</bcp14> define other procedures for
    discovery.</t>
      <t>In Bluetooth Low Energy, for example, advertisements are broadcast by
    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
    obtain information about available resources, which are returned in a
    standardized format, as described in <xref target="RFC6690" format="default"/>.
</t>
    </section>
    <!-- ***************************************************** -->

<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.
      </t>
      <dl newline="true" spacing="normal">
        <dt>Credential Provisioning</dt>
        <dd>
          <t>
        In constrained environments, it cannot be assumed that the client and the RS
        are part of a common key infrastructure. Therefore, the AS provisions
	credentials and associated information to allow mutual authentication
	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
	access tokens the client uses.
          </t>
        </dd>
        <dt>Proof of Possession</dt>
        <dd>
          <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
	the key bound to the token.  The binding is provided by the <tt>cnf</tt> (confirmation)
	claim
	<xref target="RFC8747" format="default"/>, indicating what key is used for
	proof of possession. If a client needs to submit a new access token,
	e.g., to obtain additional access rights, they can request
	that the AS binds this token to the same key as the previous one.
          </t>
        </dd>
        <dt>ACE Profiles</dt>
        <dd>
        The client or RS may be limited in the encodings or protocols it
        supports.  To support a variety of different deployment settings,
        specific interactions between the client and RS are defined in an ACE
        profile.  In the ACE framework, the AS is expected to manage the matching
	of compatible profile choices between a client and an RS.  The AS
	informs the client of the selected profile using the <tt>ace_profile</tt>
	parameter in the token response.
      </dd>
      </dl>
      <t>OAuth 2.0 requires the use of TLS to protect the communication 
  between the AS and client when requesting an access token between the client and RS
  when accessing a resource and between the AS and RS if introspection is used.
  In constrained settings, TLS is not always feasible or desirable.
  Nevertheless, it is <bcp14>REQUIRED</bcp14> that the communications named above are
  encrypted, integrity protected, and protected against message replay.  It is
  also <bcp14>REQUIRED</bcp14> that the communicating endpoints perform mutual authentication.
  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
  actually belongs to a certain request.  Note that setting up such a secure
  communication may require some unprotected messages to be exchanged first
  (e.g., sending the token from the client to the RS).</t>
      <t>Profiles <bcp14>MUST</bcp14> specify a communication security protocol between the
      client and RS that provides the features required above.  Profiles
      <bcp14>MUST</bcp14> specify a
      communication security protocol <bcp14>RECOMMENDED</bcp14> to be used between the
      client and AS that provides the features required above.  Profiles <bcp14>MUST</bcp14>
      specify, for  introspection, a communication security protocol
      <bcp14>RECOMMENDED</bcp14> to be used 
      between the RS and AS that provides the features required above.  These 
      recommendations enable interoperability between different implementations
      without the need to define a new profile if the communication between the C and
      AS, or between the RS and AS, is protected with a different security protocol
      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
  parameters.  When profiles of this framework use CoAP instead, it is 
  <bcp14>REQUIRED</bcp14> to use of the following alternative instead of Uri-query
  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.
  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
  <bcp14>MUST</bcp14> specify their CBOR encoding.</t>
      <t>Profiles that use CBOR encoding of protocol message parameters at the
  outermost encoding layer <bcp14>MUST</bcp14> use the Content-Format "application/ace+cbor".
  If CoAP is used for communication, the Content-Format <bcp14>MUST</bcp14> be abbreviated
  with the ID: 19 (see <xref target="IANAcoapContentFormat" format="default"/>).</t>
      <t>The OAuth 2.0 AS uses a JSON structure in the payload of its responses
  both to the client and RS.  If CoAP is used, it is <bcp14>REQUIRED</bcp14> to use
  CBOR <xref target="RFC8949" format="default"/> instead of JSON.  Depending on the profile,
  the CBOR payload <bcp14>MAY</bcp14> be enclosed in a non-CBOR cryptographic wrapper.</t>
      <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.

Ludwig: I won't argue grammar with professional document editors ;-). Agreed
-->
        <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 with this
URI is authorized to provide access tokens for this RS.
        </t>
        <t> In order to determine the AS URI, the C <bcp14>MAY</bcp14> send an initial Unauthorized
Resource Request message to the RS.  The RS then denies the request and sends
the address of its AS back to the C (see <xref target="rreq" format="default"/>). How the C validates the
AS authorization is not in scope for this document. The C may, for example, ask
its owner if this AS is authorized for this RS. The C may also use a
mechanism that addresses both problems at once (e.g., by querying a dedicated secure service provided by the client owner) .</t>
      </section>
      <!--AS Discovery -->

  <section anchor="rreq" numbered="true" toc="default">
        <name>Unauthorized Resource Request Message</name>
        <t>An Unauthorized Resource Request message is a request for any
	resource hosted by the RS for which the client does not have authorization granted.
	The RSs <bcp14>MUST</bcp14>
	treat any request for a protected resource as an Unauthorized Resource
	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 autonomously
	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>MUST
	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 server
	<bcp14>SHOULD</bcp14> provide proper
	AS Request Creation Hints to enable the client to request an access token
	from the RS's AS, as described in <xref target="asInfo" format="default"/>.</t>
        <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 -->

  <section anchor="asInfo" numbered="true" toc="default">
        <name>AS Request Creation Hints</name>
        <t>The AS Request Creation Hints are sent by an RS as a response 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 are a CBOR or JSON map,
	with an <bcp14>OPTIONAL</bcp14> element <tt>AS</tt> specifying an absolute URI (see
	<xref target="RFC3986" sectionFormat="of" section="4.3"/>) that identifies 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 <tt>audience</tt> element containing an identifier the client
      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 
      restrict the use of the access token to specific RSs. See 
      <xref target="audience" format="default"/> for a discussion of this parameter.</li>
          <li>A <tt>kid</tt> (key identifier) element contains the key identifier of a key used in
	  an existing security association between the client and the RS.
	  The RS expects the client to request an access token bound to this
	  key in order to avoid having to reestablish the security
	  association.</li>
          <li>A <tt>cnonce</tt> element contains a client-nonce. See <xref target="cnonceParam"
	  format="default"/>.</li>
          <li>A <tt>scope</tt> element contains the suggested scope that the client
	  should request towards the AS.</li>
        </ul>
        <t><xref target="table_asinfo" format="default"/> summarizes the parameters that may
	be part of the AS Request Creation Hints.</t>
        <table anchor="table_asinfo">
          <name>AS Request Creation Hints</name>
	  <thead>
	    <tr>
	      <th>Name</th>
	      <th>CBOR Key</th>
	      <th>Value Type</th>
	    </tr>
	  </thead>
	  <tbody>
	  <tr>
	    <td>AS</td>
            <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
    and the AS. Thus, the example AS value "coap://as.example.com/token"
    might need to be transformed to "coaps://as.example.com/token".
    It is assumed that the client can determine the correct schema part on
    its own depending on the way it communicates with the AS.</t>
        <t><xref target="fig_as-info-payload" format="default"/> shows an example for an AS
    Request Creation Hints payload using diagnostic notation.</t>
<!-- [rfced] Please review the "type" attribute of each sourcecode element 
in the XML file to ensure correctness. If the current list of preferred 
values for "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt)
does not contain an applicable type, then feel free to let us know.

Ludwig: Done. Corrected one from json -> cbor-diag
-->
        <figure anchor="fig_as-info-payload">
          <name>AS Request Creation Hints Payload Example</name>
          <sourcecode type="cbor-diag"><![CDATA[
    4.01 Unauthorized
    Content-Format: application/ace+cbor
    Payload :
    {
     / AS / 1 : "coaps://as.example.com/token",
     / audience / 5 : "coaps://rs.example.com",
     / scope / 9 : "rTempC",
     / cnonce / 39 : h'e0a156bb3f'
    }
]]></sourcecode>
        </figure>
        <t>In the example above, the response parameter <tt>AS</tt> points the receiver of
    this message to the URI "coaps://as.example.com/token" to request access
    tokens.  The RS sending this response uses an internal clock
    that is not synchronized with the clock of the AS.  Therefore, it
    cannot reliably verify the expiration time of access tokens it receives.
    Nevertheless, to ensure a certain level of access token freshness, the RS has
    included a <tt>cnonce</tt> parameter (see <xref target="cnonceParam" format="default"/>) in the response. (The hex sequence of the <tt>cnonce</tt> parameter 
    is encoded in CBOR-based notation in this example.)</t>
        <t><xref target="fig_as-info-cbor" format="default"/> illustrates the mandatory use
	of binary encoding of the message payload shown in
	<xref target="fig_as-info-payload" format="default"/>.</t>
        <figure anchor="fig_as-info-cbor">
          <name>AS Request Creation Hints Example Encoded in CBOR</name>
          <sourcecode name="" type="cbor-pretty"><![CDATA[
a4                                   # map(4)
   01                                # unsigned(1) (=AS)
   78 1c                             # text(28)
      636f6170733a2f2f61732e657861
      6d706c652e636f6d2f746f6b656e   # "coaps://as.example.com/token"
   05                                # unsigned(5) (=audience)
   76                                # text(22)
      636f6170733a2f2f72732e657861
      6d706c652e636f6d               # "coaps://rs.example.com"
   09                                # unsigned(9) (=scope)
   66                                # text(6)
      7254656d7043                   # "rTempC"
   18 27                             # unsigned(39) (=cnonce)
   45                                # bytes(5)
      e0a156bb3f                     # 
      ]]></sourcecode>
        </figure>
        <section anchor="cnonceParam" numbered="true" toc="default">
          <name>The Client-Nonce Parameter</name>
          <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
      in that case, the RS can use the <tt>cnonce</tt> (client-nonce) parameter.
      The processing requirements for this parameter are as follows:
          </t>
          <ul spacing="normal">
            <li>An RS sending a <tt>cnonce</tt> parameter in an AS Request Creation
	    Hints message <bcp14>MUST</bcp14> store information to validate that a given
	    cnonce is fresh.  How this is implemented internally is out of scope
	    for this specification.  Expiration of client-nonces should be based
	    roughly on the time it would take a client to obtain an access token
	    after receiving the AS Request Creation Hints, with some
	    allowance for unexpected delays.</li>
            <li>A client receiving a <tt>cnonce</tt> parameter in an AS Request Creation
	    Hints message <bcp14>MUST</bcp14> include this in the parameters when
	    requesting an access token at the AS, using the <tt>cnonce</tt> parameter from
	    <xref target="cnonceParamToken" format="default"/>.</li>
            <li>If an AS grants an access token request containing a <tt>cnonce</tt>
	    parameter, it <bcp14>MUST</bcp14> include this value in the access token, using
	    the	<tt>cnonce</tt> claim specified in <xref target="accessToken"
	    format="default"/>.</li>
            <li>An RS that is using the client-nonce mechanism and that receives an
	    access token <bcp14>MUST</bcp14> verify that this token contains a <tt>cnonce</tt>
	    claim, with
	    a client-nonce value that is fresh according to the information stored
	    at the first step above.  If the <tt>cnonce</tt> claim is not present or if the
	    <tt>cnonce</tt> claim value is not fresh, the RS <bcp14>MUST</bcp14> discard the access
	    token. If this was an interaction with the authz-info endpoint, the RS
	    <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" numbered="true" toc="default">
        <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
  is expressed in the form of an authorization grant.</t>
        <t>The OAuth framework <xref target="RFC6749" format="default"/> defines four grant types. The grant types can
  be split up into two groups: those granted on behalf of the resource
  owner (password, authorization code, implicit) and those for the client
  (client credentials). Further grant types have been added later, such as an assertion-based authorization grant defined in <xref target="RFC7521" format="default"/>.</t>
        <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
  grant is recommended.  If the client acts on behalf of the resource owner
  but does not have any display or has very limited interaction possibilities, it is
  recommended to use the device code grant defined in
  <xref target="RFC8628" format="default"/>.  In cases where the client
  acts autonomously, the client credentials grant is recommended.</t>
        <t>For details on the different grant types, see <xref target="RFC6749" sectionFormat="of" section="1.3"/>. The OAuth 2.0 framework provides an extension
  mechanism for defining additional grant types, so profiles of this framework
  <bcp14>MAY</bcp14> define additional grant types, if needed.</t>
      </section>
      <!--Grants-->

<section anchor="clientCredentials" numbered="true" toc="default">
        <name>Client Credentials</name>
        <t>Authentication of the client is mandatory independent of the grant type
  when requesting an access token from the token endpoint. In the case of
  the client credentials grant type, the authentication and grant coincide.</t>
        <t>Client registration and provisioning of client credentials to the client
  is out of scope for this specification.</t>
        <t>The OAuth framework defines two client credential types in
  <xref target="RFC6749" sectionFormat="of" section="2.3.1"/>: client id and client secret. <xref target="I-D.erdtman-oauth-rpcc" format="default"/> adds raw public key and pre-shared key to the
  client credentials types.  Profiles of this framework <bcp14>MAY</bcp14> extend with
  an additional client credentials type using client certificates.</t>
      </section>
      <!--Client Credentials-->

<section anchor="ASAuthentication" numbered="true" toc="default">
        <name>AS Authentication</name>
        <t>The client credentials grant does not, by default, authenticate the AS that the client
  connects to. In classic OAuth, the AS is authenticated with a TLS server
  certificate.</t>
        <t>Profiles of this framework <bcp14>MUST</bcp14> specify how clients authenticate the AS
  and how communication security is implemented. By default, server side TLS
  certificates, as defined by OAuth 2.0, are required.</t>
      </section>
      <!--AS Authentication-->

<section anchor="authorizeEndpoint" numbered="true" toc="default">
        <name>The Authorization Endpoint</name>
        <t>The OAuth 2.0 authorization endpoint is used to interact with the resource owner
  and obtain an authorization grant in certain grant flows.  The primary use
  case for the ACE-OAuth framework is for machine-to-machine interactions that do not involve
  the resource owner in the authorization flow; therefore, this endpoint is
  out of scope here.  Future profiles may define constrained adaptation
  mechanisms for this endpoint as well.  Nonconstrained clients interacting
  with constrained resource servers can use the specification in
  <xref target="RFC6749" sectionFormat="of" section="3.1"/> and the attack countermeasures suggested in
  <xref target="RFC6819" sectionFormat="of" section="4.2"/>.</t>
      </section>
      <!--The 'Authorize' Endpoint-->

<section anchor="tokenEndpoint" numbered="true" toc="default">
        <name>The Token Endpoint</name>
        <t>In standard OAuth 2.0, the AS provides the token endpoint for submitting
  access token requests.  This framework extends the functionality of the
  token endpoint, giving the AS the possibility to help the client and RS
  establish shared keys or exchange their public keys.  Furthermore,
  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 the mapping
  between the fields described below and these transports.

<!--[rfced] *AD, please review and let us know if you approve this change.
FYI, this text in Section 5.8 has been updated as follows per mail from 
G. Selander  2022-02-03. (In addition, we have inserted the word "the" 
before "payload format".)

Original:
   If HTTPS is used, the semantics of Sections 4.1.3 and 4.1.4 of the OAuth
   2.0 specification MUST 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.

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 the 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 payload 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
  their own instead.</t>

        <section anchor="tokenRequest" numbered="true" toc="default">
          <name>Client-to-AS Request</name>
          <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
    in the relevant subsection of Section <xref target="RFC6749" section="4" sectionFormat="bare"/> of the OAuth 2.0 specification
    <xref target="RFC6749" format="default"/>, depending on the grant type, with the following
    exceptions and additions:
          </t>
          <ul spacing="normal">
            <li>The parameter <tt>grant_type</tt> is <bcp14>OPTIONAL</bcp14> in the context
	    of this framework (as opposed to <bcp14>REQUIRED</bcp14> in <xref
	    target="RFC6749" format="default"/>).  If that parameter is
	    missing, the default value "client_credentials" is implied.</li>
            <li>The <tt>audience</tt> parameter from <xref target="RFC8693"
	    format="default"/> is <bcp14>OPTIONAL</bcp14> to
	    request an access token bound to a specific audience.</li>
            <li>The <tt>cnonce</tt> parameter defined in <xref target="cnonceParamToken"
	    format="default"/> is
	    <bcp14>REQUIRED</bcp14> if the RS provided a client-nonce in the AS
	    Request Creation Hints message (<xref target="asInfo" format="default"/>).</li>
            <li>The <tt>scope</tt> parameter <bcp14>MAY</bcp14> be encoded as a byte string
	    instead of the string encoding specified in <xref target="RFC6749" sectionFormat="of"
	    section="3.3"/> or
	    in order to allow compact encoding of complex scopes.  The syntax of
	    such a binary encoding is explicitly not specified here and left
	    to profiles or applications. Note specifically that a binary encoded
	    scope does not necessarily use the space character '0x20' to delimit
	    scope-tokens.</li>
            <li>The client can send an empty (null value) <tt>ace_profile</tt> parameter to
	    indicate that it wants the AS to include the <tt>ace_profile</tt> 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 additional
      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
    pair or to reuse a key previously established with the RS, the client is
    supposed to use the <tt>req_cnf</tt> parameter from <xref target="RFC9201" format="default"/>.
          </t>
          <t>If CoAP is used, then these parameters <bcp14>MUST</bcp14> be provided in a CBOR map
    (see <xref target="table_cborTokenParameters" format="default"/>).</t>
          <t>When HTTP is used as a transport, then the client makes a 
    request to the token endpoint; the parameters <bcp14>MUST</bcp14> be encoded as defined 
    in <xref target="RFC6749" sectionFormat="of" section="B"/>.</t>
          <t>The following examples illustrate different types of requests
    for proof-of-possession tokens. </t>
          <t><xref target="fig_symmATreq" format="default"/> shows a request for a token
    with a symmetric proof-of-possession key, using diagnostic notation.
          </t>
          <figure anchor="fig_symmATreq">
            <name>Example Request for an Access Token Bound to a Symmetric Key</name>
            <sourcecode name="" type="cbor-diag"><![CDATA[
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: application/ace+cbor
Payload:
{
  / client_id / 24 : "myclient",
  / audience /  5  : "tempSensor4711"
}
]]></sourcecode>
          </figure>
          <t><xref target="fig_asymmATreq" format="default"/> shows a request for a token
	  with an
	  asymmetric proof-of-possession key.  Note that, in this example, OSCORE
	  <xref target="RFC8613" format="default"/> is used
	  to provide object-security; therefore, the Content-Format is
	  "application/oscore" wrapping the "application/ace+cbor" type content.
	  The OSCORE option has a decoded interpretation appended in parentheses
	  for the reader's convenience.  Also note that, in this example, the audience
	  is implicitly known by both the client and AS. Furthermore, note that this
	  example uses the <tt>req_cnf</tt> parameter from <xref target="RFC9201"
	  format="default"/>.
          </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)
Uri-Host: "as.example.com"
Uri-Path: "token"
OSCORE: 0x09, 0x05, 0x44, 0x6C
  (h=0, k=1, n=001, partialIV= 0x05, kid=[0x44, 0x6C])
Content-Format: application/oscore
Payload:
  0x44025d1/ ... (full payload omitted for brevity) ... /68b3825e
  
Decrypted payload:
{
  / client_id / 24 : "myclient",
  / req_cnf / 4 : {
    / COSE_Key / 1 : {
      / kty /  1 : 2 / EC2 /,
      / kid /  2 : h'11',
      / crv / -1 : 1 / P-256 /,
      / x /   -2 : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
      / y /   -3 : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'
    }
  }
}
        ]]></sourcecode>
          </figure>
          <t><xref target="fig_kidATreq" format="default"/> shows a request for a token
    where a previously communicated proof-of-possession key is only
    referenced using the <tt>req_cnf</tt> parameter from
    <xref target="RFC9201" format="default"/>.

          </t>
          <figure anchor="fig_kidATreq">
            <name>Example Request for an Access Token Bound to a Key Reference</name>
            <sourcecode name="" type="cbor-diag"><![CDATA[
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: application/ace+cbor
Payload:
{
  / client_id / 24 : "myclient",
  / audience /   5 : "valve424",
  / scope /      9 : "read",
  / req_cnf /    4 : {
     / kid /        3 : b64'6kg0dXJM13U'
  }
}
       ]]></sourcecode>
          </figure>
          <t>Refresh tokens are typically not stored as securely as
	  proof-of-possession keys in requesting clients.  Proof-of-possession-based
	  refresh token requests <bcp14>MUST NOT</bcp14> request different
	  proof-of-possession keys
	  or different audiences in token requests.  Refresh token requests can only be
	  used to request access tokens bound to the same proof-of-possession key and
	  the same audience as access tokens issued in the initial token request.</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
    to its access token request, the AS sends a response with the response
    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
    described in <xref target="errorsToken" format="default"/>.</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
	  knowledge of the capabilities of the client and the RS (see <xref
	  target="app_registration" format="default"/>).  This prior knowledge may,
	  for example, be set
	  by the use of a dynamic client registration protocol exchange
	  <xref target="RFC7591" format="default"/>.  If the client has requested a
	  specific
	  proof-of-possession key using the <tt>req_cnf</tt> parameter from
	  <xref target="RFC9201" format="default"/>, this may also influence which
	  profile the AS selects, as it needs to support the use of the key type
	  requested by the client.</t>
          <t>The content of the successful reply is the Access Information. 
	  When using CoAP, the payload <bcp14>MUST</bcp14> be encoded as a CBOR map;
	  when using
	  HTTP, the encoding is a JSON map, as specified in <xref target="RFC6749"
	  sectionFormat="of" section="5.1"/>.  In both cases, the parameters specified
	  in <xref target="RFC6749" sectionFormat="of" section="5.1"/> are used, with
	  the following additions and changes:</t>
          <dl newline="true" spacing="normal" indent="6">
            <dt>ace_profile:</dt>
            <dd>This parameter is <bcp14>OPTIONAL</bcp14> unless the request included an
	    empty <tt>ace_profile</tt> parameter,
	    in which case it is MANDATORY.  This indicates the profile that the
	    client <bcp14>MUST</bcp14> use towards the RS. See <xref
	    target="paramProfile" format="default"/> for
	    the formatting of this parameter.  If this parameter is absent, the AS
	    assumes that the client implicitly knows which profile to use towards
	    the RS.</dd>
<!--[rfced] We changed 'required' to REQUIRED because it seems to
be a direct mention of what appeared in RFC 6749. If this is not accurate,
please let us know.

Original:
   token_type:
         This parameter is OPTIONAL, as opposed to 'required' in
         [RFC6749]. 

Current:
   token_type:
         This parameter is OPTIONAL, as opposed to REQUIRED in 
         [RFC6749].
		 
		 
Ludwig: Agreed.
-->
            <dt><tt>token_type</tt>:</dt>
            <dd>This parameter is <bcp14>OPTIONAL</bcp14>, as opposed to
	    <bcp14>REQUIRED</bcp14> in
	    <xref target="RFC6749" format="default"/>. By default, implementations of
	    this framework
	    <bcp14>SHOULD</bcp14> assume that the <tt>token_type</tt> is "PoP".  If a specific
	    use case
	    requires another <tt>token_type</tt> (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 when
	  responding to a request to the token endpoint.</t>
          <t><xref target="table_rsinfo" format="default"/> summarizes the parameters 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><tt>access_token</tt></td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>token_type</tt></td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>expires_in</tt></td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>refresh_token</tt></td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>scope</tt></td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>state</tt></td>
		<td><xref target="RFC6749" format="default"/></td>
              </tr>
	      <tr>
		<td><tt>error</tt></td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>error_description</tt></td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>error_uri</tt></td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>ace_profile</tt></td>
		<td>RFC 9200</td>
	      </tr>
	      <tr>
		<td><tt>cnf</tt></td>
		<td><xref target="RFC9201" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>rs_cnf</tt></td>
		<td><xref target="RFC9201" format="default"/></td>
	      </tr>
	    </tbody>
	  </table>
          <t><xref target="fig_symmATres" format="default"/> shows a response containing a token
    and a <tt>cnf</tt> parameter with a symmetric proof-of-possession key, which
    is defined in <xref target="RFC9201" format="default"/>.  Note that
    the key identifier <tt>kid</tt> is only used to simplify indexing and
    retrieving the key, and no assumptions should be made that it is
    unique in the domains of either the client or the RS.

          </t>
          <figure anchor="fig_symmATres">
            <name>Example AS Response with an Access Token Bound to a Symmetric Key</name>
            <sourcecode name="" type="cbor-diag"><![CDATA[
Header: Created (Code=2.01)
Content-Format: application/ace+cbor
Payload:
{
  / access_token / 1 : b64'SlAV32hk'/ ...
   (remainder of CWT omitted for brevity;
   CWT contains COSE_Key in the cnf claim)/,
  / ace_profile / 38 : "coap_dtls",
  / expires_in /   2 : 3600,
  / cnf / 8 : {
    / COSE_Key / 1 : {
      / kty / 1 : 4 / Symmetric /,
      / kid / 2 : b64'39Gqlw',
      / k /  -1 : b64'hJtXhkV8FJG+Onbc6mxC'
    }
  }
}
      ]]></sourcecode>
          </figure>
        </section>
        <section anchor="errorsToken" numbered="true" toc="default">
          <name>Error Response</name>
          <t>The error responses for interactions with the AS are generally
    equivalent to the ones defined in <xref target="RFC6749" sectionFormat="of" section="5.2"/>,
    with the following exceptions:

          </t>
          <ul spacing="normal">
            <li>When using CoAP, the payload <bcp14>MUST</bcp14> be encoded as a CBOR
	    map, with
	    the Content-Format "application/ace+cbor".  When using HTTP, the
            payload is encoded in JSON, as specified in <xref target="RFC6749"
	    sectionFormat="of" section="5.2"/>.</li>
            <li>A response code equivalent to the CoAP code 4.00 (Bad Request)
	    <bcp14>MUST</bcp14>
	    be used for all error responses, except for invalid_client, where a
	    response code equivalent to the CoAP code 4.01 (Unauthorized)
	    <bcp14>MAY</bcp14> be
	    used under the same conditions as specified in 
	    <xref target="RFC6749" sectionFormat="of" section="5.2"/>.</li>
            <li>The parameters <tt>error</tt>, <tt>error_description</tt>, and <tt>error_uri</tt> <bcp14>MUST</bcp14>
	be abbreviated using the codes specified in <xref target="table_cborTokenParameters" format="default"/>, when a CBOR encoding is used.</li>
            <li>The error code (i.e., value of the <tt>error</tt> parameter) <bcp14>MUST</bcp14> be
	abbreviated, as specified in <xref target="table_cborErrorCodes" format="default"/>, when a CBOR encoding is used.</li>
          </ul>

<!--[rfced] Please review whether "abbreviations" is an accurate term 
as used in this document. For example: Section 5.8 refers to "integer 
abbreviations for the parameters or their values". 

Specifically, in the cases below, perhaps "values" would be more
precise than "abbreviations"? (where "CBOR Value" is the column title 
in the corresponding IANA registry)

Current:
   Table 3: CBOR Abbreviations for Common Error Codes
Perhaps:
   Table 3: CBOR Values for Common Error Codes

Current:
   Table 4: CBOR Abbreviations for Common Grant Types
Perhaps: 
   Table 4: CBOR Values for Common Grant Types
   
   
 Ludwig: CBOR does also have string values, so just calling these "values" looses some important context.
 The intention was to abbreviate long string values into compact integer representations. I would therefore 
 prefer to keep the term "Abbreviations"
-->
          <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><tt>invalid_request</tt></td>
		<td>1</td>
		<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td>
	      </tr>
	      <tr>
		<td><tt>invalid_client</tt></td>
		<td>2</td>
		<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td>
	      </tr>
	      <tr>
		<td><tt>invalid_grant</tt></td>
		<td>3</td>
		<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td>
	      </tr>
	      <tr>
		<td><tt>unauthorized_client</tt></td>
		<td>4</td>
		<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td>
	      </tr>
	      <tr>
		<td><tt>unsupported_grant_type</tt></td> 
		<td>5</td>
		<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td>
	      </tr>
	      <tr>
		<td><tt>invalid_scope</tt></td>
		<td>6</td>
		<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td>
	      </tr>
	      <tr>
		<td><tt>unsupported_pop_key</tt></td>
		<td>7</td>
		<td>RFC 9200</td>
	      </tr>
	      <tr>
		<td><tt>incompatible_ace_profiles</tt></td>
		<td>8</td>
		<td>RFC 9200</td>
	      </tr>
	    </tbody>
	  </table>
          <t>In addition to the error responses defined in OAuth 2.0, the following
	  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 that the
	    RS cannot process, the AS <bcp14>MUST</bcp14> reject that request with a
	    response code equivalent to the CoAP code 4.00 (Bad Request), including 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 request with
	    a response code equivalent to the CoAP code 4.00 (Bad Request), including
	    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 for
	  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
      in <xref target="RFC6749" format="default"/> if CBOR payloads are used.

            </t>
            <table anchor="table_grant_types">
              <name>CBOR Abbreviations for Common Grant Types</name>
	      <thead>
		<tr>
		  <th>Name</th>
		  <th>CBOR Value</th>
		  <th>Original Specification</th>
		</tr>
	      </thead>
	      <tbody>
		<tr>
		  <td><tt>password</tt></td>
		  <td>0</td>
		  <td><xref target="RFC6749" sectionFormat="of" section="4.3.2"/></td>
		</tr>
		<tr>
		  <td><tt>authorization_code</tt></td>
		  <td>1</td>
		  <td><xref target="RFC6749" sectionFormat="of" section="4.1.3"/></td>
		</tr>
		<tr>
		  <td><tt>client_credentials</tt></td>
		  <td>2</td>
		  <td><xref target="RFC6749" sectionFormat="of" section="4.4.2"/></td>
		</tr>
		<tr>
		  <td><tt>refresh_token</tt></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 <tt>token_type</tt> 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>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 <tt>token_type</tt> 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 <tt>token_type</tt> parameter is
	    the default. The AS may, however, provide a different value from those
	    registered in <xref target="IANA.OAuthAccessTokenTypes" format="default"/>.</t>
          </section>
          <section anchor="paramProfile" numbered="true" toc="default">
            <name>Profile</name>
            <t>Profiles of this framework <bcp14>MUST</bcp14> define the communication
	    protocol and the communication security protocol between the client
	    and the RS.  The security protocol <bcp14>MUST</bcp14> provide encryption,
	    integrity, and
	    replay protection. It <bcp14>MUST</bcp14> also provide a binding between
	    requests and
	    responses.  Furthermore, profiles <bcp14>MUST</bcp14> define a list of
	    allowed proof-of-possession methods if they support proof-of-possession
	    tokens.</t>
            <t>A profile <bcp14>MUST</bcp14> specify an identifier that <bcp14>MUST</bcp14> be used to uniquely
      identify itself in the <tt>ace_profile</tt> parameter. The textual
      representation of the profile identifier is intended for human
      readability and for JSON-based interactions; it <bcp14>MUST NOT</bcp14> be used for
      CBOR-based interactions.  Profiles <bcp14>MUST</bcp14> register their identifier in the
      registry defined in <xref target="IANAProfile" format="default"/>.
            </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
      support negotiation or signaling of profile-specific parameters.
            </t>
            <t>Clients that want the AS to provide them with the <tt>ace_profile</tt>
	    parameter in the access token response can indicate that by sending an
	    <tt>ace_profile</tt> parameter with a null value for CBOR-based interactions, 
	    or an empty string if CBOR is not used, in the access token
	    request.</t>
          </section>
          <section anchor="cnonceParamToken" numbered="true" toc="default">
            <name>Client-Nonce</name>
            <t>This parameter <bcp14>MUST</bcp14> be sent from the client to the AS
	    if it previously received a <tt>cnonce</tt> parameter in the AS Request
	    Creation Hints (<xref target="asInfo" format="default"/>).  The parameter
	    is encoded as a byte string for CBOR-based interactions and as a
	    string (base64url without padding encoded binary <xref target="RFC4648"
	    format="default"/>) if CBOR is not used.
	    It <bcp14>MUST</bcp14> copy the value from the <tt>cnonce</tt> parameter in the AS
	    Request Creation Hints.</t>
          </section>
        </section>
        <!--Parameters -->

  <section anchor="tokenCborParams" numbered="true" toc="default">
          <name>Mapping Parameters to CBOR</name>
          <t>If CBOR encoding is used, all OAuth parameters in access token requests
    and responses <bcp14>MUST</bcp14> be mapped to CBOR types, as specified in the registry
    defined by <xref target="IANAOAuthParameterMappingsRegistry" format="default"/>, using the
    given integer abbreviation for the map keys.</t>
          <t>Note that we have aligned the abbreviations corresponding to claims
    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
    size in CBOR. We have thus chosen to assign abbreviations in that
    range to parameters we expect to be used most frequently in constrained
    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><tt>access_token</tt></td>
		<td>1</td>
		<td>byte string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>expires_in</tt></td>
		<td>2</td>
		<td>unsigned integer</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>audience</tt></td>
		<td>5</td>
		<td>text string</td>
		<td><xref target="RFC8693" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>scope</tt></td>
		<td>9</td>
		<td>text or byte string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>client_id</tt></td>
		<td>24</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>client_secret</tt></td>
		<td>25</td>
		<td>byte string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>response_type</tt></td>
		<td>26</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>redirect_uri</tt></td>
		<td>27</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>state</tt></td>
		<td>28</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>code</tt></td>
		<td>29</td>
		<td>byte string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>error</tt></td>
		<td>30</td>
		<td>integer</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>error_description</tt></td>
		<td>31</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>error_uri</tt></td>
		<td>32</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>grant_type</tt></td>
		<td>33</td>
		<td>unsigned integer</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>token_type</tt></td>
		<td>34</td>
		<td>integer</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>username</tt></td>
		<td>35</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>password</tt></td>
		<td>36</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>refresh_token</tt></td>
		<td>37</td>
		<td>byte string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>ace_profile</tt></td>
		<td>38</td>
		<td>integer</td>
		<td>RFC 9200</td>
	      </tr>
	      <tr>
		<td><tt>cnonce</tt></td>
		<td>39</td>
		<td>byte string</td>
		<td>RFC 9200</td>
	      </tr>
	    </tbody>
	  </table>
        </section>
      </section>
      <!-- Token endpoint -->

<section anchor="introspectionEndpoint" numbered="true" toc="default">
        <name>The Introspection Endpoint</name>
        <t>Token introspection <xref target="RFC7662" format="default"/> <bcp14>MAY</bcp14>
	be implemented by the AS and the RS. When implemented, it <bcp14>MAY</bcp14> be
	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" format="default"/> 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.  The client MAY also implement and use introspection analogously to the RS, to obtain information about a given token.</t>
        <t>Communication between the requesting entity and the introspection endpoint
  at the AS <bcp14>MUST</bcp14> be integrity protected and encrypted.  The communication
  security protocol <bcp14>MUST</bcp14> also provide a binding between requests and
  responses.  Furthermore, the two interacting parties <bcp14>MUST</bcp14> perform mutual
  authentication.  Finally, the AS <bcp14>SHOULD</bcp14> verify that the requesting entity has
  the right to access introspection information about the provided token.
  Profiles of this framework that support introspection <bcp14>MUST</bcp14> specify how
  authentication and communication security between the requesting
  entity and the AS is implemented.</t>
        <t> The default name of this endpoint in a url-path <bcp14>SHOULD</bcp14> be '/introspect'.
  However, implementations are not required to use this name and can define
  their own instead.</t>

        <section anchor="introReq" numbered="true" toc="default">
          <name>Introspection Request</name>
          <t>The requesting entity sends a POST request to the introspection endpoint
    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 with a <tt>token</tt>
    entry containing the access token.  Further optional parameters
    representing additional context that is known by the requesting entity to
    aid the AS in its response <bcp14>MAY</bcp14> be included.</t>
          <t>For CoAP-based interaction, all messages <bcp14>MUST</bcp14> use the content
	  type "application/ace+cbor". For HTTP, the encoding defined in 
	  <xref target="RFC7662" sectionFormat="of" section="2.1"/> is used.</t>
          <t>The same parameters are required and optional as in 
	  <xref target="RFC7662" sectionFormat="of" section="2.1"/>.</t>
          <t>For example, <xref target="fig_introReq" format="default"/> shows an RS
	  calling the token
	  introspection endpoint at the AS to query about an OAuth 2.0
	  proof-of-possession token.  Note that object security based on OSCORE
	  <xref target="RFC8613" format="default"/> is assumed in this example;
	  therefore, the Content-Format is "application/oscore". <xref
	  target="fig_introReq-payl" format="default"/> shows the decoded payload.</t>
          <figure anchor="fig_introReq">
            <name>Example Introspection Request</name>
            <sourcecode name="" type=""><![CDATA[
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "introspect"
OSCORE: 0x09, 0x05, 0x25
Content-Format: application/oscore
Payload:
... COSE content ...
       ]]></sourcecode>
          </figure>
          <figure anchor="fig_introReq-payl">
            <name>Decoded Payload</name>
            <sourcecode name="" type="cbor-diag"><![CDATA[
{
  / token / 11  : b64'7gj0dXJQ43U',
  / token_type_hint / 33 : 2 / PoP /
}
       ]]></sourcecode>
          </figure>
        </section>
        <section anchor="introRes" numbered="true" toc="default">
          <name>Introspection Response</name>
          <t>If the introspection request is authorized and successfully processed,
	  the AS sends a response with the response code equivalent to the CoAP code
	  2.01 (Created).  If the introspection request was invalid, not authorized,
	  or couldn't be processed, the AS returns an error response, as described in
	  <xref target="errorsIntro" format="default"/>.</t>
          <t>In a successful response, the AS encodes the response parameters in
	  a map.  If CoAP is used, this <bcp14>MUST</bcp14> be encoded as a CBOR map; if
	  HTTP is used, the JSON encoding specified in <xref target="RFC7662"
	  sectionFormat="of" section="2.2"/>
	  is used.  The map containing the response payload  includes the same
	  required and optional parameters as in
	  <xref target="RFC7662" sectionFormat="of" section="2.2"/>, with the following
	  additions:</t>
          <dl newline="true" spacing="normal">
            <dt><tt>ace_profile</tt></dt>
            <dd>This parameter is <bcp14>OPTIONAL</bcp14>.  This indicates the profile that
	    the RS <bcp14>MUST</bcp14> use with the
	    client.  See <xref target="paramProfile" format="default"/> for more details on
	    the formatting of this parameter. If this parameter is absent, the AS
	    assumes that the RS implicitly knows which profile to use towards
	    the client.</dd>
            <dt><tt>cnonce</tt></dt>
            <dd>This parameter is <bcp14>OPTIONAL</bcp14>.  This is a
	    client-nonce provided to the AS by the client.
	    The RS <bcp14>MUST</bcp14> verify that this corresponds to the
	    client-nonce
	    previously provided to the client in the AS Request Creation
	    Hints. See Sections <xref target="asInfo" format="counter"/> and
	    <xref target="cnonceParamToken" format="counter"/>. 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><tt>cti</tt></dt>
	    <dd>This parameter is <bcp14>OPTIONAL</bcp14>.  This is the <tt>cti</tt> claim 
		associated to this access token.
	    This parameter has the same meaning and processing rules as the
	    <tt>jti</tt> parameter defined in <xref target="RFC7662" sectionFormat="of"
	    section="3.1.2"/> except that its value is a byte string when encoded
	    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
	    <tt>expires_in</tt> 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 responding to a
    request to the introspection endpoint.</t>
          <t>For example, <xref target="fig_introRes" format="default"/> shows an AS
    response to the introspection request in <xref target="fig_introReq" format="default"/>.
    Note that this example contains the <tt>cnf</tt> parameter defined in
    <xref target="RFC9201" format="default"/>.

          </t>
          <figure anchor="fig_introRes">
            <name>Example Introspection Response</name>
            <sourcecode name="" type="cbor-diag"><![CDATA[
Header: Created (Code=2.01)
Content-Format: application/ace+cbor
Payload:
{
  / active /      10 : true,
  / scope /        9 : "read",
  / ace_profile / 38 : 1 / coap_dtls /,
  / cnf /          8 : {
    / COSE_Key / 1 : {
      / kty / 1 : 4 / Symmetric /,
      / kid / 2 : b64'39Gqlw',
      / k /  -1 : b64'hJtXhkV8FJG+Onbc6mxC'
    }
  }
}
      ]]></sourcecode>
          </figure>
        </section>
        <section anchor="errorsIntro" numbered="true" toc="default">
          <name>Error Response</name>
          <t>The error responses for CoAP-based interactions with the AS
	  are equivalent to the ones for HTTP-based interactions, as defined in
	  <xref target="RFC7662" sectionFormat="of" section="2.3"/>, with the
	  following differences:</t>
          <ul spacing="normal">
            <li>If content is sent and CoAP is used, the payload <bcp14>MUST</bcp14> be
	    encoded as a
	    CBOR map and the Content-Format "application/ace+cbor" <bcp14>MUST</bcp14>
	    be used.
	    For HTTP, the encoding defined in <xref target="RFC6749" sectionFormat="of"
	    section="2.3"/> is used.</li>
            <li>If the credentials used by the requesting entity (usually the RS)
	    are invalid, the AS <bcp14>MUST</bcp14> respond with the response code
	    equivalent to the
	    CoAP code 4.01 (Unauthorized) and use the required and optional
	    parameters from <xref target="RFC7662" sectionFormat="of"
	    section="2.3"/>.</li>
            <li>If the requesting entity does not have the right to perform this
      introspection request, the AS <bcp14>MUST</bcp14> respond with a response code
      equivalent to the CoAP code 4.03 (Forbidden).  In this case, no payload is
      returned.</li>
            <li>The parameters <tt>error</tt>, <tt>error_description</tt>, and <tt>error_uri</tt> <bcp14>MUST</bcp14>
      be abbreviated using the codes specified in <xref target="table_cborTokenParameters" format="default"/>.</li>
            <li>The error codes <bcp14>MUST</bcp14> be abbreviated using the codes specified in
      the registry defined by <xref target="IANAErrorCBORMappings" format="default"/>.</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
    specification.  In these cases, the authorization server <bcp14>MUST</bcp14> instead
    respond with an introspection response with the <tt>active</tt> field set to
    "false".</t>
        </section>
        <section anchor="introParamsCbor" numbered="true" toc="default">
          <name>Mapping Introspection Parameters to CBOR</name>
          <t>If CBOR is used, the introspection request and response parameters <bcp14>MUST</bcp14>
    be mapped to CBOR types, as specified in the registry defined by <xref target="IANAIntrospectionEndpointCBORMappingsRegistry" format="default"/>, using the given
    integer abbreviation for the map key.</t>
          <t>Note that we have aligned abbreviations that correspond to a
    claim with the abbreviations defined in <xref target="RFC8392" format="default"/>
    and the abbreviations of parameters with the same name from
    <xref target="tokenCborParams" format="default"/>.
          </t>
          <table anchor="table_cborIntrospectionParameters">
            <name>CBOR Mappings for Token Introspection Parameters</name>
	    <thead>
	      <tr>
		<th>Parameter name</th>
		<th>CBOR Key</th>
		<th>Value Type</th>
		<th>Original Specification</th>
	      </tr>
	    </thead>
	    <tbody>
	      <tr>
		<td><tt>iss</tt></td>
		<td>1</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>sub</tt></td>
		<td>2</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>aud</tt></td>
		<td>3</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>exp</tt></td>
		<td>4</td>
		<td>integer or floating-point number</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>nbf</tt></td>
		<td>5</td>
		<td>integer or floating-point number</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>iat</tt></td>
		<td>6</td>
		<td>integer or floating-point number</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>cti</tt></td>
		<td>7</td>
		<td>byte string</td>
		<td>RFC 9200</td>
	      </tr>
	      <tr>
		<td><tt>scope</tt></td>
		<td>9</td>
		<td>text or byte string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>active</tt></td>
		<td>10</td>
		<td>True or False</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>token</tt></td>
		<td>11</td>
		<td>byte string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>client_id</tt></td>
		<td>24</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>error</tt></td>
		<td>30</td>
		<td>integer</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>error_description</tt></td>
		<td>31</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>error_uri</tt></td>
		<td>32</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>token_type_hint</tt></td>
		<td>33</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>token_type</tt></td>
		<td>34</td>
		<td>integer</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>username</tt></td>
		<td>35</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td><tt>ace_profile</tt></td>
		<td>38</td>
		<td>integer</td>
		<td>RFC 9200</td>
	      </tr>
	      <tr>
		<td><tt>cnonce</tt></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.

Original:
    | exi               | 40       | unsigned integer  |[this document]|

Current:
    | exi               | 40   | integer              | RFC 9200      |
	
Ludwig: There is an inconsistence in the IANA registrations. The introspection parameter has "unsigned integer" 
while the CWT claim has "integer". "unsigned integer" is correct. I will notify IANA. Document is corrected
	
-->
	      <tr>
		<td>exi</td>
		<td>40</td>
		<td>unsigned integer</td>
		<td>RFC 9200</td>
	      </tr>
	    </tbody>
	  </table>
        </section>
      </section>
      <!-- introspection endpoint -->

<section anchor="accessToken" numbered="true" toc="default">
        <name>The Access Token</name>
        <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 <tt>cnf</tt> claim from <xref target="RFC8747" format="default"/>
  and the <tt>scope</tt> claim from <xref target="RFC8693" format="default"/> for
  JWT- and CWT-encoded tokens.  In addition to string encoding specified for
  the <tt>scope</tt> claim, a binary encoding <bcp14>MAY</bcp14> be used.  The syntax of such an
  encoding is explicitly not specified here and left to profiles or
  applications, specifically note that a binary encoded scope does not
  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
  should use to communicate with the client, the AS <bcp14>MAY</bcp14> include an
  <tt>ace_profile</tt> claim in the access token, with the same syntax and semantics
  as defined in <xref target="paramProfile" format="default"/>.</t>
        <t>If the client submitted a <tt>cnonce</tt> parameter in the access token
	request (<xref target="cnonceParamToken" format="default"/>), the AS
	<bcp14>MUST</bcp14> include the value of
	this parameter in the <tt>cnonce</tt> claim specified here.  The <tt>cnonce</tt> claim
	uses binary encoding.</t>
        <section anchor="tokenAuthInfoEndpoint" numbered="true" toc="default">
          <name>The Authorization Information Endpoint</name>
          <t>The access token, containing authorization information and information
  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
  client request.</t>
          <t>This section defines a method for transporting the access token to the RS
  using a RESTful protocol, such as CoAP. Profiles of this framework <bcp14>MAY</bcp14> define
  other methods for token transport.
          </t>
          <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 authz-info
  endpoint at the RS with the access token in the payload.  The CoAP 
  Content-Format or HTTP media type <bcp14>MUST</bcp14> reflect the format of the token,
  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>
          <t>The RS receiving the token <bcp14>MUST</bcp14> verify the validity of the
	  token.  If the
	  token is valid, the RS <bcp14>MUST</bcp14> respond to the POST request 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>
          <t>The RS <bcp14>MUST</bcp14> be prepared to store at least one access token for future
  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
  therefore not stored at the RS.</t>
          <t>When using this framework, it is <bcp14>RECOMMENDED</bcp14> that an RS stores
	  only one token per proof-of-possession key.  This means that an additional token
	  linked to the same key will supersede any existing token at the RS by replacing
	  the corresponding authorization information.  The reason is that
	  this greatly simplifies (constrained) implementations, with respect to
	  required storage and resolving a request to the applicable token.  The use of
	  multiple access tokens for a single client increases the strain on the
	  resource server, as it must consider every access token and calculate the
	  actual permissions of the client.  Also, tokens may contradict each other,
	  which may lead the server to enforce wrong permissions.  If one of the 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>
          <t>The RS <bcp14>MAY</bcp14> make an introspection request to validate the token before
  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
  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
  an introspection response.
          </t>
          <t>Profiles <bcp14>MUST</bcp14> specify whether the authz-info endpoint is protected,
  including whether error responses from this endpoint are protected.  Note that
  since the token contains information that allows the client and the RS to
  establish a security context in the first place, mutual authentication may
  not be possible at this point.</t>
          <t>The default name of this endpoint in a url-path is '/authz-info';
	  however, implementations are not required to use this name and can define
	  their own instead.</t>
          <section anchor="verifyToken" numbered="true" toc="default">
            <name>Verifying an Access Token</name>
            <t>When an RS receives an access token, it <bcp14>MUST</bcp14> verify it before storing
    it. The details of token verification depends on various aspects, including 
    the token encoding, the type of token, the security protection applied to
    the token, and the claims.  The token encoding matters since the security
    protection differs between the token encodings. For example, a CWT token
    uses COSE, while a JWT token uses JSON Object Signing and Encryption (JOSE).  
<!--[rfced] Should "token-by-reference" be "reference token" in this sentence?

Original:
   The type of token also has an influence on the verification
   procedure since tokens may be self-contained whereby token
   verification may happen locally at the RS while a token-by-reference
   requires further interaction with the authorization server, for
   example using token introspection, to obtain the claims associated
   with the token reference. 
   
   
 Ludwig: They mean the same, but "reference token" seems to be more commonly used.
 I have replace the occurence
-->
    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 
    reference token 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</bcp14> 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 format.
	    For CWT, the description can be found in <xref target="RFC8392"
	    format="default"/>; for
	    JWT, the relevant specification is <xref target="RFC7519" format="default"/>. 
	    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 obtain
    the claims first. When the RS uses token introspection, the relevant
    specification is <xref target="RFC7662" format="default"/> with CoAP transport 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 token
	  was issued by an AS that does not have the right to issue tokens
	  for the receiving RS, the RS <bcp14>MUST</bcp14> discard the token
	  and, if this was an interaction with authz-info, return an error
	  message with a response code equivalent to the CoAP code 4.01
	  (Unauthorized).</li>
              <li>If the claims cannot be obtained, the RS <bcp14>MUST</bcp14> discard the token and,
	  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
	  Request).</li>
            </ul>
            <t>Next, the RS <bcp14>MUST</bcp14> verify claims, if present, contained in the
	    access
	    token. Errors are returned when claim checks fail, in the order of
	    priority of this list:
            </t>
            <dl newline="true" spacing="normal">
              <dt><tt>iss</tt></dt>
              <dd>The <tt>iss</tt> claim (if present) must identify the AS that
	      has produced the security protection for the access token.  If that is
	      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.01 (Unauthorized).</dd>
              <dt><tt>exp</tt></dt>
              <dd>The expiration date must be in the future.  
	      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.01 (Unauthorized). Note that the RS has to
	      terminate access rights to the protected resources at the time when the
	      tokens expire. </dd>
              <dt><tt>aud</tt></dt>
              <dd>The <tt>aud</tt> claim must refer to an audience that
	      the RS identifies with. If that is not the case, the RS <bcp14>MUST</bcp14>
	      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><tt>scope</tt></dt>
              <dd>The RS must recognize value of the <tt>scope</tt> claim.
	      If that is not the case, the RS <bcp14>MUST</bcp14> discard the token.  If
	      this was an
	      interaction with authz-info, the RS <bcp14>MUST</bcp14> also respond 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>
            <t>Note that the <tt>sub</tt> (Subject) claim cannot always be verified when
    the token is submitted to the RS since the client may not have
    authenticated yet. Also note that a counter for the <tt>exi</tt> (expires in) claim
    <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
    transport mechanisms that do not allow for error responses.  Therefore, the
    error messages specified here only apply if the token was sent to the
    authz-info endpoint.</t>
            <t>When sending error responses, the RS <bcp14>MAY</bcp14> use the error
	    codes from <xref target="RFC6750" sectionFormat="of" section="3.1"/> to
	    provide additional details to the client.</t>
          </section>
          <section anchor="protAuthzInfo" numbered="true" toc="default">
            <name>Protecting the Authorization Information Endpoint</name>
            <t>As this framework can be used in RESTful environments, it is important
	    to make sure that attackers cannot perform unauthorized requests on the
	    authz-info endpoints, other than submitting access tokens.</t>
            <t>Specifically, it <bcp14>SHOULD NOT</bcp14> be possible to perform GET,
	    DELETE, or PUT on the authz-info endpoint.</t>
            <t>The RS <bcp14>SHOULD</bcp14> implement rate-limiting measures to mitigate
	    attacks aiming
	    to overload the processing capacity of the RS by repeatedly submitting
	    tokens. For CoAP-based communication, the RS could use the mechanisms from
	    <xref target="RFC8516" format="default"/> to indicate that it is overloaded.</t>
          </section>
        </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> verify that the keys
  used to protect this communication are still valid. See <xref target="keyExpiration" format="default"/> for details on how the client determines the
  validity of the keys used.</t>
          <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 access token
  that authorizes this request and that the client has performed the
  proof-of-possession binding for that token to the request.</t>
          <t>The response code <bcp14>MUST</bcp14> be 4.01 (Unauthorized) in case the client has
  not performed the proof of possession or if the RS has no valid access token for
  the client. If the RS has an access token for the client but the token does not
  authorize access for the resource that was requested, the RS <bcp14>MUST</bcp14> reject the
  request with a 4.03 (Forbidden). If the RS has an access token for the client but
  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>
          <t>Note: The use of the response codes 4.03 and 4.05 is intended to prevent
  infinite loops where a client optimistically tries to access a
  requested resource with any access token received from AS. As malicious
  clients could pretend to be the C to determine the C's privileges, these detailed
  response codes must be used only when a certain level of security is
  already available, which can be achieved only when the client is
  authenticated.</t>
          <t>Note: The RS <bcp14>MAY</bcp14> use introspection for timely validation of an
  access token at the time when a request is presented.</t>
          <t>Note: Matching the claims of the access token (e.g., <tt>scope</tt>) to a specific
  request is application specific.</t>
          <t>If the request matches a valid token and the client has performed the
  proof of possession for that token, the RS continues to process the request
  as specified by the underlying application.</t>
        </section>
        <section anchor="tokenExpiration" numbered="true" toc="default">
          <name>Token Expiration</name>
          <t>Depending on the capabilities of the RS, there are various ways in
	  which it can verify the expiration of a received access token.  The following is
	  a list of the possibilities including what functionality they require of the
	  RS.</t>
          <ul spacing="normal">
            <li>The token is a CWT and includes an <tt>exp</tt> claim and possibly the
	    <tt>nbf</tt> claim.  The RS verifies these by comparing them to values from
	    its internal clock, as defined in <xref target="RFC7519" format="default"/>.  In
	    this case, the RS's internal clock must reflect the current date and time or
	    at least be synchronized with the AS's clock.  How this clock
	    synchronization would be performed is out of scope for this
	    specification.</li>
            <li>The RS verifies the validity of the token by performing an
	    introspection request, as specified in <xref target="introspectionEndpoint"
	    format="default"/>.  This requires the RS to have a
	    reliable network connection to the AS and to be able to handle two
	    secure sessions in parallel (C to RS and RS to AS).</li>
            <li>In order to support token expiration for devices that have no reliable
	    way of synchronizing their internal clocks, this specification defines the
	    following approach: The claim <tt>exi</tt> (expires in) can be used to provide
	    the RS with the lifetime of the token in seconds from the time the RS first
	    receives the token.  This mechanism only works for self-contained tokens,
	    i.e., CWTs and JWTs. For CWTs, this parameter is encoded as an unsigned integer,
	    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 <tt>exi</tt> claim,
		keep track of the time it received that token and revisit that list
		regularly to expunge expired tokens.</li>
                <li>
                  <t>Keep track of the identifiers of tokens containing the <tt>exi</tt>
      claim that have expired (in order to avoid accepting them again).
      In order to avoid an unbounded memory usage growth, this <bcp14>MUST</bcp14> be
      implemented in the following way when the <tt>exi</tt> claim is used:
                  </t>
                  <ul spacing="normal">
                    <li>When creating the token, the AS <bcp14>MUST</bcp14> add a <tt>cti</tt> claim (
	or <tt>jti</tt> for JWTs) to the access token.  The value of this claim
	<bcp14>MUST</bcp14> be created as the binary representation of the concatenation
	of the identifier of the RS with a sequence number counting the
	tokens containing an <tt>exi</tt> claim, issued by this AS for the
	RS.</li>
                    <li>The RS <bcp14>MUST</bcp14> store the highest sequence number of an expired
	token containing the <tt>exi</tt> claim that it has seen and treat
	tokens with lower sequence numbers as expired.  Note that
        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
	RS.  The assumption is that typically tokens in such a scenario would
	all have the same validity time.</li>
                  </ul>
                </li>
              </ul>
            </li>
          </ul>
          <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
  (Unauthorized) to the client and then terminate processing the long-running
  request.</t>
        </section>
        <section anchor="keyExpiration" numbered="true" toc="default">
          <name>Key Expiration</name>
          <t>The AS provides the client with key material that the RS uses. This can
  either be a common symmetric PoP key or an asymmetric key used by the RS to
  authenticate towards the client.  Since there is currently no expiration
  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
  requests containing sensitive information to the RS using a key that is
  expired and possibly in the hands of an attacker or where the client accepts responses from
  the RS that are not properly protected and could possibly have been forged by
  an attacker. 
          </t>
          <t>In order to prevent this, the client must assume that those keys are
  only valid as long as the related access token is.  Since the access token
  is opaque to the client, one of the following methods <bcp14>MUST</bcp14> be used to
  inform the client about the validity of an access token:

          </t>
          <ul spacing="normal">
            <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
    AS or published by the AS in a way that the client can query.</li>
            <li>The AS informs the client about the token validity using the
    <tt>expires_in</tt> parameter in the Access Information.</li>
          </ul>
          <t>A client that is not able to obtain information about the expiration of a
  token <bcp14>MUST NOT</bcp14> use this token.</t>
        </section>
      </section>
      <!-- access token -->

</section>
    <!--Framework-->

<section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Security considerations applicable to authentication and authorization
  in RESTful environments provided in OAuth 2.0 <xref target="RFC6749" format="default"/> apply
  to this work.  Furthermore, <xref target="RFC6819" format="default"/>
  provides additional security considerations for OAuth, which apply to IoT
  deployments as well.  If the introspection endpoint is used,
  the security considerations from <xref target="RFC7662" format="default"/> also apply.</t>
      <t>The following subsections address issues specific to this document and
      its use in constrained environments.</t>
      <section anchor="tokenProtection" numbered="true" toc="default">
        <name>Protecting Tokens</name>
        <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
	digest, e.g., a Message Authentication Code (MAC) or an Authenticated 
	Encryption with Associated Data (AEAD)
	algorithm.  Consequently, the token integrity protection <bcp14>MUST</bcp14> be
	applied to prevent the token from being modified, particularly since it contains
	a reference to the symmetric key or the asymmetric key used for
	proof of possession.  If the access token contains the symmetric key,
	this symmetric key <bcp14>MUST</bcp14> be encrypted by the authorization server so
	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,
      shared between the AS and the recipients, is not sufficient, since any of
      the recipients could modify the token undetected by the other recipients.
      Therefore, a token with a multirecipient audience <bcp14>MUST</bcp14> be protected
      with an asymmetric signature.</t>
        <t>It is important for the authorization server to include the identity
      of the intended recipient (the audience), typically a single resource
      server (or a list of resource servers), in the token.  The same
      shared secret <bcp14>MUST NOT</bcp14> be used as a proof-of-possession key with
      multiple resource servers, since the benefit from using the proof-of-possession
      concept is then significantly reduced.</t>
        <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
      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
      the resource server.  Shorter keys also lead to shorter messages
      (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 permission.</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 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" numbered="true" toc="default">
        <name>Communication Security</name>
        <t>Communication with the authorization server <bcp14>MUST</bcp14> use confidentiality
      protection.  This step is extremely important since the client or the
      RS may obtain the proof-of-possession key from the authorization server
      for use with a specific access token.  Not using confidentiality
      protection exposes this secret (and the access token) to an eavesdropper,
      thereby completely negating proof-of-possession security.
      The requirements for communication security of profiles are specified
      in <xref target="oauthProfile" format="default"/>.</t>
        <t>Additional protection for the access token can be applied by
	encrypting it, for example, encryption of CWTs is specified in
	<xref target="RFC8392" sectionFormat="of" section="7.1"/>.  Such additional
	protection can be necessary
	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 be taken by developers to prevent leakage of the PoP 
      credentials (i.e., the private key or the symmetric key).  An
      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
      real risk with many constrained environments, since adversaries may
      get physical access to the devices and can therefore use physical
      extraction techniques to gain access to memory contents.  This risk can 
      be mitigated to some extent by making sure that keys are refreshed
      frequently, by using software isolation techniques, and by using hardware
	security.</t>
      </section>
      <!--communication security-->

    <section anchor="keys" numbered="true" toc="default">
        <name>Long-Term Credentials</name>
        <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
      devices deployed in publicly accessible places, such protection can
      be difficult to achieve without specialized hardware (e.g., secure
      key storage memory).</t>
        <t>If credentials are lost or compromised, the operator of the affected
      devices needs to have procedures to invalidate any access these
      credentials give and needs to revoke tokens linked to such credentials.  The
      loss of a credential linked to a specific device <bcp14>MUST NOT</bcp14> lead to a
      compromise of other credentials not linked to that device; therefore,
      secret keys used for authentication <bcp14>MUST NOT</bcp14> be shared between more than
      two parties.</t>
        <t>Operators of the clients or RSs <bcp14>SHOULD</bcp14> have procedures in place to
      replace credentials that are suspected to have been compromised or that
      have been lost.</t>
        <t>Operators also <bcp14>SHOULD</bcp14> have procedures for decommissioning devices
      that include securely erasing credentials and other security-critical
      material in the devices being decommissioned.</t>
      </section>
      <!--credential livecycle-->
 
    <section anchor="unprotected-as-information" numbered="true" toc="default">
        <name>Unprotected AS Request Creation Hints</name>
        <t>Initially, no secure channel exists to protect the communication
	between the C and RS. Thus, the C cannot determine if the AS Request
	Creation Hints contained in an unprotected response from the RS to an
	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
	of scope for this document and left to the applications.</t>
      </section>
      <section anchor="minimalCommSecReq" numbered="true" toc="default">
        <name>Minimal Security Requirements for Communication</name>
        <t>This section summarizes the minimal requirements for the
	communication security of the different protocol interactions.
        </t>
        <dl newline="true" spacing="normal">
          <dt>C-AS</dt>
          <dd>All communication between the client and the
	  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
	  swaps the intended response for an older one valid for a previous
	  request.  This requires that the client and the authorization server
	  have previously exchanged either a shared secret or their public
	  keys in order to negotiate a secure communication. Furthermore, the
	  client <bcp14>MUST</bcp14> be able to determine whether an AS has the authority
	  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.
	  </dd>
          <dt>RS-AS</dt>
          <dd>The communication between the resource
	  server and the authorization server via the introspection endpoint
	  <bcp14>MUST</bcp14> be encrypted and integrity and replay protected. Furthermore,
	  responses from the AS to the RS <bcp14>MUST</bcp14> be bound to the RS's request.
	  This requires that the RS and the authorization server
	  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 authority
	  to issue access tokens itself.  This is usually configured out of
	  band but could also be performed through an online lookup mechanism,
	  provided that it is also secured in the same way.</dd>
          <dt>C-RS</dt>
          <dd>The initial communication between the client
	  and the resource server cannot be secured in general, since
	  the RS is not in possession of on access token for that client,
	  which would carry the necessary parameters.  If both parties
	  support DTLS without client authentication, it is <bcp14>RECOMMENDED</bcp14> to use
	  this mechanism for protecting the initial communication.
	  After the client has successfully transmitted the access token to the
	  RS, a secure communication protocol <bcp14>MUST</bcp14> be established between the
	  client and RS for the actual resource request.  This protocol <bcp14>MUST</bcp14>
	  provide confidentiality, integrity, and replay protection, as well as a
	  binding between requests and responses.  This requires that the
	  client learned either the RS's public key or received a symmetric
	  proof-of-possession key bound to the access token from the AS.
	  The RS must have learned either the client's public key, a shared
	  symmetric key from the claims in the token, or an introspection
	  request.  Since ACE does not provide profile negotiation between the
	  C and RS, the client <bcp14>MUST</bcp14> have learned what profile the RS
	  supports (e.g., from the AS or preconfigured) and initiated the
	  communication accordingly.</dd>
        </dl>
      </section>
      <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
	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
	mechanism (<tt>cnonce</tt>) defined in <xref target="asInfo" format="default"/> to ensure
	freshness of an	Access Token subsequently presented to this RS.</t>
        <t>Another problem with clock drift is that evaluating the
	standard token expiration claim <tt>exp</tt> can give unpredictable results.
        </t>
        <t>Acceptable ranges of clock drift are highly dependent on the
	concrete application.  Important factors are how long access tokens
	are valid and how critical timely expiration of the access token is.</t>
        <t>The expiration mechanism implemented by the <tt>exi</tt> claim, based on
	the first time the RS sees the token, was defined to provide a more
	predictable alternative.  The <tt>exi</tt> approach has some drawbacks that
	need to be considered:
        </t>
        <ul spacing="normal">
          <li>A malicious client may hold back tokens with the <tt>exi</tt> claim in
	  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 <tt>exi</tt> claims of
	  tokens it is storing.</li>
	</ul>
        <t>
	The first drawback is inherent to the deployment scenario and the <tt>exi</tt>
	solution.  It can therefore not be mitigated without requiring the
	RS be online at times.  The second drawback can be mitigated by
	regularly storing the value of <tt>exi</tt> counters to persistent memory.</t>
      </section>
      <section anchor="mixnmatch" numbered="true" toc="default">
        <name>Combining Profiles</name>
        <t>There may be use cases where different transport and security
      protocols are allowed for the different interactions, and, if that is
      not explicitly covered by an existing profile, it corresponds to
      combining profiles into a new one.  For example, a new profile could
      specify that a previously defined MQTT-TLS profile is used between
      the client and the RS in combination with a previously defined
      CoAP-DTLS profile for interactions between the client and the AS. The
      new profile that combines existing profiles <bcp14>MUST</bcp14> specify how the
      existing profiles' security requirements remain satisfied. Therefore, any profile
      <bcp14>MUST</bcp14> clearly specify its security requirements and <bcp14>MUST</bcp14>
      document if its security depends on the combination of various
      protocol interactions.</t>
      </section>
      <section anchor="infoLeak" numbered="true" toc="default">
        <name>Unprotected Information</name>
        <t>Communication with the authz-info endpoint, as well as the
	various error responses defined in this framework, potentially
	includes sending information over an unprotected channel.
	These messages may leak information to an adversary or may be
	manipulated by active attackers to induce incorrect behavior.  For
	example, error responses for requests to the authorization information
	endpoint can reveal information about an otherwise opaque access token
	to an adversary who has intercepted this token.</t>
        <t>As far as error messages are concerned, this framework is written
	under the assumption that, in general, the benefits of detailed error
	messages outweigh the risk due to information leakage. For particular
	use cases where this assessment does not apply, detailed error
	messages can be replaced by more generic ones.</t>
        <t>In some scenarios, it may be possible to protect the
	communication with the authz-info endpoint (e.g., through
	DTLS with only server-side authentication). In cases where
	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
	introspection by the RS.</t>
        <t>If the initial Unauthorized Resource Request message (see <xref target="rreq" format="default"/>) is used, the client <bcp14>MUST</bcp14> make sure that it is
	not sending sensitive content in this request. While GET and DELETE
	requests only reveal the target URI of the resource, POST and PUT
	requests would reveal the whole payload of the intended operation.</t>
        <t>Since the client is not authenticated at the point when
	it is submitting an access token to the authz-info endpoint,
	attackers may be pretending to be a client and trying to trick
	an RS to use an obsolete profile that in turn specifies a
	vulnerable security mechanism via the authz-info endpoint.  Such an
	attack would require a valid access token containing an <tt>ace_profile</tt>
	claim requesting the use of said obsolete profile.  Resource owners
	should update the configuration of their RSs to prevent them from
	using such obsolete profiles.</t>
      </section>
      <section anchor="audience" numbered="true" toc="default">
        <name>Identifying Audiences</name>
        <t>The <tt>aud</tt> claim, as defined in <xref target="RFC7519" format="default"/>,
	and the equivalent <tt>audience</tt> parameter from
	<xref target="RFC8693" format="default"/> are intentionally vague
	on how to match the audience value to a specific RS.  This is intended
	to allow application-specific semantics to be used.  This section
	attempts to give some general guidance for the use of audiences in
	constrained environments.</t>
        <t>URLs are not a good way of identifying mobile devices that can
	switch networks and thus be associated with new URLs.  If the
	audience represents a single RS and asymmetric keys are used,
	the RS can be uniquely identified by a hash of its public key.
	If this approach is used, it is <bcp14>RECOMMENDED</bcp14> to apply the
	procedure from <xref target="RFC6920" sectionFormat="of" section="3"/>.</t>
        <t>If the audience addresses a group of resource servers, the mapping
	of a group identifier to an individual RS has to be provisioned to each RS
	before the group-audience is usable.  Managing dynamic groups could be
	an issue if any RS is not always reachable when the groups' memberships
	change. Furthermore, issuing access tokens bound to symmetric
	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
	client towards the other RSs that are part of the group.  It is
	therefore <bcp14>NOT RECOMMENDED</bcp14> to issue access tokens bound
	to a group-audience and symmetric proof-of possession keys.</t>
        <t>Even the client must be able to determine the correct values to put
	into the <tt>audience</tt> parameter in order to obtain a token for the
	intended RS.  Errors in this process can lead to the client
	inadvertently obtaining a token for the wrong RS.  The correct values
	for <tt>audience</tt> can either be provisioned to the client as part of its
	configuration or dynamically looked up by the client in some
	directory. In the latter case, the integrity and	correctness of the
	directory data must be assured.  Note that the <tt>audience</tt> hint
	provided by the RS as part of the AS Request Creation Hints (<xref
	target="asInfo" format="default"/>) is not typically source authenticated and
	integrity protected and should therefore not be treated a trusted value.</t>
      </section>
      <section anchor="introDos" numbered="true" toc="default">
        <name>Denial of Service Against or with Introspection</name>
        <t>
	The optional introspection mechanism provided by OAuth and supported
	in the ACE framework allows for two types of attacks that need
	to be considered by implementers.</t>
        <t>First, an attacker could perform a denial-of-service attack against
	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
	configured to use introspection <bcp14>MUST NOT</bcp14> allow access based on a token
	for which it couldn't reach the introspection endpoint.</t>
        <t>Second, an attacker could use the fact that an RS performs
	introspection to perform a denial-of-service attack against that RS by
	repeatedly sending tokens to its authz-info endpoint that require an
	introspection call. The RS can mitigate such attacks by implementing rate
	limits on how many introspection requests they perform in a given time
	interval for a certain client IP address submitting tokens to
	/authz-info.  When that limit has been reached, incoming requests from
	that address are rejected for a certain	amount of time.  A general rate
	limit on the introspection requests should also be considered in order to
	mitigate distributed attacks.</t>
      </section>
    </section>
    <section anchor="privacy" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>Implementers and users should be aware of the privacy implications
      of the different possible deployments of this framework.</t>
      <t>The AS is in a very central position and can potentially learn sensitive
      information about the clients requesting access tokens.  If the client
      credentials grant is used, the AS can track what kind of access
      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
      grants it issues to anonymous, ephemeral credentials that do not allow
      the AS to link different grants and thus different access token requests
      by the same client.</t>
      <t>The claims contained in a token can reveal privacy-sensitive
      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
      introspection).  The AS <bcp14>SHOULD</bcp14> be configured to minimize the information
      about clients and RSs disclosed in the tokens it issues.</t>
      <t>If tokens are only integrity protected and not encrypted, they
      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,
      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
      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
      not a machine-to-machine interaction).</t>
      <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
      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
      to determine the client's identity.</t>
      <t>An unprotected response to an unauthorized request (see 
      <xref target="asInfo" format="default"/>) may disclose information about the RS
      and/or its
      existing relationship with the C. It is advisable to include as little
      information as possible in an unencrypted response. Even the absolute URI of the AS may reveal sensitive information about the service that the RS provides. Developers must ensure that the RS does not disclose information that has an impact on the privacy of the stakeholders in the AS Request Creation Hints. They may choose to use a different mechanism for the discovery of the AS if necessary. If means of encrypting
      communication between the C and RS already exist, more detailed information
      may be included with an error response to provide the C with sufficient
      information to react on that particular error.</t>
    </section>
    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>

<!--[rfced] May the titles of these subsections be made consistent?
The original is inconsistent about including the word "Registration" or
"Registry" vs. no additional word. Is the following option acceptable
(no additional word)?  (The title of 8.15 was changed to singular because 
it contains one registration.)

Original:
   8.  IANA Considerations
     8.1.  ACE Authorization Server Request Creation Hints
     8.2.  CoRE Resource Type Registry
     8.3.  OAuth Extensions Error Registration
     8.4.  OAuth Error Code CBOR Mappings Registry
     8.5.  OAuth Grant Type CBOR Mappings
     8.6.  OAuth Access Token Types 
     8.7.  OAuth Access Token Type CBOR Mappings
       8.7.1.  Initial Registry Contents
     8.8.  ACE Profile Registry 
     8.9.  OAuth Parameter Registration  
     8.10. OAuth Parameters CBOR Mappings Registry
     8.11. OAuth Introspection Response Parameter Registration
     8.12. OAuth Token Introspection Response CBOR Mappings
            Registry
     8.13. JSON Web Token Claims
     8.14. CBOR Web Token Claims
     8.15. Media Type Registrations
     8.16. CoAP Content-Format Registry

Perhaps:
   8.  IANA Considerations
     8.1.  ACE Authorization Server Request Creation Hints
     8.2.  CoRE Resource Types
     8.3.  OAuth Extensions Errors 
     8.4.  OAuth Error Code CBOR Mappings
     8.5.  OAuth Grant Type CBOR Mappings
     8.6.  OAuth Access Token Types 
     8.7.  OAuth Access Token Type CBOR Mappings
       8.7.1.  Initial Registry Contents
     8.8.  ACE Profiles
     8.9.  OAuth Parameters
     8.10. OAuth Parameters CBOR Mappings 
     8.11. OAuth Introspection Response Parameters
     8.12. OAuth Token Introspection Response CBOR Mappings
     8.13. JSON Web Token Claims
     8.14. CBOR Web Token Claims
     8.15. Media Type Registration
     8.16. CoAP Content-Formats
	 
	 
Ludwig: Acceptable and implemented.
-->

      <t>This document creates several registries with a registration policy of
  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" format="default"/>. 
      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.</dd>
          <dt>Value Type:</dt>
          <dd>The CBOR data types allowable for the values of
      this parameter.</dd>
          <dt>Reference:</dt>
          <dd>This contains a pointer to the public
      specification of the Request Creation Hint abbreviation, if one
      exists.</dd>
        </dl>
	<t>This registry has been initially populated by the values in <xref target="table_asinfo"/>. The Reference column for all of these entries is this document.</t>
      </section>
      <section anchor="IANAcoreRT" numbered="true" toc="default">
        <name>CoRE Resource Types</name>
        <t>IANA has registered a new Resource Type (rt=) Link Target
    Attribute in the "Resource Type (rt=) Link Target Attribute Values"
    subregistry under the "Constrained RESTful Environments (CoRE)
    Parameters" <xref target="IANA.CoreParameters" format="default"/> registry:</t>
        <dl newline="false" spacing="compact">
          <dt>Value:</dt>
	  <dd><tt>ace.ai</tt></dd>
          <dt>Description:</dt>
	  <dd>ACE-OAuth authz-info endpoint resource.</dd>
          <dt>Reference:</dt>
	  <dd>RFC 9200</dd>
        </dl>
        <t>Specific ACE-OAuth profiles can use this common resource type for
   defining their profile-specific discovery processes.</t>
      </section>
      <section anchor="IANAOAuthErrorCodes" numbered="true" toc="default">
        <name>OAuth Extensions Errors</name>
        <t>This specification registers the following error values in the OAuth
    Extensions Error registry
    <xref target="IANA.OAuthExtensionsErrorRegistry" format="default"/>.</t>
        <dl newline="false" spacing="compact">
          <dt>Error name:</dt>
	  <dd><tt>unsupported_pop_key</tt></dd>
          <dt>Error usage location:</dt>
	  <dd>token error response</dd>
          <dt>Related protocol extension:</dt>
	  <dd>RFC 9200</dd>
          <dt>Change Controller:</dt>
	  <dd>IETF</dd>
          <dt>Specification document(s):</dt>
	  <dd><xref target="errorsToken" format="default"/> of RFC 9200</dd>
        </dl>
        <dl newline="false" spacing="compact">
          <dt>Error name:</dt>
	  <dd><tt>incompatible_ace_profiles</tt></dd>
          <dt>Error usage location:</dt>
	  <dd>token error response</dd>
          <dt>Related protocol extension:</dt>
	  <dd>RFC 9200</dd>
          <dt>Change Controller:</dt>
	  <dd>IETF</dd>
          <dt>Specification document(s):</dt>
	  <dd><xref target="errorsToken" format="default"/> of RFC 9200</dd>
        </dl>
      </section>
      <section anchor="IANAErrorCBORMappings" numbered="true" toc="default">
        <name>OAuth Error Code CBOR Mappings</name>
        <t>This specification establishes the IANA "OAuth Error Code
    CBOR Mappings" registry.</t>


<!--[rfced] In Sections 8.1, 8.4, 8.5, 8.7, 8.8, 8.10, and 8.12, the original
contained redundant text regarding the registration policies. FYI, the
detailed text regarding the ranges of the registration policies remains,
whereas the preceding sentence ("The registry has been created to use the ...")
has been removed.

Ludwig: Ok.
-->
        <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>

	<t>This registry has been initially populated by the values in <xref target="table_cborErrorCodes"/>. The Reference column for all of these entries is this document.</t>

      </section>
      <section anchor="IANAGrantTypeMappings" numbered="true" toc="default">
        <name>OAuth Grant Type CBOR Mappings</name>
        <t>This specification establishes the IANA "OAuth Grant Type CBOR Mappings"
    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="default"/>.</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>This registry has been initially populated by the values in <xref target="table_grant_types"/>. The Reference column for all of these entries is this document.</t>

      </section>
      <section anchor="IANAOAuthTokenType" numbered="true" toc="default">
        <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><tt>cnf</tt>, <tt>rs_cnf</tt> (see <xref target="RFC8747" sectionFormat="of" section="3.1"/> <xref target="RFC9201"
	  sectionFormat="of" section="3.2"/>).</dd>
          <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="default"/>.</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="default">
          <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 Profiles</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 values use different registration policies <xref
	  target="RFC8126" format="default"/>.  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.</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 Parameters</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</name>
        <t>This specification establishes the IANA "OAuth Parameters CBOR Mappings"
    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., <tt>client_id</tt>.</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="default"/>.</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 has been initially populated by the values in <xref target="table_cborTokenParameters"/>. The Reference column for all of these entries is this document.</t>

      </section>
      <section anchor="IANAOAuthIntrospectionResponseParameterRegistration" numbered="true" toc="default">
        <name>OAuth Introspection Response Parameters</name>
        <t>This specification registers the following parameters in the OAuth
    Token Introspection Response registry <xref target="IANA.TokenIntrospectionResponse" format="default"/>.</t>
        <dl newline="false" spacing="compact">
          <dt>Name:</dt>
	  <dd><tt>ace_profile</tt></dd>
          <dt>Description:</dt>
	  <dd>The ACE profile used between the client and RS.</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">
          <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
	when the RS cannot synchronize its clock with the AS.</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>cti</tt></dd>
	  <dt>Description</dt>
	  <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
	clocks.</dd>
          <dt>Change Controller:</dt>
	  <dd>IETF</dd>
          <dt>Reference:</dt>
	  <dd><xref target="introRes" format="default"/> of RFC 9200</dd>
        </dl>
      </section>
      <section anchor="IANAIntrospectionEndpointCBORMappingsRegistry" numbered="true" toc="default">
        <name>OAuth Token Introspection Response CBOR Mappings</name>
        <t>This specification establishes the IANA "OAuth Token Introspection
    Response CBOR Mappings" 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., <tt>client_id</tt>.</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="default"/>.</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 introspection response parameter abbreviation, if
	  one exists.</dd>
	  <dt>Original Specification</dt>
	  <dd>This contains a pointer to the public
	  specification of the OAuth Token Introspection parameter, if one
	        exists.</dd>
        </dl>
        <t>
	  This registry has been initially populated by the values in <xref           
target="table_cborIntrospectionParameters"/>. The Reference column for all of these entries is this document.</t>

        <t>Note that the mappings of parameters corresponding to claim names
    intentionally coincide with the CWT claim name mappings from <xref target="RFC8392" format="default"/>.</t>
      </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.JsonWebTokenClaims" 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
      when the RS cannot synchronize its clock with the AS.</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>exi</tt></dd>
          <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
      clocks.</dd>
          <dt>Change Controller:</dt>
	  <dd>IETF</dd>
          <dt>Reference:</dt>
	  <dd><xref target="tokenExpiration" format="default"/> of RFC 9200</dd>
        </dl>
      </section>
      <section anchor="IANACWTClaims" numbered="true" toc="default">
        <name>CBOR Web Token Claims</name>
        <t>This specification registers the following new claims in the "CBOR
    Web Token (CWT) Claims" registry <xref target="IANA.CborWebTokenClaims" 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>JWT Claim Name:</dt>
	  <dd><tt>ace_profile</tt></dd>
          <dt>Claim Key:</dt>
	  <dd>38</dd>
          <dt>Claim Value Type(s):</dt>
	  <dd>integer</dd>
          <dt>Change Controller:</dt>
	  <dd>IETF</dd>
          <dt>Specification Document(s):</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>The client-nonce sent to the AS by the RS via the client.</dd>
          <dt>JWT Claim Name:</dt>
	  <dd><tt>cnonce</tt></dd>
          <dt>Claim Key:</dt>
	  <dd>39</dd>
          <dt>Claim Value Type(s):</dt>
	  <dd>byte string</dd>
          <dt>Change Controller:</dt>
	  <dd>IETF</dd>
          <dt>Specification Document(s):</dt>
	  <dd><xref target="accessToken" format="default"/> of RFC 9200</dd>
        </dl>
        <dl newline="false" spacing="compact">
          <dt>Claim Name:</dt>
	  <dd><tt>exi</tt></dd>
          <dt>Claim Description:</dt>
	  <dd>The expiration time of a token measured from when it was received at the RS
	  in seconds.</dd>
          <dt>JWT Claim Name:</dt> 
	  <dd><tt>exi</tt></dd>
          <dt>Claim Key:</dt>
	  <dd>40</dd>
          <dt>Claim Value Type(s):</dt>
	  <dd>unsigned integer</dd>
          <dt>Change Controller:</dt>
	  <dd>IETF</dd>
          <dt>Specification Document(s):</dt>
	  <dd><xref target="tokenExpiration" format="default"/> of RFC 9200</dd>
        </dl>
        <dl newline="false" spacing="compact">
          <dt>Claim Name:</dt>
	  <dd><tt>scope</tt></dd>
          <dt>Claim Description:</dt>
	  <dd>The scope of an access token, as defined in <xref target="RFC6749"
	  format="default"/>.</dd>
          <dt>JWT Claim Name:</dt>
	  <dd><tt>scope</tt></dd>
          <dt>Claim Key:</dt>
	  <dd>9</dd>
          <dt>Claim Value Type(s):</dt>
	  <dd>byte string or text string</dd>
          <dt>Change Controller:</dt>
	  <dd>IETF</dd>
          <dt>Specification Document(s):</dt>
	  <dd><xref target="RFC8693" sectionFormat="of" section="4.2"/></dd>
        </dl>
      </section>
      <section anchor="IANAmediaType" numbered="true" toc="default">
        <name>Media Type Registration</name>
        <t>This specification registers the "application/ace+cbor" media type for
    messages of the protocols defined in this document carrying parameters
    encoded in CBOR.  This registration follows the procedures specified in
    <xref target="RFC6838" format="default"/>.</t>
    <dl newline="false">
        <dt>Type name:</dt> 
	<dd>application</dd>
        <dt>Subtype name:</dt>
	<dd>ace+cbor</dd>
        <dt>Required parameters:</dt>
	<dd>N/A</dd>
        <dt>Optional parameters:</dt>
	<dd>N/A</dd>
        <dt>Encoding considerations:</dt>
	<dd>Must be encoded as a CBOR map containing
	the protocol parameters defined in RFC 9200.</dd>
        <dt>Security considerations:</dt>
	<dd>See <xref target="security" format="default"/> of RFC 9200</dd>
        <dt>Interoperability considerations:</dt>
	<dd>N/A</dd>
        <dt>Published specification:</dt>
	<dd>RFC 9200</dd>
        <dt>Applications that use this media type:</dt>
	<dd>The type is used by
	authorization servers, clients, and resource servers that support the ACE
	framework with CBOR encoding, as specified in RFC 9200.</dd>
        <dt>Fragment identifier considerations:</dt>
	<dd>N/A</dd>
        <dt>Additional information:</dt> 
	<dd>N/A</dd>
        <dt>Person &amp; email address to contact for further information:</dt>
	<dd>IESG &lt;iesg@ietf.org&gt;</dd>
        <dt>Intended usage:</dt>
	<dd>COMMON</dd>
        <dt>Restrictions on usage:</dt>
	<dd>none</dd>
        <dt>Author:</dt>
	<dd>Ludwig Seitz &lt;ludwig.seitz@combitech.se&gt;</dd>
        <dt>Change controller:</dt>
	<dd>IETF</dd>
    </dl>
      </section>
      <section anchor="IANAcoapContentFormat" numbered="true" toc="default">
        <name>CoAP Content-Formats</name>
        <t>The following entry has been registered in the "CoAP
    Content-Formats" registry:</t>
    <dl newline="false" spacing="compact">
        <dt>Media Type:</dt>
	<dd>application/ace+cbor</dd>
        <dt>Encoding:</dt>
	<dd>-</dd>
        <dt>ID:</dt>
	<dd>19</dd>
        <dt>Reference:</dt>
	<dd>RFC 9200</dd>
    </dl>
      </section>
      <section anchor="IANAinstructions" numbered="true" toc="default">
        <name>Expert Review Instructions</name>
        <t>All of the IANA registries established in this document are defined
   to use a registration policy of Expert Review.  This section gives some general guidelines for
   what the experts should be looking for, but they are being designated
   as experts for a reason, so they should be given substantial
    latitude.</t>
        <t>Expert Reviewers should take into consideration the following points:
        </t>
        <ul spacing="normal">
          <li>Point squatting should be discouraged.  Reviewers are encouraged
      to get sufficient information for registration requests to ensure
      that the usage is not going to duplicate one that is already
      registered and that the point is likely to be used in deployments.  The
      zones tagged as Private Use are intended for testing purposes and closed
      environments; code points in other ranges should not be assigned for
      testing.</li>
          <li>Specifications are needed for the first-come, first-serve range if
      they are expected to be used outside of closed environments in an
      interoperable way.  When specifications are not provided, the description
      provided needs to have sufficient information to identify what the point
      is being used for.</li>
          <li>Experts should take into account the expected usage of fields when
      approving point assignment.  The fact that there is a range for
      Standards Track documents does not mean that a Standards Track
      document cannot have points assigned outside of that range.  The
      length of the encoded value should be weighed against how many
      code points of that length are left, i.e., the size of device it will be
      used on.</li>
          <li>Since a high degree of overlap is expected between these registries
      and the contents of the OAuth parameters <xref target="IANA.OAuthParameters" format="default"/> registries, experts should require new
      registrations to maintain alignment with parameters from OAuth that have
      comparable functionality.  Deviation from this alignment should only
      be allowed if there are functional differences that are motivated by
      the use case and that cannot be easily or efficiently addressed by
      comparable OAuth parameters.</li>
        </ul>
      </section>
    </section>
    <!-- IANA considerations -->

    <!-- Possibly a 'Contributors' section ... -->
  </middle>
  <!--  *****BACK MATTER ***** -->

  <back>

<displayreference target="I-D.erdtman-oauth-rpcc" to="OAUTH-RPCC"/>
<displayreference target="I-D.gerdes-ace-dcaf-authorize" to="DCAF"/>
<displayreference target="I-D.ietf-oauth-pop-key-distribution" to="POP-KEY-DIST"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6920.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7662.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8152.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8392.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8693.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8747.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>

<!-- [I-D.ietf-ace-oauth-params] companion document RFC 9201 -->

<reference anchor='RFC9201' target="https://www.rfc-editor.org/info/rfc9201">
<front>
<title>Additional OAuth Parameters for Authentication and Authorization in Constrained Environments (ACE)</title>
<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
<organization />
</author>
<date year='2022' month='March'/>
</front>
<seriesInfo name="RFC" value="9201"/>
<seriesInfo name="DOI" value="10.17487/RFC9201"/>
</reference>

        <reference anchor="IANA.OAuthAccessTokenTypes" target="https://www.iana.org/assignments/oauth-parameters">
          <front>
            <title>OAuth Access Token Types</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>

        <reference anchor="IANA.OAuthParameters" target="https://www.iana.org/assignments/oauth-parameters">
          <front>
            <title>OAuth Parameters</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>

        <reference anchor="IANA.TokenIntrospectionResponse" target="https://www.iana.org/assignments/oauth-parameters">
          <front>
            <title>OAuth Token Introspection Response</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>

        <reference anchor="IANA.JsonWebTokenClaims" target="https://www.iana.org/assignments/jwt">
          <front>
            <title>JSON Web Token Claims</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>

        <reference anchor="IANA.CborWebTokenClaims" target="https://www.iana.org/assignments/cwt">
          <front>
            <title>CBOR Web Token (CWT) Claims</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>

        <reference anchor="IANA.OAuthExtensionsErrorRegistry" target="https://www.iana.org/assignments/oauth-parameters">
          <front>
            <title>OAuth Extensions Errors</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>

        <reference anchor="IANA.CoreParameters" target="https://www.iana.org/assignments/core-parameters">
          <front>
            <title>Constrained RESTful Environments (CoRE) Parameters</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
	<xi:include                                                                 
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
      </references>

      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6690.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6819.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7009.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7521.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7540.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7591.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7641.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7744.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7959.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8252.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8414.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8516.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8628.xml"/>

<!-- [I-D.ietf-tls-dtls13] in AUTH48*R as RFC-to-be 9147 -->

<reference anchor='RFC9147' target='https://www.rfc-editor.org/info/rfc9147'>
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
<organization />
</author>
<author initials='N' surname='Modadugu' fullname='Nagendra Modadugu'>
<organization />
</author>
    <date year="2022" month="March" /><!-- TBD -->
</front>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference>

<!-- [I-D.erdtman-ace-rpcc] Replaced by draft-erdtman-oauth-rpcc [I-D.erdtman-oauth-rpcc]; IESG state Expired  -->

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.erdtman-oauth-rpcc-00.xml"/>

<!-- [I-D.ietf-quic-transport] Published as RFC 9000 -->

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>

<!-- [I-D.ietf-ace-oscore-profile] - companion document RFC 9203 -->
<reference anchor='RFC9203' target='https://www.rfc-editor.org/info/rfc9203'>
<front>
<title>The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework</title>
<author initials='F' surname='Palombini' fullname='Francesca Palombini'>
<organization />
</author>
<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
<organization />
</author>
<author initials='G' surname='Selander' fullname='Goeran Selander'>
<organization />
</author>
<author initials='M' surname='Gunnarsson' fullname='Martin Gunnarsson'>
<organization />
</author>
    <date year="2022" month="March" />
</front>
<seriesInfo name="RFC" value="9203"/>
<seriesInfo name="DOI" value="10.17487/RFC9203"/>
</reference>

<!-- [I-D.ietf-ace-dtls-authorize] - companion document RFC 9202 -->

<reference anchor='RFC9202' target='https://www.rfc-editor.org/info/rfc9202'>
<front>
<title>Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)</title>
<author initials='S' surname='Gerdes' fullname='Stefanie Gerdes'>
<organization />
</author>
<author initials='O' surname='Bergmann' fullname='Olaf Bergmann'>
<organization />
</author>
<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<author initials='G' surname='Selander' fullname='Goeran Selander'>
<organization />
</author>
<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
<organization />
</author>
    <date year="2022" month="March" />
</front>
<seriesInfo name="RFC" value="9202"/>
<seriesInfo name="DOI" value="10.17487/RFC9202"/>
</reference>

<!--[rfced] FYI, we have added the following documents to the 
Informative References, as they appear in the Acknowledgments. Please 
let us know if you prefer otherwise.

   [DCAF]     Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP
              Authentication and Authorization Framework (DCAF)", Work
              in Progress, Internet-Draft, draft-gerdes-ace-dcaf-
              authorize-04, 19 October 2015,
              <https://datatracker.ietf.org/doc/html/draft-gerdes-ace-
              dcaf-authorize-04>.

   [POP-KEY-DIST]
              Bradley, J., Hunt, P., Jones, M. B., Tschofenig, H., and
              M. Meszaros, "OAuth 2.0 Proof-of-Possession: Authorization
              Server to Client Key Distribution", Work in Progress,
              Internet-Draft, draft-ietf-oauth-pop-key-distribution-07,
              27 March 2019, <https://datatracker.ietf.org/doc/html/
              draft-ietf-oauth-pop-key-distribution-07>.
Ludwig: Ok
-->

<!-- [I-D.ietf-oauth-pop-key-distribution] IESG state Expired
-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-oauth-pop-key-distribution-07.xml"/>

<!-- [I-D.gerdes-ace-dcaf-authorize] IESG state Expired
-->
<xi:include
href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.gerdes-ace-dcaf-authorize-04.xml"/>

        <reference anchor="Margi10impact">
          <front>
            <title>Impact of Operating Systems on Wireless Sensor Networks
	  (Security) Applications and Testbeds</title>
            <author initials="C." surname="Margi"/>
            <author initials="B." surname="de Oliveira"/>
            <author initials="G." surname="de Sousa"/>
            <author initials="M." surname="Simplicio Jr"/>
            <author initials="P." surname="Barreto"/>
            <author initials="T." surname="Carvalho"/>
            <author initials="M." surname="Naeslund"/>
            <author initials="R." surname="Gold"/>
            <date year="2010" month="August"/>
          </front>
	  <seriesInfo name="DOI" value="10.1109/ICCCN.2010.5560028"/>
          <refcontent>Proceedings of the 19th International Conference on Computer
	  Communications and Networks</refcontent>
        </reference>

        <reference anchor="MQTT5.0" target="https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html">
          <front>
            <title>MQTT Version 5.0</title>
            <author initials="A." surname="Banks"/>
            <author initials="E." surname="Briggs"/>
            <author initials="K." surname="Borgendale"/>
            <author initials="R." surname="Gupta"/>
            <date year="2019" month="March"/>
          </front>
          <refcontent>OASIS Standard</refcontent>
        </reference>

        <reference anchor="BLE" target="https://www.bluetooth.com/specifications/bluetooth-core-specification/">
          <front>
            <title>Core Specification 5.3</title>
            <author>
	      <organization>Bluetooth Special Interest Group</organization>
	    </author>
            <date year="2021" month="July"/>
          </front>
          <seriesInfo name="Section" value="4.4"/>
        </reference>
      </references>
    </references>
    <section anchor="constraints" numbered="true" toc="default">
      <name>Design Justification</name>
      <t>This section provides further insight into the design decisions
     of the solution documented in this document.  <xref target="overview" format="default"/>
     lists several building blocks and briefly summarizes their importance.
     The justification for offering some of those building blocks, as opposed
     to using OAuth 2.0 as is, is given below.</t>
      <t>Common IoT constraints are:

      </t>
      <dl newline="true" spacing="normal">
        <dt>Low Power Radio:</dt>
        <dd>
          Many IoT devices are equipped with a small battery that needs
          to last for a long time.  For many constrained wireless devices, the
          highest energy cost is associated to transmitting or receiving
          messages (roughly by a factor of 10 compared to AES)
	  <xref target="Margi10impact" format="default"/>.  It is therefore important
	  to keep
	  the total communication overhead low, including minimizing the number
	  and size of messages sent and received, which has an impact of choice
	  on the message format and protocol.  By using CoAP over UDP and 
	  CBOR-encoded messages, some of these aspects are addressed.  Security
	  protocols contribute to the communication overhead and can, in some
	  cases, be optimized.  For example, authentication and key
	  establishment may, in certain cases where security requirements
	  allow, be replaced by the provisioning of security context by a trusted
	  third party, using transport or application-layer security.
        </dd>
        <dt>Low CPU Speed:</dt>
        <dd>
          Some IoT devices are equipped with processors that are significantly
          slower than those found in most current devices on the Internet.
          This typically has implications on what timely cryptographic
          operations a device is capable of performing, which in turn impacts,
          e.g., protocol latency.  Symmetric key cryptography may be used
          instead of the computationally more expensive public key cryptography
          where the security requirements so allow, but this may also require
          support for trusted, third-party-assisted secret key establishment
          using transport- or application-layer security.
        </dd>
        <dt>Small Amount of Memory:</dt>
        <dd>
          Microcontrollers embedded in IoT devices are often equipped with
          only a small amount of RAM and flash memory, which places limitations on what
          kind of processing can be performed and how much code can be put on
          those devices.  To reduce code size, fewer and smaller protocol
          implementations can be put on the firmware of such a device.  In
          this case, CoAP may be used instead of HTTP,  symmetric-key
          cryptography may be used instead of public-key cryptography, and CBOR may be used
	  instead of
          JSON.  An authentication and key establishment protocol, e.g., the DTLS
          handshake,  in comparison with assisted key establishment, also have
          an impact on memory and code footprints.
        </dd>
        <dt>User Interface Limitations:</dt>
        <dd>
          Protecting access to resources is both an important security as well
          as privacy feature.  End users and enterprise customers may not want
          to give access to the data collected by their IoT device or to
          functions it may offer to third parties.  Since the classical
          approach of requesting permissions from end users via a rich user
          interface does not work in many IoT deployment scenarios, these
          functions need to be delegated to user-controlled devices that are
          better suitable for such tasks, such as smartphones and tablets.
        </dd>
        <dt>Communication Constraints:</dt>
        <dd>
          <t>
          In certain constrained settings, an IoT device may not be able to
          communicate with a given device at all times.  Devices may be
          sleeping or just disconnected from the Internet because of general
          lack of connectivity in the area for cost or security
          reasons, e.g., to avoid an entry point for denial-of-service attacks.
          </t>
          <t>
          The communication interactions this framework builds upon (as shown
          graphically in <xref target="fig_protocolFlow" format="default"/>) may be
	  accomplished
          using a variety of different protocols, and not all parts of the
          message flow are used in all applications due to the communication
          constraints.  Deployments making use of CoAP are expected, but this
	  framework is not
          limited to them.  Other protocols, such as HTTP or
          Bluetooth Smart communication, that do not
          necessarily use IP could also be used.  The latter raises the need
          for application-layer security over the various interfaces.</t>
        </dd>
      </dl>
      <t>In the light of these constraints, we have made the following design
      decisions:</t>
      <dl newline="true" spacing="normal">
        <dt>CBOR, COSE, CWT:</dt>
        <dd>
	  When using this framework, it is <bcp14>RECOMMENDED</bcp14> to use CBOR 
	  <xref target="RFC8949" format="default"/> as the data format.  Where CBOR data
	  needs to be
	  protected, the use of COSE <xref target="RFC8152" format="default"/> is
	  <bcp14>RECOMMENDED</bcp14>. 
	  Furthermore, where self-contained tokens are needed, it is
	  <bcp14>RECOMMENDED</bcp14>
	  to use CWT <xref target="RFC8392" format="default"/>.  These measures aim
	  at reducing
	  the size of messages sent over the wire, the RAM size of data objects
	  that need to be kept in memory, and the size of libraries that devices
	  need to support.
       </dd>
        <dt>CoAP:</dt>
        <dd>
	  When using this framework, it is <bcp14>RECOMMENDED</bcp14> to use CoAP 
	  <xref target="RFC7252" format="default"/> instead of HTTP.  This does not
	  preclude the
	  use of other protocols specifically aimed at constrained devices,
	  e.g., Bluetooth Low Energy (see <xref target="coap" format="default"/>). 
	  This aims
	  again at reducing the size of messages sent over the wire, the RAM size
	  of data objects that need to be kept in memory, and the size of 
	  libraries that devices need to support.
        </dd>
        <dt>Access Information:</dt>
        <dd>
	  This framework defines the name "Access Information" for data
	  concerning the RS that the AS returns to the client in an access
	  token response (see  <xref target="tokenResponse" format="default"/>).  This
	  aims at
	  enabling scenarios where a powerful client supporting multiple
	  profiles needs to interact with an RS for which it does not know the
	  supported profiles and the raw public key.
        </dd>
        <dt>Proof of Possession:</dt>
        <dd>
	  This framework makes use of proof-of-possession tokens, using
	  the <tt>cnf</tt> claim <xref target="RFC8747" format="default"/>.  A request
	  parameter <tt>cnf</tt> and a Response parameter <tt>cnf</tt>, both having a
	  value space semantically and syntactically identical to the <tt>cnf</tt>
	  claim, are defined for the token endpoint to allow requesting and
	  stating confirmation keys.  This aims at making token theft harder.
	  Token theft is specifically relevant in constrained use cases, as
	  communication often passes through middleboxes, which could be able
	  to steal bearer tokens and use them to gain unauthorized access.
        </dd>
        <dt>Authz-Info endpoint:</dt>
        <dd>
	  This framework introduces a new way of providing access tokens
	  to an RS by exposing an authz-info endpoint to which access tokens
	  can be POSTed.  This aims at reducing the size of the request
	  message and the code complexity at the RS.  The size of the request
	  message is problematic, since many constrained protocols have severe
	  message size limitations at the physical layer (e.g., in the order of
	  100 bytes). This means that larger packets get fragmented, which in
	  turn combines badly with the high rate of packet loss and the
	  need to retransmit the whole message if one packet gets lost.
	  Thus, separating sending of the request and sending of the access
	  tokens helps to reduce fragmentation.
        </dd>
        <dt>Client Credentials Grant:</dt>
        <dd>
	  In this framework, the use of the client credentials grant is
	  <bcp14>RECOMMENDED</bcp14> for machine-to-machine communication use cases,
	  where 
	  manual intervention of the resource owner to produce a grant token is
	  not feasible.  The intention is that the resource owner would instead
	  prearrange authorization with the AS based on the client's own
	  credentials.  The client can then (without manual intervention) obtain
	  access tokens from the AS.
        </dd>
        <dt>Introspection:</dt>
        <dd>
	  In this framework, the use of access token introspection is
	  <bcp14>RECOMMENDED</bcp14>
	  in cases where the client is constrained in a way that it cannot
	  easily obtain new access tokens (i.e., it has connectivity issues
	  that prevent it from communicating with the AS). In that case,
	  it is <bcp14>RECOMMENDED</bcp14> to use a long-term token that could be a
	  simple reference.  The RS is assumed to be able to communicate
	  with the AS and can therefore perform introspection in order to
	  learn the claims associated with the token reference.  The advantage
	  of such an approach is that the resource owner can change the claims
	  associated to the token reference without having to be in contact
	  with the client, thus granting or revoking access rights.
        </dd>
      </dl>
    </section>
    <section anchor="app_rolesAndResponsibilities" numbered="true" toc="default">
      <name>Roles and Responsibilities</name>
      <dl newline="true" spacing="normal">
        <dt>Resource Owner</dt>
        <dd>
          <ul spacing="normal">
            <li>Make sure that the RS is registered at the AS.  This includes
	    making known to the AS which profiles, token_type, scopes, and
	    key types (symmetric/asymmetric) the RS supports. Also making
	    it known to the AS which audience(s) the RS identifies itself
	    with.</li>
            <li>Make sure that clients can discover the AS that is in charge
	    of the RS.</li>
            <li>If the client-credentials grant is used, make sure that the AS
	    has the necessary, up-to-date access control policies for the
	    RS.</li>
          </ul>
        </dd>
        <dt>Requesting Party</dt>
        <dd>
          <ul spacing="normal">
            <li>Make sure that the client is provisioned the necessary
	    credentials to authenticate to the AS.</li>
            <li>Make sure that the client is configured to follow the security
	    requirements of the requesting party when issuing requests
	    (e.g., minimum communication security requirements or trust
	    anchors).</li>
            <li>Register the client at the AS.  This includes making known to
	    the AS which profiles, token_types, and key types
	    (symmetric/asymmetric) for the client.</li>
          </ul>
        </dd>
        <dt>Authorization Server</dt>
        <dd>
          <ul spacing="normal">
            <li>Register the RS and manage corresponding security contexts.</li>
            <li>Register clients and authentication credentials.</li>
            <li>Allow resource owners to configure and update access control
	    policies related to their registered RSs.</li>
            <li>Expose the token endpoint to allow  clients to request
	    tokens.</li>
            <li>Authenticate clients that wish to request a token.</li>
            <li>Process a token request using the authorization
	    policies configured for the RS.</li>
            <li>Optionally, expose the introspection endpoint that allows
	    RSs to submit token introspection requests.</li>
            <li>If providing an introspection endpoint, authenticate RSs that
	    wish to get an introspection response.</li>
            <li>If providing an introspection endpoint, process token
	    introspection requests.</li>
            <li>Optionally, handle token revocation.</li>
            <li>Optionally, provide discovery metadata. See <xref target="RFC8414" format="default"/>.</li>
            <li>Optionally, handle refresh tokens.</li>
          </ul>
        </dd>
        <dt>Client</dt>
        <dd>
          <ul spacing="normal">
            <li>Discover the AS in charge of the RS that is to be targeted with
	    a request.</li>
            <li>
              <t>Submit the token request (see step (A) of
	    <xref target="fig_protocolFlow" format="default"/>).
              </t>
              <ul spacing="normal">
                <li>Authenticate to the AS.</li>
                <li>Optionally (if not preconfigured), specify which RS, which
		resource(s), and which action(s) the request(s) will
		target.</li>
                <li>If raw public keys (RPKs) or certificates are used, make sure
		the AS has the right RPK or certificate for this client.</li>
              </ul>
            </li>
            <li>
              <t>Process the access token and Access Information (see step (B)
	    of <xref target="fig_protocolFlow" format="default"/>).
              </t>
              <ul spacing="normal">
                <li>Check that the Access Information provides the necessary
		security parameters (e.g., PoP key or information on
		communication security protocols supported by the RS).</li>
                <li>Safely store the proof-of-possession key.</li>
                <li>If provided by the AS, safely store the refresh token.</li>
              </ul>
            </li>
            <li>
              <t>Send the token and request to the RS (see step (C) of
	    <xref target="fig_protocolFlow" format="default"/>).
              </t>
              <ul spacing="normal">
                <li>Authenticate towards the RS (this could coincide with the
		proof-of-possession process).</li>
                <li>Transmit the token as specified by the AS (default is to the
		authz-info endpoint; alternative options are specified by
		profiles).</li>
                <li>Perform the proof-of-possession procedure as specified by
		the profile in use (this may already have been taken care
		of through the authentication procedure).</li>
              </ul>
            </li>
            <li>Process the RS response (see step (F) of
	    <xref target="fig_protocolFlow" format="default"/>) of the RS.</li>
          </ul>
        </dd>
        <dt>Resource Server</dt>
        <dd>
          <ul spacing="normal">
            <li>Expose a way to submit access tokens. By default, this is
	    the authz-info endpoint.</li>
            <li>
              <t>Process an access token.
              </t>
              <ul spacing="normal">
                <li>Verify the token is from a recognized AS.</li>
                <li>Check the token's integrity.</li>
                <li>Verify that the token applies to this RS.</li>
                <li>Check that the token has not expired (if the token provides
		expiration information).</li>
                <li>Store the token so that it can be retrieved in the context
		of a matching request.</li>
              </ul>
              <t>
	      Note: The order proposed here is not normative; any process
	      that arrives at an equivalent result can be used.  A noteworthy
	      consideration is whether one can use cheap operations early on to
	      quickly discard nonapplicable or invalid tokens before
	      performing expensive cryptographic operations (e.g., doing an
	      expiration check before verifying a signature).
              </t>
            </li>
            <li>
              <t>Process a request.
              </t>
              <ul spacing="normal">
                <li>Set up communication security with the client.</li>
                <li>Authenticate the client.</li>
                <li>Match the client against existing tokens.</li>
                <li>Check that tokens belonging to the client actually
		authorize the requested action.</li>
                <li>Optionally, check that the matching tokens are still valid,
		using introspection (if this is possible.)</li>
              </ul>
            </li>
            <li>Send a response following the agreed upon communication
	    security mechanism(s).</li>
            <li>Safely store credentials, such as raw public keys, for
	    authentication or proof-of-possession keys linked to access
	    tokens.</li>
          </ul>
        </dd>
      </dl>
    </section>
    <!-- ***************************************************** -->
<section anchor="app_profileRequirements" numbered="true" toc="default">
      <name>Requirements on Profiles</name>
      <t>This section lists the requirements on profiles of this framework
      for the convenience of profile designers.</t>
      <ul spacing="normal">
        <li>Optionally, define new methods for the client to discover the
	necessary permissions and AS for accessing a resource different from
	the one proposed in Sections <xref target="asDiscovery" format="counter"/> and <xref
	target="specs" format="counter"/></li>
        <li>Optionally, specify new grant types
	(<xref target="authorizationGrants" format="default"/>).</li>
        <li>Optionally, define the use of client certificates as client credential
	type (<xref target="clientCredentials" format="default"/>).</li>
        <li>Specify the communication protocol the client and RS must use
	(e.g., CoAP) (Sections <xref target="oauthProfile" format="counter"/> and <xref
	target="paramProfile" format="counter"/>).</li>
        <li>Specify the security protocol the client and RS must use to protect
	their communication (e.g., OSCORE or DTLS).  This must provide
	encryption and integrity and replay protection (<xref target="paramProfile"
	format="default"/>).</li>
        <li>Specify how the client and the RS mutually authenticate (<xref target="specs"
	format="default"/>).</li>
        <li>Specify the proof-of-possession protocol(s) and how to select one
	if several are available.  Also specify which key types
	(e.g., symmetric/asymmetric) are supported by a specific proof-of-possession
	protocol (<xref target="paramTokenType" format="default"/>).</li>
        <li>Specify a unique <tt>ace_profile</tt> identifier (<xref target="paramProfile"
	format="default"/>).</li>
        <li>If introspection is supported, specify the communication and security
	protocol for introspection (<xref target="introspectionEndpoint"
	format="default"/>).</li>
        <li>Specify the communication and security protocol for interactions between
	the client and AS. This must provide encryption, integrity protection,
	replay protection,  and a binding between requests and responses (Sections <xref
	target="oauthProfile" format="counter"/> and <xref target="tokenEndpoint"
	format="counter"/>).</li>
        <li>Specify how/if the authz-info endpoint is protected, including
	how error responses are protected (<xref target="tokenAuthInfoEndpoint"
	format="default"/>).</li>
        <li>Optionally, define other methods of token transport than the authz-info
	endpoint (<xref target="tokenAuthInfoEndpoint" format="default"/>).</li>
      </ul>
    </section>
    <section anchor="app_registration" numbered="true" toc="default">
      <name>Assumptions on AS Knowledge about the C and RS</name>
      <t>This section lists the assumptions on what an AS should know about a
 client and an RS in order to be able to respond to requests to the token
 and introspection endpoints.  How this information is established is out of
 scope for this document.

      </t>
      <ul spacing="normal">
        <li>The identifier of the client or RS.</li>
        <li>The profiles that the client or RS supports.</li>
        <li>The scopes that the RS supports.</li>
        <li>The audiences that the RS identifies with.</li>
        <li>The key types (e.g., pre-shared symmetric key, raw public key,
	key length, and other key parameters) that the client or RS supports.</li>
        <li>The types of access tokens the RS supports (e.g., CWT).</li>
        <li>If the RS supports CWTs, the COSE parameters for the crypto wrapper
	(e.g., algorithm, key-wrap algorithm, and key-length) that the RS supports.</li>
        <li>The expiration time for access tokens issued to this RS
	(unless the RS accepts a default time chosen by the AS).</li>
        <li>The symmetric key shared between the client and AS (if any).</li>
        <li>The symmetric key shared between the RS and AS (if any).</li>
        <li>The raw public key of the client or RS (if any).</li>
        <li>Whether the RS has synchronized time (and thus is able to use the <tt>exp</tt>
	claim) or not.</li>
      </ul>
    </section>
    <section anchor="app_diffOAuth" numbered="true" toc="default">
      <name>Differences to OAuth 2.0</name>
      <t>This document adapts OAuth 2.0 to be suitable for constrained environments.  
      This section lists the main differences from the normative requirements of
      OAuth 2.0.</t>
      <dl newline="true" spacing="normal">
        <dt>Use of TLS</dt>
	<dd>OAuth 2.0 requires the use of TLS to protect the
	communication between the AS and client when requesting an access token,
	between the client and RS when accessing a resource, and between the AS and RS if
	introspection is used.  This framework requires similar security
	properties but does not require that they be realized with TLS.  
	See <xref target="oauthProfile" format="default"/>.</dd>
        <dt>Cardinality of <tt>grant_type</tt> parameter</dt>
	<dd>In client-to-AS requests 
	using OAuth 2.0, the <tt>grant_type</tt> parameter is required (per 
	<xref target="RFC6749" format="default"/>).  In this framework, this parameter
	is optional.  See <xref target="tokenRequest" format="default"/>.</dd>
        <dt>Encoding of <tt>scope</tt> parameter</dt>
	<dd>In client-to-AS requests using OAuth
	2.0, the <tt>scope</tt> parameter is string encoded (per 
	<xref target="RFC6749" format="default"/>).  In this framework, this parameter
	may also be
	encoded as a byte string.  See <xref target="tokenRequest"
	format="default"/>.</dd>
        <dt>Cardinality of <tt>token_type</tt> parameter</dt>
	<dd>In AS-to-client responses
	using OAuth 2.0, the <tt>token_type</tt> parameter is required (per 
	<xref target="RFC6749" format="default"/>).  In this framework, this parameter
	is
	optional.  See <xref target="tokenResponse" format="default"/>.</dd>
        <dt>Access token retention</dt>
	<dd>In OAuth 2.0, the access token may be sent with
	every request to the RS. The exact use of access tokens depends on the
	semantics 
	of the application and the session management concept it uses. In this
	framework, 
	the RS must be able to store these tokens for later use.  See
        <xref target="tokenAuthInfoEndpoint" format="default"/>.</dd>
      </dl>
    </section>
    <!-- ***************************************************** -->
      <section anchor="app_options" numbered="true" toc="default">
      <name>Deployment Examples</name>
      <t>There is a large variety of IoT deployments, as is indicated in
        <xref target="constraints" format="default"/>, and this section highlights a few common
        variants.  This section is not normative but illustrates how the
        framework can be applied.
      </t>
      <t>For each of the deployment variants, there are a number of possible
        security setups between clients, resource servers, and authorization
        servers.  The main focus in the following subsections is on how
        authorization of a client request for a resource hosted by an RS is
        performed.  This requires the security of the requests and
        responses between the clients and the RS to be considered.
      </t>
      <t>Note: CBOR diagnostic notation is used for examples of requests
          and responses.</t>
      <!-- ************************** -->


 <!-- ************************** -->
<section anchor="localTokenValidation" numbered="true" toc="default">
        <name>Local Token Validation</name>
        <t>In this scenario, the case where the resource server is offline is considered,
	i.e., it is not connected to the AS at the time of the access request.
	This access procedure involves steps (A), (B), (C), and (F) of <xref
	target="fig_protocolFlow" format="default"/>.</t>
        <t>Since the resource server must be able to verify the access token locally,
	self-contained access tokens must be used.</t>
        <t>This example shows the interactions between a client, the
	authorization server, and a temperature sensor acting as a resource server.  Message
	exchanges A and B are shown in <xref target="fig_RSOffline" format="default"/>.</t>
        <dl newline="false" spacing="normal" indent="4">
          <dt>A:</dt> 
	  <dd>
	    <t>The client first generates a public-private key pair used for
	    communication security with the RS.</t>
	    <t>The client sends a CoAP POST request to the token endpoint at the AS. 
	    The security
            of this request can be transport or application layer. It is up the
            communication security profile to define. In the example, it is
	    assumed that both the client and AS have performed mutual authentication,
	    e.g., via DTLS.  The request contains the public key of the client and
	    the <tt>audience</tt> parameter set to "tempSensorInLivingRoom", a value that
	    the temperature sensor identifies itself with.  The AS evaluates the
	    request and authorizes the client to access the resource.</t>
            </dd>
          <dt>B:</dt>
	  <dd>
	    <t>The AS responds with a 2.05 (Content) response containing the
	    Access Information, including the access token.
	    The PoP access token contains the public key of the client, and the
	    Access Information  contains the public key of the RS.  For communication
	    security, this example uses DTLS RawPublicKey between the client and the
	    RS. The issued token will have a short validity time, i.e., <tt>exp</tt> close
	    to <tt>iat</tt>, in order to mitigate attacks using stolen client credentials.
	    The token includes claims, such as <tt>scope</tt>, with the authorized access
	    that an owner of the temperature device can enjoy.  In this example, the
	    <tt>scope</tt> claim issued by the AS informs the RS that the owner of the
	    token that can prove the possession of a key is authorized to make a GET
	    request against the /temperature resource and a POST request on the
	    /firmware resource.  Note that the syntax and semantics of the <tt>scope</tt> claim
	    are application specific.</t>
            <t>Note: In this example, it is assumed that the client knows what resource
	    it wants to access and is therefore able to request specific
	    <tt>audience</tt> and <tt>scope</tt> claims for the access token.</t>
	  </dd>
        </dl>

<!--[rfced] Please review this item in Figures 11 and 16.
Should quotation marks be added?

Content-Format: application/ace+cbor
vs.
Content-Format: "application/ace+cbor" (as in Figure 18)

(FYI, the figure numbers are different from the original.)

Ludwig: Added quotation marks.
-->
        <figure anchor="fig_RSOffline">
          <name>Token Request and Response Using Client Credentials</name>
          <artwork align="left" name="" type="" alt=""><![CDATA[
         Authorization
  Client    Server
    |         |
    |<=======>| DTLS Connection Establishment
    |         |   and mutual authentication
    |         |
A:  +-------->| Header: POST (Code=0.02)
    |  POST   | Uri-Path:"token"
    |         | Content-Format: application/ace+cbor
    |         | Payload: <Request-Payload>
    |         |
B:  |<--------+ Header: 2.05 Content
    |  2.05   | Content-Format: application/ace+cbor
    |         | Payload: <Response-Payload>
    |         |
        ]]></artwork>
        </figure>
        <t>The information contained in the Request-Payload and the
    Response-Payload is shown in <xref target="fig_RSOfflineReq" format="default"/>.
    Note that the parameter <tt>rs_cnf</tt> from
    <xref target="RFC9201" format="default"/> is used to inform
    the client about the resource server's public key.

        </t>
        <figure anchor="fig_RSOfflineReq">
          <name>Request and Response Payload Details</name>
          <sourcecode name="" type="cbor-diag"><![CDATA[
Request-Payload :
{
  / audience / 5 : "tempSensorInLivingRoom",
  / client_id / 24 : "myclient",
  / req_cnf / 4 : {
    / COSE_Key / 1 : {
      / kid / 2 : b64'1Bg8vub9tLe1gHMzV76e',
      / kty / 1 : 2 / EC2 /,
      / crv / -1 : 1 / P-256 /,
      / x / -2 : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
      / y / -3 : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
    }
  }
}

Response-Payload :
{
  / access_token / 1 : b64'0INDoQEKoQVNKkXfb7xaWqMT'/ .../,
  / rs_cnf / 41 : {
    / COSE_Key / 1 : {
      / kid / 2 : b64'c29tZSBwdWJsaWMga2V5IGlk',
      / kty / 1 : 2 / EC2 /,
      / crv / -1 : 1 / P-256 /,
      / x / -2   : b64'MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4',
      / y / -3   : b64'4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM'
    }
  }
}
        ]]></sourcecode>
        </figure>
        <t>The content of the access token is shown
    in <xref target="fig_BothcborMappingValueAsymmetricCWT" format="default"/>.</t>
        <figure anchor="fig_BothcborMappingValueAsymmetricCWT">
          <name>Access Token Including Public Key of the Client</name>
          <sourcecode name="" type="cbor-diag"><![CDATA[
{
  / aud / 3 : "tempSensorInLivingRoom",
  / iat / 6 : 1563451500,
  / exp / 4 : 1563453000,
  / scope / 9 :  "temperature_g firmware_p",
  / cnf / 8 : {
    / COSE_Key / 1 : {
      / kid / 2 : b64'1Bg8vub9tLe1gHMzV76e',
      / kty / 1 : 2 / EC2 /,
      / crv / -1 : 1 / P-256 /,
      / x / -2 : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
      / y / -3 : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
    }
  }
}
        ]]></sourcecode>
        </figure>
        <t>Messages C and F are shown in Figures
    <xref target="fig_RSOfflinePostAccessTokenAsymmetric" format="counter"/> and
    <xref target="fig_RSOfflineDTLSRequestAndResponse" format="counter"/>.</t>
        <dl newline="false" spacing="normal" indent="4">
          <dt>C:</dt>
          <dd>
	    The client then sends the PoP access token to the authz-info endpoint at
	    the RS.  This is a plain CoAP POST request, i.e., no transport or
	    application-layer security is used between the client and RS since the token is
	    integrity protected
	    between the AS and RS.  The RS verifies that the PoP access token was
	    created by a
	    known and trusted AS, which it applies to this RS, and that it is valid. 
	    The RS caches
	    the security context together with authorization information about this
	    client contained in the PoP access token.</dd>
	</dl>
            <figure anchor="fig_RSOfflinePostAccessTokenAsymmetric">
              <name>Access Token Provisioning to the RS</name>
              <artwork align="left" name="" type="" alt=""><![CDATA[
           Resource
 Client     Server
    |         |
C:  +-------->| Header: POST (Code=0.02)
    |  POST   | Uri-Path:"authz-info"
    |         | Payload: 0INDoQEKoQVN ...
    |         |
    |<--------+ Header: 2.04 Changed
    |  2.04   |
    |         |
]]></artwork>
            </figure>
          <t>The client and the RS runs the DTLS handshake using the raw
      public keys established in steps B and C.</t>
          <t>The client sends a CoAP GET request to /temperature on the RS over
      DTLS. The RS verifies that the request is authorized based on
      previously established security context.</t>
	  <dl newline="false" spacing="normal" indent="3">
          <dt>F:</dt> 
	  <dd>The RS responds over the same DTLS channel with a CoAP 2.05 Content response
	  containing a resource representation as payload.</dd>
        </dl>
        <figure anchor="fig_RSOfflineDTLSRequestAndResponse">
          <name>Resource Request and Response Protected by DTLS</name>
          <artwork align="left" name="" type="" alt=""><![CDATA[
           Resource
 Client     Server
    |         |
    |<=======>| DTLS Connection Establishment
    |         |   using Raw Public Keys
    |         |
    +-------->| Header: GET (Code=0.01)
    | GET     | Uri-Path: "temperature"
    |         |
    |         |
    |         |
F:  |<--------+ Header: 2.05 Content
    | 2.05    | Payload: <sensor value>
    |         |
      ]]></artwork>
        </figure>
      </section>
      <!-- ************************** -->

<section anchor="introspectionAidedTokenValidation" numbered="true" toc="default">
        <name>Introspection Aided Token Validation</name>
        <t>In this deployment scenario, it is assumed that a client is not able to
  access the AS at the time of the access request, whereas the RS is assumed
  to be connected to the back-end infrastructure. Thus, the RS can make use of
  token introspection.  This access procedure involves steps (A)-(F) of
  <xref target="fig_protocolFlow" format="default"/> but assumes steps (A) and (B) have been
  carried out during a phase when the client had connectivity to the AS.
        </t>
        <t>Since the client is assumed to be offline, at least for a certain period of
  time, a preprovisioned access token has to be long lived.  Since the client
  is constrained, the token will not be self-contained (i.e., not a CWT) but
  instead just a reference.  The resource server uses its connectivity to
  learn about the claims associated to the access token by using introspection,
  which is shown in the example below.</t>
        <t>In the example, interactions between an offline client
    (key fob), an RS (online lock), and an AS is shown.  It is
    assumed that there is a provisioning step where the client has access to the
    AS.  This corresponds to message exchanges A and B, which are shown in
    <xref target="fig_cOffline" format="default"/>.
        </t>
        <t>Authorization consent from the resource owner can be preconfigured,
    but it can also be provided via an interactive flow with the resource
    owner.  An example of this for the key fob case could be that the
    resource owner has a connected car, and buys a generic key to use with the
	car.  To authorize the key fob, the owner connects it to a computer that 
	then provides the UI for the device.  After that, OAuth 2.0 implicit flow
	can be used to authorize the key for the car at the car manufacturers 
	AS.</t>
        <t>Note: In this example, the client does not know the exact door it
    will be used to access since the token request is not sent at the
    time of access. So the <tt>scope</tt> and <tt>audience</tt> parameters are set quite
    wide to start with, while tailored values narrowing down the claims to
    the specific RS being accessed can be provided to that RS during
    an introspection step.</t>
        <dl newline="false" spacing="normal" indent="4">
          <dt>A:</dt>
          <dd>The client sends a CoAP POST request to the token endpoint at the
	AS.  The request contains the <tt>audience</tt> parameter set to  "PACS1337"
	(Physical Access System (PACS)), a value that identifies the
	physical access control system to which the individual doors are
	connected.  The AS generates an access token as	an opaque string, which
	it can match to the specific client and the targeted audience. It
	furthermore generates a symmetric proof-of-possession key. The
	communication security and authentication between the client and AS
	is assumed to have been	provided at the transport layer (e.g., via DTLS)
	  using a pre-shared security context (pre-shared key (PSK), RPK, or
	  certificate).</dd>
          <dt>B:</dt>
          <dd>The AS responds with a CoAP 2.05 Content response, containing as
	payload the Access Information, including the access token and the
	symmetric proof-of-possession key.  Communication security between the C
        and RS will be DTLS and PreSharedKey.  The PoP key is used as the
        PreSharedKey.
        </dd>
        </dl>
        <t>Note: In this example, we are using a symmetric key for a multi-RS
	audience, which is not recommended normally (see <xref target="audience"
	format="default"/>).
	However, in this case, the risk is deemed to be acceptable, since
	all the doors are part of the same physical access control system;
	therefore, the risk of a malicious RS impersonating the client towards
	another RS is low.</t>
        <figure anchor="fig_cOffline">
          <name>Token Request and Response Using Client Credentials</name>
          <artwork align="left" name="" type="" alt=""><![CDATA[
         Authorization
 Client     Server
    |         |
    |<=======>| DTLS Connection Establishment
    |         |   and mutual authentication
    |         |
A:  +-------->| Header: POST (Code=0.02)
    |  POST   | Uri-Path:"token"
    |         | Content-Format: application/ace+cbor
    |         | Payload: <Request-Payload>
    |         |
B:  |<--------+ Header: 2.05 Content
    |         | Content-Format: application/ace+cbor
    |  2.05   | Payload: <Response-Payload>
    |         |
    ]]></artwork>
        </figure>
        <t>The information contained in the Request-Payload and the
	Response-Payload is shown in <xref target="fig_cOfflineReq" format="default"/>.
        </t>
        <figure anchor="fig_cOfflineReq">
          <name>Request and Response Payload for the C Offline</name>
          <sourcecode name="" type="cbor-diag"><![CDATA[
Request-Payload:
{
  / client_id / 24 : "keyfob",
  / audience / 5   : "PACS1337"
}

Response-Payload:
{
  / access_token / 1 : b64'VGVzdCB0b2tlbg',
  / cnf / 8 : {
    / COSE_Key / 1 : {
      / kid / 2 : b64'c29tZSBwdWJsaWMga2V5IGlk',
      / kty / 1 : 4 / Symmetric /,
      / k / -1  : b64'ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE'
    }
  }
}
      ]]></sourcecode>
        </figure>
        <t>In this case, the access token is just an opaque byte string referencing
   the authorization information at the AS.</t>
        <dl newline="false" spacing="normal" indent="4">
          <dt>C:</dt>
          <dd>Next, the client POSTs the access token to the authz-info
        endpoint in the RS.  This is a plain CoAP request, i.e., no
        DTLS between the client and RS.  Since the token is an opaque string,
        the RS cannot verify it on its own, and thus defers to respond to the
        client with a status code until after step E.</dd>
          <dt>D:</dt>
          <dd>The RS sends the token to the introspection
          endpoint on the AS using a CoAP POST request.  In this example, the RS and
	  AS are assumed to have performed mutual authentication using a pre-shared security
	  context (PSK, RPK, or certificate) with the RS acting as the DTLS client.</dd>
          <dt>E:</dt>
          <dd>
	    <t>The AS provides the introspection response (2.05 Content)
	containing parameters about the token.  This includes the confirmation
	key (<tt>cnf</tt>) parameter that allows the RS to verify the client's proof of
	possession in step F. Note that our example in <xref
	target="fig_cOfflineIntroReq" format="default"/> assumes a preestablished key
	(e.g., one
	used by the client and the RS for a previous token) that is now only
	referenced by its key identifier <tt>kid</tt>.</t>
	<t>After receiving message E, the RS responds to the client's POST in
        step C with the CoAP response code 2.01 (Created).</t>
	  </dd>
	</dl>
            <figure anchor="fig_cOfflineIntrospection">
              <name>Token Introspection for the C Offline</name>
              <artwork align="left" name="" type="" alt=""><![CDATA[
           Resource
  Client    Server
    |         |
C:  +-------->| Header: POST (T=CON, Code=0.02)
    |  POST   | Uri-Path:"authz-info"
    |         | Payload: b64'VGVzdCB0b2tlbg'
    |         |
    |         |     Authorization
    |         |       Server
    |         |          |
    |      D: +--------->| Header: POST (Code=0.02)
    |         |  POST    | Uri-Path: "introspect"
    |         |          | Content-Format: application/ace+cbor
    |         |          | Payload: <Request-Payload>
    |         |          |
    |      E: |<---------+ Header: 2.05 Content
    |         |  2.05    | Content-Format: application/ace+cbor
    |         |          | Payload: <Response-Payload>
    |         |          |
    |         |
    |<--------+ Header: 2.01 Created
    |  2.01   |
    |         |
]]></artwork>
            </figure>
            <t>The information contained in the Request-Payload and the
        Response-Payload is shown in <xref target="fig_cOfflineIntroReq" format="default"/>.

            </t>
            <figure anchor="fig_cOfflineIntroReq">
              <name>Request and Response Payload for Introspection</name>
              <sourcecode name="" type="cbor-diag"><![CDATA[
Request-Payload:
{
  / token /     11 : b64'VGVzdCB0b2tlbg',
  / client_id / 24 : "FrontDoor"
}

Response-Payload:
{
  / active / 10 : true,
  / aud /     3 : "lockOfDoor4711",
  / scope /   9 : "open close",
  / iat /     6 : 1563454000,
  / cnf /     8 : {
         / kid / 3 : b64'c29tZSBwdWJsaWMga2V5IGlk'
  }
}
          ]]></sourcecode>
            </figure>
            <t>The client uses the symmetric PoP key to establish a DTLS
            PreSharedKey secure connection to the RS. The CoAP request PUT is
            sent to the uri-path /state on the RS, changing the state of the door to
	    locked.</t>
<!--[rfced] We are having trouble parsing the following sentence. Please
let us know how we may clarify.

Original:
      F: The RS responds with a appropriate over the secure DTLS
      channel.

Perhaps:
      F: The RS responds with an appropriate response over the secure DTLS
      channel.
	  
	  
Ludwig: Correct. Fixed.
-->
	    <dl newline="false" spacing="normal" indent="4">
            <dt>F:</dt> 
	    <dd>The RS responds with an appropriate response over the secure DTLS channel.</dd>
        </dl>
        <figure anchor="fig_cOfflineDTLSRequestAndResponse">
          <name>Resource Request and Response Protected by OSCORE</name>
          <artwork align="left" name="" type="" alt=""><![CDATA[
           Resource
  Client    Server
    |         |
    |<=======>| DTLS Connection Establishment
    |         |   using Pre Shared Key
    |         |
    +-------->| Header: PUT (Code=0.03)
    | PUT     | Uri-Path: "state"
    |         | Payload: <new state for the lock>
    |         |
F:  |<--------+ Header: 2.04 Changed
    | 2.04    | Payload: <new state for the lock>
    |         |
            ]]></artwork>
        </figure>
      </section>
    </section>
<section anchor="Acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>This document is a product of the ACE Working Group of the IETF.</t>
      <t>Thanks to <contact fullname="Eve Maler"/> for her contributions to the use of
      OAuth 2.0 and Unlicensed Mobile Access (UMA) in IoT scenarios, 
      <contact fullname="Robert Taylor"/> for his
      discussion input, and <contact fullname="Malisa Vucinic"/> for his input on the
      predecessors of this proposal.</t>
      <t>Thanks to the authors of "<xref target="I-D.ietf-oauth-pop-key-distribution" format="default"/><xref target="I-D.ietf-oauth-pop-key-distribution" format="title"/>" <xref target="I-D.ietf-oauth-pop-key-distribution" format="default"/>, from where
      parts of the security considerations where copied.</t>
      <t>Thanks to <contact fullname="Stefanie Gerdes"/>, <contact fullname="Olaf
      Bergmann"/>, and <contact fullname="Carsten
      Bormann"/> for contributing their work on AS discovery from
      "<xref target="I-D.gerdes-ace-dcaf-authorize" format="title"/>" <xref target="I-D.gerdes-ace-dcaf-authorize" format="default"/> (see <xref target="asDiscovery"
      format="default"/>) and the considerations on multiple access tokens.</t>
      <t>Thanks to <contact fullname="Jim Schaad"/> and <contact fullname="Mike
      Jones"/> for their comprehensive reviews.</t>
      <t>Thanks to <contact fullname="Benjamin Kaduk"/> for his input on various
      questions related to this work.</t>
      <t>Thanks to <contact fullname="Cigdem Sengul"/> for some very useful review
      comments.</t>
      <t>Thanks to <contact fullname="Carsten Bormann"/> for contributing the text for
      the CoRE Resource Type registry.</t>
      <t>Thanks to <contact fullname="Roman Danyliw"/> for suggesting <xref
      target="app_diffOAuth" format="default"/>
      (including its contents).</t>
      <t><contact fullname="Ludwig Seitz"/> and <contact fullname="Göran Selander"/>
      worked on this document as part of the CelticPlus project CyberWI, with funding
      from Vinnova. <contact fullname="Ludwig Seitz"/>
      has also received further funding for this work by Vinnova in the context of
      the CelticNext project CRITISEC.</t>
    </section>
  </back>
<!--[rfced] Terminology

a) Throughout the text,  the following terminology appears to 
be used inconsistently. Please review these occurrences and let us know
if/how they be made consistent.

group-audience vs. group audience

===
Ludwig: I cannot find any instances of "group audience" in this document.
===


"AS Request Creation Hints" message vs. "AS Request Creation Hints"

===
Ludwig: Fixed to remove 'message'
===

b) We see parameter names appear within double quotes and without quotes
inconsistently throughout the document. Do you want any changes to  
make this consistent?

   ace_profile parameter vs. "ace_profile" parameter
   cnonce parameter vs. "cnonce" parameter
   scope parameter vs. "scope" parameter

Note: there are instances of "cnonce" parameter tagged using <tt>.
FYI, xml2rfc no longer renders <tt> with quotation marks in the text output;
it still renders fixed-width font in the HTML and PDF outputs.

Ludwig: I'd prefer the double quotes. Fixed. Note that this also applied to claim names, I fixed that as well
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. For example, please consider
whether the following should be updated: traditional, native, dumb, and
pronouns such as he/his/her.

Ludwig: I have replaced "traditional" by "classical" and deleted "dumb",
"native" occurs in reference to a document title using this exact word, 
so it would be confusing to rephrase this. I also rephrased the example using he/his.

The other occurences of his/her are part of the acknowledgments and the corresponding
persons have not indicated other pronoun preferences to my best knowledge.


-->
</rfc>