<?xml version="1.0" encoding="utf-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. --> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC6690 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6690.xml">
<!ENTITY RFC6749 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6749.xml">
<!ENTITY RFC6750 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6750.xml">
<!ENTITY RFC6819 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6819.xml">
<!ENTITY RFC6838 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6838.xml">
<!ENTITY RFC6920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6920.xml">
<!ENTITY RFC7009 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7009.xml">
<!ENTITY RFC8949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8949.xml">
<!ENTITY RFC7228 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7228.xml">
<!ENTITY RFC7231 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7231.xml">
<!ENTITY RFC7252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7252.xml">
<!ENTITY RFC7519 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7519.xml">
<!ENTITY RFC7521 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7521.xml">
<!ENTITY RFC7540 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7540.xml">
<!ENTITY RFC7591 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7591.xml">
<!ENTITY RFC7641 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7641.xml">
<!ENTITY RFC7662 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7662.xml">
<!ENTITY RFC7744 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7744.xml">
<!ENTITY RFC7959 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7959.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8152 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8152.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8252.xml">
<!ENTITY RFC8259 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8259.xml">
<!ENTITY RFC8392 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8392.xml">
<!ENTITY RFC8414 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8414.xml">
<!ENTITY RFC8446 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8446.xml">
<!ENTITY RFC8516 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8516.xml">
<!ENTITY RFC8613 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8613.xml">
 <!ENTITY RFC8628 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8628.xml"> nbsp    "&#160;">
 <!ENTITY RFC8693 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8693.xml"> zwsp   "&#8203;">
 <!ENTITY RFC8747 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.8747.xml"> nbhy   "&#8209;">
 <!ENTITY I-D.ietf-ace-oauth-params SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ace-oauth-params.xml">
<!ENTITY I-D.erdtman-ace-rpcc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.erdtman-ace-rpcc.xml">
<!ENTITY I-D.ietf-tls-dtls13 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-dtls13.xml">
<!ENTITY I-D.ietf-quic-transport SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-quic-transport.xml">
<!ENTITY I-D.ietf-ace-dtls-authorize SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ace-dtls-authorize.xml">
<!ENTITY I-D.ietf-ace-oscore-profile SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ace-oscore-profile.xml"> wj     "&#8288;">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description

<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 processing instructions (PIs), the I-D were submitted after approval,
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits review and DTD validation -->
<!-- control let us know if you approve these changes:

a) the table addition of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels definition of subsections "cti" in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the Section 5.9.2.
b) updated text in Section 5.8.4.4
c) RFC 4648 added as a normative reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs

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 follows is recommended by changes to the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions characters in bulleted lists.)
-->
<rfc category="std" docName="draft-ietf-ace-oauth-authz-43" ipr="trust200902">

  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" xml2rfc v2v3 conversion 3.9.1 -->

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

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
        full title is longer than 39 characters -->
<title abbrev="ACE-OAuth">Authentication and Authorization for Constrained Environments (ACE) using Using the OAuth 2.0 Framework (ACE-OAuth)</title>

    <!-- add 'role="editor"' below

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

Current:
  Authentication and Authorization for Constrained Environments (ACE)
               Using the editors if appropriate -->

    <!-- Another author who claims to be an editor OAuth 2.0 Framework (ACE-OAuth)

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

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

    <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>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <author fullname="Goeran 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>

        <!-- uri and facsimile elements may also be added -->
      </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?
-->
      <organization/>
      <address>
        <postal>
          <street></street>
          <code></code> <city></city>
          <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>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
      <organization>Arm Ltd.</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <code>6067</code>
          <city>Absam</city>
          <country>Austria</country>
        </postal>
        <email>Hannes.Tschofenig@arm.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <date year="2021" year="2022" month="March" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the purpose of calculating the expiry date).  With drafts it is normally sufficient to specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Security</area>

    <workgroup>ACE Working Group</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>CoAP, OAuth 2.0, Access Control, Authorization, Internet
    <workgroup>ACE</workgroup>

    <keyword>CoAP</keyword>
    <keyword>OAuth 2.0</keyword>
    <keyword>Access Control</keyword>
    <keyword>Authorization</keyword>
    <keyword>Internet of Things</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->
    <abstract>
      <t>This specification defines a framework for authentication and
      authorization in Internet of Things (IoT) environments called ACE-OAuth. 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" title="Introduction"> 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"/>. target="RFC4949" format="default"/>. The authorization
   task itself can best be described as granting access to a requesting client, client for
   a resource hosted on a device, i.e., the resource server (RS).  This exchange is
   mediated by one or multiple authorization servers (AS). (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 devices, the Constrained
   Application Protocol (CoAP) <xref target="RFC7252"/> 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"/> 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"/>. target="RFC7228" format="default"/>.  This design aims to accommodate
   different IoT deployments and thus as well as a continuous range of device and network
   capabilities.  Taking energy consumption as an example: At example, at one end end, there are
   energy-harvesting or  battery powered  battery-powered devices which that have a tight power
   budget,
   budget; on the other end end, there are mains-powered devices, 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 capabilities, and there is a need to support many
     different authorization use cases <xref target="RFC7744"/>.</t> target="RFC7744" format="default"/>.</t>
      <t>This specification describes a framework for authentication Authentication and authorization
   in constrained environments Authorization
   for Constrained Environments (ACE) built on re-use reuse of OAuth 2.0
   <xref target="RFC6749"/>, 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="I-D.ietf-ace-dtls-authorize"/> target="RFC9202" format="default"/> or <xref target="I-D.ietf-ace-oscore-profile"/>. 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, specification and also summarized in
   <xref target="app:profileRequirements"/>. target="app_profileRequirements" format="default"/>.
      </t>
    </section>
    <!-- ***************************************************** -->

<section anchor="terminology" title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
"OPTIONAL"
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref
target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.</t>
      <t>Certain security-related terms terms, such as "authentication",
"authorization", "confidentiality", "(data) integrity", "message
authentication code", and "verify" "verify", are taken from <xref
target="RFC4949"/>. 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.)
-->
      <t>Since exchanges in this specification are described as RESTful protocol
    interactions, HTTP <xref target="RFC7231"/> 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"/> 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 resources, such as token and
introspection at the AS and authz-info at the RS (see <xref target="tokenAuthInfoEndpoint"/> target="tokenAuthInfoEndpoint" format="default"/> for a definition of the authz-info endpoint).
The CoAP <xref target="RFC7252"/> definition, which is "An "[a]n entity
participating in the CoAP protocol" <xref target="RFC7252" format="default"/>, is not used in this specification.</t>
      <t>The specifications specification in this document is called the "framework" or "ACE framework".
When referring to "profiles of this framework" 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.
(e.g., public key of the RS, RS or profile supported by RS).</t>
      <t>The term "Authorization Information" "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>
    </section>
    <!-- ***************************************************** -->

<section anchor="overview" title="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"/> 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
  settings, additional profiling is needed.
      </t>
      <t>Another building block is the lightweight web transfer protocol CoAP
  <xref target="RFC7252"/>, 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"/>, target="RFC7540" format="default"/>,
  Message Queuing Telemetry Transport (MQTT) <xref target="MQTT5.0"/>, target="MQTT5.0" format="default"/>,
  Bluetooth Low Energy (BLE) <xref target="BLE"/> target="BLE" format="default"/>, and QUIC <xref
  target="I-D.ietf-quic-transport"/>. target="RFC9000" format="default"/>.  Note that this document specifies
  protocol exchanges in terms of RESTful verbs verbs, such as GET and POST.
  Future profiles using protocols that do not support these verbs MUST <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"/>, target="RFC8949" format="default"/>, for encodings where JSON
  <xref target="RFC8259"/> 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 RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.
      </t>
      <t>A fourth building block is CBOR Object Signing and Encryption (COSE)
  <xref target="RFC8152"/>, target="RFC8152" format="default"/>, which enables object-level layer security as an
  alternative or complement to transport layer security (DTLS
    <xref target="RFC6347"/> target="RFC6347" format="default"/> or TLS <xref target="RFC8446"/>). target="RFC8446" format="default"/>). COSE is used to
    secure self-contained tokens 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"/>. target="RFC8392" format="default"/>.
    Application-layer security for CoAP using COSE can be provided with OSCORE Object Security for
    Constrained RESTful Environments (OSCORE)
    <xref target="RFC8613"/>.</t> 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"/> 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"/>.</t> target="constraints" format="default"/>.</t>
      <t>Luckily, not every IoT device suffers from all constraints.  The  Nevertheless, the ACE
  framework nevertheless takes all these aspects into account and allows
  several different deployment variants to co-exist, 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" title="OAuth 2.0"> 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:

      <list style="hanging">

        <t hangText="Access Tokens:"><vspace blankLines="0"/>

        </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.
        <vspace blankLines="1"/>
            </t>
            <t>
        Access tokens can have different formats, formats and various methods
        of utilization e.g., (e.g., cryptographic properties) based on the security
        requirements of the given deployment.
        <vspace blankLines="1"/>
            </t>

	<t hangText="Introspection:"><vspace blankLines="0"/>
          </dd>
          <dt>Introspection:</dt>
          <dd>
	Introspection is a method for a resource server 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 reference, rather than a self-contained
	token.  More information about introspection in OAuth 2.0 can be
	found in <xref target="RFC7662"/>.
	</t>

	<t hangText="Refresh Tokens:"><vspace blankLines="0"/> 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, 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"/>).
	<vspace blankLines="1"/> 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.
	<vspace blankLines="1"/></t>

	<t hangText="Proof of Possession Tokens:"><vspace blankLines="0"/>
            </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).
        <vspace blankLines="1"/>
            </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 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" token", it
	is assumed to be a PoP access token unless specifically stated
	otherwise.

        <vspace blankLines="1"/>

            </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.
	<vspace blankLines="1"/>
        <list style="hanging">

          <t hangText="Symmetric
            </t>
            <dl newline="true" spacing="normal">
              <dt>Symmetric PoP key:"><vspace blankLines="0"/> key:</dt>
              <dd>
                <t>
              The AS generates a random 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 MUST <bcp14>MUST</bcp14> be encrypted
	      in the latter case.  The PoP key is also returned to
	      client together with the token.<vspace blankLines="1"/>

          </t>
          <t hangText="Asymmetric token.</t>
              </dd>
              <dt>Asymmetric PoP key:"><vspace blankLines="0"/> 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.
          </t>
        </list>

        <vspace blankLines="1"/>
          </dd>
            </dl>
            <t> The token is either a simple reference, reference
	or a structured information object (e.g., CWT <xref target="RFC8392"/>) target="RFC8392" format="default"/>)
	protected by a cryptographic wrapper (e.g., COSE <xref
	target="RFC8152"/>). target="RFC8152" format="default"/>).  The choice of PoP key does not necessarily imply
	a specific credential type for the integrity protection of the
	token.<vspace blankLines="1"/>
      </t>

      <t hangText="Scopes
	token.</t>
          </dd>
          <dt>Scopes and Permissions:"><vspace blankLines="0"/> Permissions:</dt>
          <dd>
            <t>
         In OAuth 2.0, the client specifies the type of permissions it is
         seeking to obtain (via the scope parameter) in the access token
	 request.  In turn, the AS may use the scope response parameter to
	 inform the client of the scope of the access token issued.  As the
	 client could be a constrained device as well, this specification
	 defines the use of CBOR encoding, see encoding (see <xref
	 target="oauthProfile"/>, target="oauthProfile" format="default"/>) for such requests and responses.
         <vspace blankLines="1"/>
            </t>
            <t>
         The values of the scope parameter in OAuth 2.0 are expressed as a list
	 of space-delimited, case-sensitive strings, strings with a semantic that is
	 well-known
	 well known to the AS and the RS.
<!--[rfced] We see a number of author-inserted comments in the XML
file for this document. We are unsure if these have been resolved.
Please review and let us know if these can be deleted or if they
need to be addressed.-->
         <!-- <vspace blankLines="1"/>
         A common misconception is that the requested scopes must
         also be included in the returned access token, but the requested scopes
         are only metadata about the token.  They could also be packaged in the
         token as a separate attribute, but it's more common to assert the
         requested and authorized access using claims within the access token.
         <vspace blankLines="1"/>-->
         More details about the concept of scopes is are found under Section 3.3 in
         <xref target="RFC6749" />.<vspace blankLines="1"/>
      </t>

      <t hangText="Claims:"><vspace blankLines="0"/> 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 "iss" claim) and
      what audience the access token is intended for (via the "aud" claim).
	The audience of an access token can be a specific resource or resource, one resource, or
	many resource servers.  The resource owner policies influence what
	claims are put into the access token by the authorization server.
        <vspace blankLines="1"/>
            </t>
            <t>
        While the structure and encoding of the access token varies throughout
        deployments, a standardized format has been defined with the JSON Web
        Token (JWT) <xref target="RFC7519"/> target="RFC7519" format="default"/>, where claims are encoded as a
	JSON object.  In <xref target="RFC8392"/> target="RFC8392" format="default"/>, the CBOR Web Token (CWT)
	has been defined as an equivalent format using CBOR encoding.
	<vspace blankLines="1"/>
            </t>

      <t hangText="The token
          </dd>
          <dt>Token and introspection Endpoints:"><vspace blankLines="0"/> 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).
      <vspace blankLines="0"/>
            </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.)
      <vspace blankLines="1"/>
        </t>

    </list>
            </t>
          </dd>
        </dl>
      </section>
      <section anchor="coap" title="CoAP"> numbered="true" toc="default">
        <name>CoAP</name>
        <t>
    CoAP is an application-layer protocol similar to HTTP, 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 blockwise block-wise transfers <xref target="RFC7959"/>. target="RFC7959" format="default"/>.  However,
    blockwise
    block-wise transfer does not increase the size limits of CoAP options,
    therefore 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"/><xref target="RFC8446"/> target="RFC6347" format="default"/> <xref target="I-D.ietf-tls-dtls13"/>. 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 mechanism, such as COSE <xref target="RFC8152"/>. target="RFC8152" format="default"/>.
        </t>
        <t>
    One application of COSE is OSCORE
    <xref target="RFC8613"/>, 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 framework, the use of CoAP as replacement for HTTP is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
  for use in constrained environments.  For communication security 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"/>, target="RFC6347" format="default"/> <xref target="I-D.ietf-tls-dtls13"/> target="RFC9147" format="default"/> and OSCORE
  <xref target="RFC8613"/> target="RFC8613" format="default"/> are mentioned as examples, examples; other protocols fulfilling
  the requirements from <xref target="minimalCommSecReq"/> target="minimalCommSecReq" format="default"/> are also
  applicable.</t>
      </section>
    </section>
    <!-- ***************************************************** -->
<section anchor="specs" title="Protocol Interactions"> 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 deployments, the RS can
    process the access token locally, however locally; however, in some cases 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"/>. target="fig_protocolFlow" format="default"/>.  An
    overview of various OAuth concepts is provided in <xref
    target="oauth2Overview"/>. target="oauth2Overview" format="default"/>.
</t>

<t><figure align="center" anchor="fig:protocolFlow"
           title="Basic
      <figure anchor="fig_protocolFlow">
        <name>Basic Protocol Flow."> Flow</name>
        <artwork align="left"><![CDATA[ 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></t>

<t>
  <list style="hanging">
    <t hangText="Requesting
      </figure>
      <dl newline="true" spacing="normal">
        <dt>Requesting an Access Token (A):"><vspace blankLines="0"/> (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"/> 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,
      obtain and information about the credentials it wants to use for
      proof-of-possession
      proof of possession (e.g., symmetric/asymmetric cryptography or a
      reference to a specific key) of the access token.<vspace blankLines="1"/>
    </t>

    <t hangText="Access token.</t>
        </dd>
        <dt>Access Token Response (B):"><vspace blankLines="0"/> (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. e.g.,
      the profile the RS supports.  More information about these parameters
      can be found in <xref target="tokenParams"/>.
      <vspace blankLines="1"/> target="tokenParams" format="default"/>.
          </t>

    <t hangText="Resource
        </dd>
        <dt>Resource Request (C):"><vspace blankLines="0"/> (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"/>, target="RFC7540" format="default"/>, QUIC <xref target="I-D.ietf-quic-transport"/>, target="RFC9000" format="default"/>,
      MQTT <xref target="MQTT5.0"/>, target="MQTT5.0" format="default"/>, Bluetooth Low Energy <xref target="BLE"/>, target="BLE" format="default"/>,
      etc., are also viable candidates.
      <vspace blankLines="1"/>
          </t>
          <t>
      Depending on the device limitations and the selected protocol, this
      exchange may be split up into two parts:

<list style="empty">
  <t>(1) the parts:</t>
          <ol type="(%d)" spacing="normal">
            <li>the client sends the access token containing, or referencing, the
  authorization information to the RS, RS that will be used for subsequent
  resource requests by the client, and </t>

  <t>(2) the </li>
            <li>the client makes the resource access request, request using the communication
  security protocol and other Access Information obtained from the AS.</t>
</list>

      <vspace blankLines="1"/> AS.</li>
          </ol>
          <t>
      The client and the RS mutually authenticate using the security protocol
      specified in the profile (see step B) (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 (D) and E) (E)) over HTTP or CoAP.<vspace blankLines="1"/>
    </t>

    <t hangText="Token CoAP.</t>
        </dd>
        <dt>Token Introspection Request (D):"><vspace blankLines="0"/> (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"/> target="introspectionEndpoint" format="default"/> and for HTTP in
      <xref target="RFC7662"/>.
      <vspace blankLines="1"/> 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.<vspace blankLines="1"/>
    </t>

    <t hangText="Token own.</t>
        </dd>
        <dt>Token Introspection Response (E):"><vspace blankLines="0"/> (E):</dt>
        <dd>
          <t>
      The AS validates the token and returns the most recent parameters, such
      as scope, audience, validity etc. 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.<vspace blankLines="1"/>
    </t>

    <t hangText="Protected it.</t>
        </dd>
        <dt>Protected Resource (F):"><vspace blankLines="0"/> (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, response according to
      the communication security protocol used.
    </t>
  </list>
</t>
    </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"/> target="RFC7521"
      format="default"/> and <xref target="RFC8628"/>). target="RFC8628" format="default"/>).
      What grant type works best depends on the usage scenario and scenario; <xref target="RFC7744"/>
      target="RFC7744" format="default"/> describes many different IoT use cases cases, but
      there are two grant types that cover a majority of these scenarios, namely the Authorization Code Grant
      authorization code grant (described in <xref target="RFC7521" 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.1 4.4 of <xref target="RFC7521"/>) RFC 6749. Please
let us know if this is not correct.

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

Current:
   and the client credentials
   grant (described in Section 4.4 of [RFC6749]).

b) We note that RFC 8392 does not contain a Section 5.1.
How should this citation be updated?

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

      the client credentials grant (described
      in <xref target="RFC7521"/>). target="RFC6749" sectionFormat="of" section="4.4"/>). The Authorization Code Grant authorization
      code grant is a good fit for use with apps running on smart phones 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"/> target="RFC8252" format="default"/> are applicable to this use case. The Client Credential Grant 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 pre-arranged 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 traditional OAuth flows, or it
    could be pre-configured 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"/>. 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 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"/>; target="asDiscovery" format="default"/>; profiles MAY <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 format, as described in <xref target="RFC6690"/>. target="RFC6690" format="default"/>.
</t>
    </section>
    <!-- ***************************************************** -->

<section anchor="oauthProfile" title="Framework"> 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>
    <list style="hanging">
      <t hangText="Credential Provisioning"><vspace blankLines="0"/>
        In constrained environments 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.
        <vspace blankLines="1"/>
          </t>

      <t hangText="Proof-of-Possession"><vspace blankLines="0"/>
        </dd>
        <dt>Proof of Possession</dt>
        <dd>
          <t>
        The ACE framework, by default, implements proof-of-possession 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 "cnf" (confirmation)
	claim
	<xref target="RFC8747"/> target="RFC8747" format="default"/>, indicating what key is used for
	proof-of-possession.
	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.
	<vspace blankLines="1"/>
          </t>

      <t hangText="ACE Profiles"><vspace blankLines="0"/>
        </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 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 "ace_profile"
	parameter in the token response.
      </t>
    </list>
  </t>
      </dd>
      </dl>
      <t>OAuth 2.0 requires the use of TLS both to protect the communication
  between the AS and client when requesting an access token; token between the client and RS
  when accessing a resource and between the AS and RS if introspection is used.
  In constrained settings settings, TLS is not always feasible, feasible or desirable.
  Nevertheless
  Nevertheless, it is REQUIRED <bcp14>REQUIRED</bcp14> that the communications named above are
  encrypted, integrity protected protected, and protected against message replay.  It is
  also REQUIRED <bcp14>REQUIRED</bcp14> that the communicating endpoints perform mutual authentication.
  Furthermore
  Furthermore, it MUST <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.
  (e.g., sending the token from the client to the RS).</t>
      <t>Profiles MUST <bcp14>MUST</bcp14> specify a communication security protocol between the
      client and RS that provides the features required above.  Profiles MUST
      <bcp14>MUST</bcp14> specify a
      communication security protocol RECOMMENDED <bcp14>RECOMMENDED</bcp14> to be used between the
      client and AS that provides the features required above.  Profiles MUST specify <bcp14>MUST</bcp14>
      specify, for
  introspection  introspection, a communication security protocol RECOMMENDED
      <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 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
  REQUIRED
  <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,
  document; if a profile needs to use other OAuth 2.0 parameters with CoAP CoAP, it
  MUST
  <bcp14>MUST</bcp14> specify their CBOR encoding.</t>
      <t>Profiles that use CBOR encoding of protocol message parameters at the
  outermost encoding layer MUST <bcp14>MUST</bcp14> use the content format 'application/ace+cbor'. Content-Format "application/ace+cbor".
  If CoAP is used for communication, the Content-Format MUST <bcp14>MUST</bcp14> be abbreviated
  with the ID: 19 (see <xref target="IANAcoapContentFormat"/>).</t> 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 REQUIRED <bcp14>REQUIRED</bcp14> to use
  CBOR <xref target="RFC8949"/> target="RFC8949" format="default"/> instead of JSON.  Depending on the profile,
  the CBOR payload MAY <bcp14>MAY</bcp14> be enclosed in a non-CBOR cryptographic wrapper.</t>
      <section anchor="asDiscovery" title="Discovering numbered="true" toc="default">
        <name>Discovering Authorization Servers">
  <t>C Servers</name>
<!--[rfced] Throughout this document and especially in Section 5.1,
the article "the" has been added before "C" and "RS" as it appears
elsewhere in this document. Please review usage and let us know if
any further updates are needed.
-->
        <t>The C must discover the AS in charge of the RS to determine where to request the
access token. To do so, the C 1) must 1. find out the AS URI to which the token
request message must be sent and 2. MUST 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 MAY <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"/>). target="rreq" format="default"/>). How the C validates the
AS authorization is not in scope for this document. The C may, e.g., 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. (e.g., by querying a dedicated secure service provided by the client owner) .</t>

</section><!--AS
      </section>
      <!--AS Discovery -->

  <section anchor="rreq" title="Unauthorized numbered="true" toc="default">
        <name>Unauthorized Resource Request Message"> 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. RSes MUST
	The RSs <bcp14>MUST</bcp14>
	treat any request for a protected resource as an Unauthorized Resource
	Request message when any of the following hold:

      <list style="symbols">
	<t>The
        </t>
        <ul spacing="normal">
          <li>The request has been received on an unsecured channel.</t>
	<t>The channel.</li>
          <li>The RS has no valid access token for the sender of the request
	  regarding the requested action on that resource.</t>
	<t>The 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.</t>
      </list>
    </t>
	  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 MUST NOT <bcp14>MUST
	NOT</bcp14> be protected as specified above (cf.  <xref
    target="tokenAuthInfoEndpoint"/>).</t>
	target="tokenAuthInfoEndpoint" format="default"/>).</t>
        <t>Unauthorized Resource Request messages MUST <bcp14>MUST</bcp14> be denied with an
	"unauthorized_client" error response. In this response, the Resource Server SHOULD 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, as described in <xref target="asInfo"/>.</t> target="asInfo" format="default"/>.</t>
        <t>The handling of all client requests (including unauthorized ones)
    by the RS is described in <xref target="requestC2RS"/>.</t>
  </section><!-- target="requestC2RS" format="default"/>.</t>
      </section>
      <!-- Unauthorized Request -->

  <section anchor="asInfo" title="AS numbered="true" toc="default">
        <name>AS Request Creation Hints"> Hints</name>
        <t>The "AS Request Creation Hints" message is sent by an RS as a response to
	an Unauthorized Resource Request message (see <xref target="rreq"/>) target="rreq"
	format="default"/>) to help
	the sender of the Unauthorized Resource Request message acquire a valid
	access token. The "AS Request Creation Hints" message is a CBOR or JSON map,
	with an OPTIONAL <bcp14>OPTIONAL</bcp14> element "AS" specifying an absolute URI (see Section 4.3
    of
	<xref target="RFC3986"/>) target="RFC3986" sectionFormat="of" section="4.3"/>) that identifies the
	appropriate AS for the RS.</t>
        <t>The message can also contain the following OPTIONAL parameters:
    <list style="symbols">
      <t>A <bcp14>OPTIONAL</bcp14>
	parameters:</t>
        <ul spacing="normal">
          <li>An "audience" element contains an identifier the client
      should request at the AS, as suggested by the RS. With this parameter,
      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"/> target="audience" format="default"/> for a discussion of this parameter.</t>
      <t>A parameter.</li>
          <li>A "kid" (key identifier) element containing 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,
	  key in order to avoid having to re-establish reestablish the security
      association.</t>
      <t>A
	  association.</li>
          <li>A "cnonce" element containing contains a client-nonce. See <xref
      target="cnonceParam"/>.</t>
      <t>A target="cnonceParam"
	  format="default"/>.</li>
          <li>A "scope" element containing contains the suggested scope that the client
	  should request towards the AS.</t>
    </list></t> AS.</li>
        </ul>
        <t><xref target="fig:asinfo"/> target="table_asinfo" format="default"/> summarizes the parameters that may
	be part of the "AS Request Creation Hints".

      <figure align="center" anchor="fig:asinfo"
	      title="AS Hints".</t>
        <table anchor="table_asinfo">
          <name>AS Request Creation Hints">
      <artwork align="left"><![CDATA[
        /-----------+----------+---------------------\
        | Name      | CBOR Key | Value Type          |
        |-----------+----------+---------------------|
        | AS        |     1    | text string         |
        | kid       |     2    | byte string         |
        | audience  |     5    | text string         |
        | scope     |     9    | text 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 |
        | cnonce    |    39    | byte string         |
        \-----------+----------+---------------------/
      ]]></artwork></figure></t> 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 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"/> target="fig_as-info-payload" format="default"/> shows an example for an "AS
    Request Creation Hints" message payload using CBOR <xref target="RFC8949"/> target="RFC8949" format="default"/>
    diagnostic notation, using the parameter names instead of the CBOR keys for
    better human readability.</t>
<!-- [rfced] Please review the "type" attribute of each sourcecode element
in the XML file to ensure correctness. If the current list of preferred
values for "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt)
does not contain an applicable type, then feel free to let us know.-->
        <figure title="AS anchor="fig_as-info-payload">
          <name>AS Request Creation Hints payload example"
	    anchor="fig:as-info-payload"><artwork><![CDATA[ Payload Example</name>
          <sourcecode type="cbor-diag"><![CDATA[
    4.01 Unauthorized
    Content-Format: application/ace+cbor
    Payload :
    {
     "AS" : "coaps://as.example.com/token",
     "audience" : "coaps://rs.example.com"
     "scope" : "rTempC",
     "cnonce" : h'e0a156bb3f'
    }
]]></artwork></figure>
]]></sourcecode>
        </figure>
        <t>In the example above, the response parameter "AS" points the receiver of
    this message to the URI "coaps://as.example.com/token" to request access
    tokens.  The RS sending this response uses an internal clock
    that is not synchronized with the clock of the AS.  Therefore, it
    can not
    cannot reliably verify the expiration time of access tokens it receives.
    To
    Nevertheless, to ensure a certain level of access token freshness nevertheless, freshness, the RS has
    included a <spanx style="verb">cnonce</spanx> <tt>cnonce</tt> parameter (see <xref
    target="cnonceParam"/>) target="cnonceParam" format="default"/>) in the response. (The hex-sequence hex sequence of the cnonce parameter
    is encoded in CBOR-based notation in this example.)</t>
        <t><xref target="fig:as-info-cbor"/> target="fig_as-info-cbor" format="default"/> illustrates the mandatory to use
	of binary encoding of the message payload shown in
	<xref target="fig:as-info-payload"/>.</t> target="fig_as-info-payload" format="default"/>.</t>
        <figure title="AS anchor="fig_as-info-cbor">
          <name>AS Request Creation Hints example encoded Example Encoded in CBOR"
	    anchor="fig:as-info-cbor"><artwork><![CDATA[ CBOR</name>
          <sourcecode name="" type="cbor"><![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                     #
      ]]></artwork></figure>
      ]]></sourcecode>
        </figure>
        <section anchor="cnonceParam" title="The numbered="true" toc="default">
          <name>The Client-Nonce Parameter"> Parameter</name>
          <t>If the RS does not synchronize its clock with the AS, it could be
      tricked into accepting old access tokens, 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 "cnonce" (client-nonce) parameter.
      The processing requirements for this parameter are as follows:
      <list style="symbols">
	<t>An
          </t>
          <ul spacing="normal">
            <li>An RS sending a "cnonce" parameter in an "AS Request Creation
	    Hints" message MUST <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" message, with some
	    allowance for unexpected delays.</t>

	<t>A delays.</li>
            <li>A client receiving a "cnonce" parameter in an "AS Request Creation
	    Hints" message MUST <bcp14>MUST</bcp14> include this in the parameters when
	    requesting an access token at the AS, using the "cnonce" parameter from
	    <xref target="cnonceParamToken"/>.</t>

	<t>If target="cnonceParamToken" format="default"/>.</li>
            <li>If an AS grants an access token request containing a "cnonce"
	    parameter, it MUST <bcp14>MUST</bcp14> include this value in the access token, using
	    the	"cnonce" claim specified in <xref target="accessToken"/>.</t>

	<t>An target="accessToken"
	    format="default"/>.</li>
            <li>An RS that is using the client-nonce mechanism and that receives an
	    access token MUST <bcp14>MUST</bcp14> verify that this token contains a cnonce
	    claim, with
	    a client-nonce value that is fresh according to the information stored
	    at the first step above.  If the cnonce claim is not present or if the
	    cnonce claim value is not fresh, the RS MUST <bcp14>MUST</bcp14> discard the access
	    token. If this was an interaction with the authz-info endpoint endpoint, the RS MUST
	    <bcp14>MUST</bcp14> also
	    respond with an error message using a response code equivalent to the
	    CoAP code 4.01 (Unauthorized).</t>
      </list>
      </t> (Unauthorized).</li>
          </ul>
        </section>
      </section>
  </section><!--AS
      <!--AS information-->

<section anchor="authorizationGrants" title="Authorization Grants"> 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"/> target="RFC6749" format="default"/> defines four grant types. The grant types can
  be split up into two groups, 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 <xref target="RFC7521"/> defining an assertion-based authorization grant.</t> 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, 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"/>. target="RFC8628" format="default"/>.  In cases where the client
  acts autonomously autonomously, the client credentials grant is recommended.</t>
        <t>For details on the different grant types, see section 1.3 of <xref
  target="RFC6749"/>. 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
  MAY
  <bcp14>MAY</bcp14> define additional grant types, if needed.</t>
      </section>
      <!--Grants-->

<section anchor="clientCredentials" title="Client Credentials"> 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 one two client credential type types in section 2.3.1 of
  <xref target="RFC6749"/>: target="RFC6749" sectionFormat="of" section="2.3.1"/>: client id and client secret. <xref
  target="I-D.erdtman-ace-rpcc"/> target="I-D.erdtman-oauth-rpcc" format="default"/> adds raw-public-key raw public key and pre-shared-key pre-shared key to the
  client credentials types.  Profiles of this framework MAY <bcp14>MAY</bcp14> extend with
  an additional client credentials type using client certificates.</t>
      </section>
      <!--Client Credentials-->

<section anchor="ASAuthentication" title="AS Authentication"> numbered="true" toc="default">
        <name>AS Authentication</name>
        <t>The client credential 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 MUST <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" title="The numbered="true" toc="default">
        <name>The Authorization Endpoint"> Endpoint</name>
        <t>The OAuth 2.0 authorization endpoint is used to interact with the resource owner
  and obtain an authorization grant, 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.  Non-constrained  Nonconstrained clients interacting
  with constrained resource servers can use the specification in section 3.1
  of
  <xref target="RFC6749"/> target="RFC6749" sectionFormat="of" section="3.1"/> and the attack countermeasures suggested in
  section 4.2 of
  <xref target="RFC6819"/>.</t> target="RFC6819" sectionFormat="of" section="4.2"/>.</t>
      </section>
      <!--The 'Authorize' Endpoint-->

<section anchor="tokenEndpoint" title="The numbered="true" toc="default">
        <name>The Token Endpoint"> 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 to
  establish shared keys or to exchange their public keys.  Furthermore,
  this framework defines encodings using CBOR, CBOR as a substitute for JSON.</t>
        <t>The endpoint may also be exposed over HTTPS HTTPS, as in classical OAuth or
  even other transports.  A profile MUST <bcp14>MUST</bcp14> define the details of the mapping
  between the fields described below, 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 MUST <bcp14>MUST</bcp14> be authenticated
  and present a valid grant for the scopes requested.  Profiles of this
  framework MUST <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"/>.</t> target="oauthProfile" format="default"/>.</t>
        <t>The default name of this endpoint in an a url-path SHOULD <bcp14>SHOULD</bcp14> be '/token'.
  However, implementations are not required to use this name and can define
  their own instead.</t>
        <t>The figures of this section use CBOR diagnostic
  notation without the integer abbreviations for the parameters or their
  values for illustrative purposes. Note that implementations MUST <bcp14>MUST</bcp14> use the
  integer abbreviations and the binary CBOR encoding, encoding if the CBOR encoding is used.</t>
        <section anchor="tokenRequest" title="Client-to-AS Request"> 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 MUST <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 4 Section <xref target="RFC6749" section="4" sectionFormat="bare"/> of the OAuth 2.0 specification
    <xref target="RFC6749"/>, target="RFC6749" format="default"/>, depending on the grant type, with the following
    exceptions and additions:

    <list style="symbols">
      <t>The
          </t>
          <ul spacing="normal">
            <li>The parameter "grant_type" is OPTIONAL <bcp14>OPTIONAL</bcp14> in the context
	    of this framework (as opposed to REQUIRED <bcp14>REQUIRED</bcp14> in RFC6749). <xref
	    target="RFC6749" format="default"/>).  If that parameter is
	    missing, the default value "client_credentials" is implied.</t>
      <t>The implied.</li>
            <li>The "audience" parameter from <xref target="RFC8693"/> target="RFC8693"
	    format="default"/> is OPTIONAL <bcp14>OPTIONAL</bcp14> to
	    request an access token bound to a specific audience.</t>
      <t>The audience.</li>
            <li>The "cnonce" parameter defined in <xref target="cnonceParamToken"/> target="cnonceParamToken"
	    format="default"/> is
      REQUIRED
	    <bcp14>REQUIRED</bcp14> if the RS provided a client-nonce in the "AS
	    Request Creation
	    Hints" message <xref target="asInfo"/></t>
      <t>The (<xref target="asInfo" format="default"/>).</li>
            <li>The "scope" parameter MAY <bcp14>MAY</bcp14> be encoded as a byte string
	    instead of
	    the string encoding specified in section 3.3 of <xref target="RFC6749"/>, 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.</t>
      <t>The
	    scope-tokens.</li>
            <li>The client can send an empty (null value) "ace_profile" parameter to
	    indicate that it wants the AS to include the "ace_profile" parameter in
      the response.  See <xref target="paramProfile"/>.</t>
      <t>A target="paramProfile" format="default"/>.</li>
            <li>A client MUST <bcp14>MUST</bcp14> be able to use the parameters from <xref
      target="I-D.ietf-ace-oauth-params"/> target="RFC9201" format="default"/> in an access token request to the
      token endpoint endpoint, and the AS MUST <bcp14>MUST</bcp14> be able to process these additional
      parameters.</t>
    </list></t>
      parameters.</li>
          </ul>
          <t>The default behavior, 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 re-use reuse a key previously established with the RS, the client is
    supposed to use the "req_cnf" parameter from <xref
    target="I-D.ietf-ace-oauth-params"/>. target="RFC9201" format="default"/>.
          </t>
          <t>If CoAP is used used, then these parameters MUST <bcp14>MUST</bcp14> be provided in a CBOR map,
    see map
    (see <xref target="fig:cborTokenParameters"/>.</t> target="table_cborTokenParameters" format="default"/>).</t>
          <t>When HTTP is used as a transport transport, then the client makes a
    request to the token endpoint, endpoint; the parameters MUST <bcp14>MUST</bcp14> be encoded as defined
    in Appendix B of <xref target="RFC6749"/>.</t> 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"/> target="fig_symmATreq" format="default"/> shows a request for a token
    with a symmetric proof-of-possession key.  The content is displayed in
    CBOR diagnostic notation, without abbreviations for better readability.
          </t>
          <figure align="center" anchor="fig:symmATreq"
            title="Example request anchor="fig_symmATreq">
            <name>Example Request for an access token bound Access Token Bound to a
		   symmetric key.">
        <artwork align="left"><![CDATA[ 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" : "myclient",
  "audience" : "tempSensor4711"
}
        ]]></artwork>
    </figure></t>
]]></sourcecode>
          </figure>
          <t><xref target="fig:asymmATreq"/> target="fig_asymmATreq" format="default"/> shows a request for a token
	  with an
	  asymmetric proof-of-possession key.  Note that that, in this example example, OSCORE
	  <xref target="RFC8613"/> target="RFC8613" format="default"/> is used
	  to provide object-security, therefore 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 that, in this example example, the audience
	  is implicitly known by both the client and AS. Furthermore Furthermore, note that this
	  example uses the "req_cnf" parameter from <xref
    target="I-D.ietf-ace-oauth-params"/>. target="RFC9201"
	  format="default"/>.
          </t>
          <figure align="center" anchor="fig:asymmATreq"
            title="Example token request bound anchor="fig_asymmATreq">
            <name>Example Token Request Bound to an asymmetric key.">
        <artwork align="left"><![CDATA[ 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" : "myclient",
  "req_cnf" : {
    "COSE_Key" : {
      "kty" : "EC",
      "kid" : h'11',
      "crv" : "P-256",
      "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
      "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'
    }
  }
}
        ]]></artwork>
    </figure></t>
        ]]></sourcecode>
          </figure>
          <t><xref target="fig:kidATreq"/> target="fig_kidATreq" format="default"/> shows a request for a token
    where a previously communicated proof-of-possession key is only
    referenced using the "req_cnf" parameter from
    <xref target="I-D.ietf-ace-oauth-params"/>. target="RFC9201" format="default"/>.

          </t>
          <figure align="center" anchor="fig:kidATreq"
            title="Example request anchor="fig_kidATreq">
            <name>Example Request for an access token bound Access Token Bound to a
		   key reference.">
        <artwork align="left"><![CDATA[ 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" : "myclient",
  "audience" : "valve424",
  "scope" : "read",
  "req_cnf" : {
    "kid" : b64'6kg0dXJM13U'
  }
}
       ]]></artwork>
    </figure></t>
       ]]></sourcecode>
          </figure>
          <t>Refresh tokens are typically not stored as securely as
	  proof-of-possession keys in requesting clients.  Proof-of-possession based  Proof-of-possession-based
	  refresh token requests MUST NOT <bcp14>MUST NOT</bcp14> request different
	  proof-of-possession keys
	  or different audiences in token requests.  Refresh token requests can only
    use 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" title="AS-to-Client Response"> 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 response, as
    described in <xref
    target="errorsToken"/>.</t> 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"/>).
	  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"/>. target="RFC7591" format="default"/>.  If the client has requested a
	  specific
	  proof-of-possession key using the "req_cnf" parameter from
	  <xref target="I-D.ietf-ace-oauth-params"/>, 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 MUST <bcp14>MUST</bcp14> be encoded as a CBOR map, map;
	  when using
    HTTP
	  HTTP, the encoding is a JSON map map, as specified in section 5.1 of <xref
    target="RFC6749"/>. target="RFC6749"
	  sectionFormat="of" section="5.1"/>.  In both cases cases, the parameters specified
	  in Section 5.1
    of <xref target="RFC6749"/> target="RFC6749" sectionFormat="of" section="5.1"/> are used, with
	  the following additions and
    changes:

    <list style="hanging">
	<t hangText="ace_profile:"><vspace blankLines="0"/>
	OPTIONAL 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 ace_profile parameter parameter,
	    in which case it is MANDATORY.  This indicates the profile that the
	    client MUST <bcp14>MUST</bcp14> use towards the RS. See <xref target="paramProfile"/>
	    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.</t>

	<t hangText="token_type:"><vspace blankLines="0"/> RS.</dd>
<!--[rfced] We changed 'required' to REQUIRED because it seems to
be a direct mention of what appeared in RFC 6749. If this is not accurate,
please let us know.

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

Current:
   token_type:
         This parameter is OPTIONAL, as opposed to REQUIRED in
         [RFC6749].
-->
            <dt>token_type:</dt>
            <dd>This parameter is <bcp14>OPTIONAL</bcp14>, as opposed to
	    <bcp14>REQUIRED</bcp14> in
	    <xref target="RFC6749"/>. target="RFC6749" format="default"/>. By default default, implementations of
	    this framework
	SHOULD
	    <bcp14>SHOULD</bcp14> assume that the token_type is "PoP".  If a specific
	    use case
	    requires another token_type (e.g., "Bearer") to be used used, then this
	    parameter is REQUIRED.
	</t>
      </list>
    </t>

    <t>Furthermore <bcp14>REQUIRED</bcp14>.
	    </dd>
          </dl>
          <t>Furthermore, <xref target="I-D.ietf-ace-oauth-params"/> target="RFC9201" format="default"/> defines
	  additional parameters that the AS MUST <bcp14>MUST</bcp14> be able to use when
	  responding to a request to the token endpoint.</t>
          <t><xref target="fig:rsinfo"/> target="table_rsinfo" format="default"/> summarizes the parameters that
	  can currently be part of the Access Information. Future extensions
	  may define additional parameters.

      <figure align="center" anchor="fig:rsinfo"
              title="Access parameters.</t>
          <table anchor="table_rsinfo">
            <name>Access Information parameters">
      <artwork align="left"><![CDATA[
        /-------------------+-------------------------------\
        | Parameter name    | Specified in                  |
        |-------------------+-------------------------------|
        | access_token      |  RFC 6749                     |
        | token_type        |  RFC 6749                     |
        | expires_in        |  RFC 6749                     |
        | refresh_token     |  RFC 6749                     |
        | scope             |  RFC 6749                     |
        | state             |  RFC 6749                     |
        | error             |  RFC 6749                     |
        | error_description |  RFC 6749                     |
        | error_uri         |  RFC 6749                     |
        | ace_profile       | [this document]               |
        | cnf               | [I-D.ietf-ace-oauth-params]   |
        | rs_cnf           | [I-D.ietf-ace-oauth-params]   |
        \-------------------+-------------------------------/
      ]]></artwork></figure>

    </t> Parameters</name>
	    <thead>
	      <tr>
		<th>Parameter name</th>
		<th>Specified in</th>
	      </tr>
            </thead>
	    <tbody>
	      <tr>
		<td>access_token</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>token_type</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>expires_in</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>refresh_token</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>scope</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>state</td>
		<td><xref target="RFC6749" format="default"/></td>
              </tr>
	      <tr>
		<td>error</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>error_description</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>error_uri</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>ace_profile</td>
		<td>RFC 9200</td>
	      </tr>
	      <tr>
		<td>cnf</td>
		<td><xref target="RFC9201" format="default"/></td>
	      </tr>
	      <tr>
		<td>rs_cnf</td>
		<td><xref target="RFC9201" format="default"/></td>
	      </tr>
	    </tbody>
	  </table>
          <t><xref target="fig:symmATres"/> target="fig_symmATres" format="default"/> shows a response containing a token
    and a "cnf" parameter with a symmetric proof-of-possession key, which
    is defined in <xref target="I-D.ietf-ace-oauth-params"/>. target="RFC9201" format="default"/>.  Note that
    the key identifier 'kid' 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 align="center" anchor="fig:symmATres"
            title="Example anchor="fig_symmATres">
            <name>Example AS response Response with an access token bound Access Token Bound to a
		   symmetric key.">
      <artwork align="left"><![CDATA[ Symmetric Key</name>
            <sourcecode name="" type="cbor-diag"><![CDATA[
Header: Created (Code=2.01)
Content-Format: "application/ace+cbor"
Payload:
{
  "access_token" : b64'SlAV32hkKG ...
   (remainder of CWT omitted for brevity;
   CWT contains COSE_Key in the "cnf" claim)',
  "ace_profile" : "coap_dtls",
  "expires_in" : "3600",
  "cnf" : {
    "COSE_Key" : {
      "kty" : "Symmetric",
      "kid" : b64'39Gqlw',
      "k" : b64'hJtXhkV8FJG+Onbc6mxCcQh'
    }
  }
}
      ]]></artwork>
    </figure></t>
      ]]></sourcecode>
          </figure>
        </section>
        <section anchor="errorsToken" title="Error Response"> 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 Section 5.2 of <xref target="RFC6749"/>, target="RFC6749" sectionFormat="of" section="5.2"/>,
    with the following exceptions:

      <list style="symbols">
        <t>When

          </t>
          <ul spacing="normal">
            <li>When using CoAP CoAP, the payload MUST <bcp14>MUST</bcp14> be encoded as a CBOR
	    map, with
	    the Content-Format "application/ace+cbor".  When using HTTP HTTP, the
            payload is encoded in JSON JSON, as specified in section 5.2 of <xref
        target="RFC6749"/>.</t>

        <t>A target="RFC6749"
	    sectionFormat="of" section="5.2"/>.</li>
            <li>A response code equivalent to the CoAP code 4.00 (Bad Request) MUST
	    <bcp14>MUST</bcp14>
	    be used for all error responses, except for invalid_client invalid_client, where a
	    response code equivalent to the CoAP code 4.01 (Unauthorized) MAY
	    <bcp14>MAY</bcp14> be
	    used under the same conditions as specified in Section 5.2 of
	    <xref target="RFC6749"/>.</t>

	<t>The target="RFC6749" sectionFormat="of" section="5.2"/>.</li>
            <li>The parameters "error", "error_description" "error_description", and "error_uri" MUST <bcp14>MUST</bcp14>
	be abbreviated using the codes specified in <xref
	target="fig:cborTokenParameters"/>, target="table_cborTokenParameters" format="default"/>, when a CBOR encoding is used.</t>

	<t>The used.</li>
            <li>The error code (i.e., value of the "error" parameter) MUST <bcp14>MUST</bcp14> be
	abbreviated
	abbreviated, as specified in <xref
	target="fig:cborErrorCodes"/>, target="table_cborErrorCodes" format="default"/>, when a CBOR encoding is used.</t>
      </list>

      <figure align="center" anchor="fig:cborErrorCodes"
              title="CBOR 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 common error codes">
        <artwork align="left"><![CDATA[
        /---------------------------+-------------\
        | Name                      | 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 |
        |---------------------------+-------------|
        | invalid_request           |      1      |
        | invalid_client            |      2      |
        | invalid_grant             |      3      |
        | unauthorized_client       |      4      |
        | unsupported_grant_type    |      5      |
        | invalid_scope             |      6      |
        | unsupported_pop_key       |      7      |
        | incompatible_ace_profiles |      8      |
        \---------------------------+-------------/
        ]]></artwork>
      </figure>
    </t> for Common Error Codes

Current:
   Table 4: CBOR Abbreviations for Common Grant Types
Perhaps:
   Table 4: CBOR Values for Common Grant Types
-->
          <table anchor="table_cborErrorCodes">
            <name>CBOR Abbreviations for Common Error Codes</name>
            <thead>
	      <tr>
		<th>Name</th>
                <th>CBOR Values</th>
		<th>Original Specification</th>
	      </tr>
	    </thead>
	    <tbody>
	      <tr>
		<td>invalid_request</td>
		<td>1</td>
		<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td>
	      </tr>
	      <tr>
		<td>invalid_client</td>
		<td>2</td>
		<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td>
	      </tr>
	      <tr>
		<td>invalid_grant</td>
		<td>3</td>
		<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td>
	      </tr>
	      <tr>
		<td>unauthorized_client</td>
		<td>4</td>
		<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td>
	      </tr>
	      <tr>
		<td>unsupported_grant_type</td>
		<td>5</td>
		<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td>
	      </tr>
	      <tr>
		<td>invalid_scope</td>
		<td>6</td>
		<td><xref target="RFC6749" sectionFormat="of" section="5.2"/></td>
	      </tr>
	      <tr>
		<td>unsupported_pop_key</td>
		<td>7</td>
		<td>RFC 9200</td>
	      </tr>
	      <tr>
		<td>incompatible_ace_profiles</td>
		<td>8</td>
		<td>RFC 9200</td>
	      </tr>
	    </tbody>
	  </table>
          <t>In addition to the error responses defined in OAuth 2.0, the following
	  behavior MUST <bcp14>MUST</bcp14> be implemented by the AS:

    <list style="symbols">
      <t>If
          </t>
          <ul spacing="normal">
            <li>If the client submits an asymmetric key in the token request that the
	    RS cannot process, the AS MUST <bcp14>MUST</bcp14> reject that request with a
	    response code equivalent to the CoAP code 4.00 (Bad Request) Request), including the
	    error code "unsupported_pop_key" specified in
	    <xref target="fig:cborErrorCodes"/>.</t>

      <t>If 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 MUST <bcp14>MUST</bcp14> reject that request with
	    a response code equivalent to the CoAP code 4.00 (Bad Request) Request), including
	    the error code "incompatible_ace_profiles" specified in
	    <xref target="fig:cborErrorCodes"/>.</t>
    </list></t> target="table_cborErrorCodes" format="default"/>.</li>
          </ul>
        </section>
        <section anchor="tokenParams"
	   title="Request numbered="true" toc="default">
          <name>Request and Response Parameters"> 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" title="Grant Type"> numbered="true" toc="default">
            <name>Grant Type</name>
            <t>The abbreviations specified in the registry defined in
      <xref target="IANAGrantTypeMappings"/> MUST target="IANAGrantTypeMappings" format="default"/> <bcp14>MUST</bcp14> be
      used in CBOR encodings instead of the string values defined
      in <xref target="RFC6749"/>, target="RFC6749" format="default"/> if CBOR payloads are used.

      <figure align="center" anchor="fig:grant_types"
              title="CBOR abbreviations

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

  <section anchor="tokenCborParams" title="Mapping numbered="true" toc="default">
          <name>Mapping Parameters to CBOR"> CBOR</name>
          <t>If CBOR encoding is used, all OAuth parameters in access token requests
    and responses MUST <bcp14>MUST</bcp14> be mapped to CBOR types types, as specified in the registry
    defined by <xref target="IANAOAuthParameterMappingsRegistry"/>, 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"/>.</t> target="RFC8392" format="default"/>.</t>
          <t>Note also that abbreviations from -24 to 23 have a 1 byte 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>

    <t>
      <figure align="center" anchor="fig:cborTokenParameters"
              title="CBOR mappings used
          <table anchor="table_cborTokenParameters">
            <name>CBOR Mappings Used in token requests Token Requests and responses">
        <artwork align="left"><![CDATA[
        /-------------------+----------+---------------------\
        | Name              | CBOR Key | Value Type          |
        |-------------------+----------+---------------------|
        | access_token      | 1        | byte string         |
        | expires_in        | 2        | unsigned integer    |
        | audience          | 5        | text string         |
        | scope             | 9        | text Responses</name>
            <thead>
	      <tr>
		<th>Name</th>
		<th>CBOR Key</th>
		<th>Value Type</th>
		<th>Original Specification</th>
	      </tr>
	    </thead>
	    <tbody>
	      <tr>
		<td>access_token</td>
		<td>1</td>
		<td>byte string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>expires_in</td>
		<td>2</td>
		<td>unsigned integer</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>audience</td>
		<td>5</td>
		<td>text string</td>
		<td><xref target="RFC8693" format="default"/></td>
	      </tr>
	      <tr>
		<td>scope</td>
		<td>9</td>
		<td>text or byte string |
        | client_id         | 24       | text string         |
        | client_secret     | 25       | byte string         |
        | response_type     | 26       | text string         |
        | redirect_uri      | 27       | text string         |
        | state             | 28       | text string         |
        | code              | 29       | byte string         |
        | error             | 30       | integer             |
        | error_description | 31       | text string         |
        | error_uri         | 32       | text string         |
        | grant_type        | 33       | unsigned integer    |
        | token_type        | 34       | integer             |
        | username          | 35       | text string         |
        | password          | 36       | text string         |
        | refresh_token     | 37       | byte string         |
        | ace_profile       | 38       | integer             |
        | cnonce            | 39       | byte string         |
        \-------------------+----------+---------------------/
      ]]></artwork>
    </figure>
  </t> string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>client_id</td>
		<td>24</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>client_secret</td>
		<td>25</td>
		<td>byte string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>response_type</td>
		<td>26</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>redirect_uri</td>
		<td>27</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>state</td>
		<td>28</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>code</td>
		<td>29</td>
		<td>byte string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>error</td>
		<td>30</td>
		<td>integer</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>error_description</td>
		<td>31</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>error_uri</td>
		<td>32</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>grant_type</td>
		<td>33</td>
		<td>unsigned integer</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>token_type</td>
		<td>34</td>
		<td>integer</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>username</td>
		<td>35</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>password</td>
		<td>36</td>
		<td>text string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>refresh_token</td>
		<td>37</td>
		<td>byte string</td>
		<td><xref target="RFC6749" format="default"/></td>
	      </tr>
	      <tr>
		<td>ace_profile</td>
		<td>38</td>
		<td>integer</td>
		<td>RFC 9200</td>
	      </tr>
	      <tr>
		<td>cnonce</td>
		<td>39</td>
		<td>byte string</td>
		<td>RFC 9200</td>
	      </tr>
	    </tbody>
	  </table>
        </section>
      </section>
</section><!--
      <!-- Token endpoint -->

<section anchor="introspectionEndpoint" title="The numbered="true" toc="default">
        <name>The Introspection Endpoint"> Endpoint</name>
        <t>Token introspection <xref target="RFC7662"/> MAY target="RFC7662" format="default"/> <bcp14>MAY</bcp14>
	be implemented by the AS, AS and the RS. When implemented, it MAY <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"/> 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.</t>
        <t>Communication between the requesting entity and the introspection endpoint
  at the AS MUST <bcp14>MUST</bcp14> be integrity protected and encrypted.  The communication
  security protocol MUST <bcp14>MUST</bcp14> also provide a binding between requests and
  responses.  Furthermore, the two interacting parties MUST <bcp14>MUST</bcp14> perform mutual
  authentication.  Finally, the AS SHOULD <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 MUST <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 an a url-path SHOULD <bcp14>SHOULD</bcp14> be '/introspect'.
  However, implementations are not required to use this name and can define
  their own instead.</t>
        <t>The figures of this section use the CBOR diagnostic
  notation without the integer abbreviations for the parameters and their
  values for better readability.
        </t>
        <section anchor="introReq" title="Introspection Request"> 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 MUST <bcp14>MUST</bcp14> specify how the communication is protected.
    If CoAP is used, the payload MUST <bcp14>MUST</bcp14> be encoded as a CBOR map with a "token"
    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 MAY <bcp14>MAY</bcp14> be included.</t>
          <t>For CoAP-based interaction, all messages MUST <bcp14>MUST</bcp14> use the content
	  type "application/ace+cbor". For HTTP HTTP, the encoding defined in section 2.1
    of
	  <xref target="RFC7662"/> target="RFC7662" sectionFormat="of" section="2.1"/> is used.</t>
          <t>The same parameters are required and optional as in Section 2.1
    of
	  <xref target="RFC7662"/>.</t> target="RFC7662" sectionFormat="of" section="2.1"/>.</t>
          <t>For example, <xref target="fig:introReq"/> 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"/> target="RFC8613" format="default"/> is assumed in this example,
    therefore example;
	  therefore, the Content-Format is "application/oscore". <xref
    target="fig:introReq-payl"/>
	  target="fig_introReq-payl" format="default"/> shows the decoded payload. payload.</t>
          <figure align="center" anchor="fig:introReq"
            title="Example introspection request.">
        <artwork align="left"><![CDATA[ anchor="fig_introReq">
            <name>Example Introspection Request</name>
            <sourcecode name="" type="cbor-diag"><![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 ...
       ]]></artwork>
       ]]></sourcecode>
          </figure>
          <figure align="center" anchor="fig:introReq-payl"
            title="Decoded payload.">
        <artwork align="left"><![CDATA[ anchor="fig_introReq-payl">
            <name>Decoded Payload</name>
            <sourcecode name="" type="cbor-diag"><![CDATA[
{
  "token" : b64'7gj0dXJQ43U',
  "token_type_hint" : "PoP"
}
       ]]></artwork>
    </figure></t>
       ]]></sourcecode>
          </figure>
        </section>
        <section anchor="introRes" title="Introspection Response"> 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 authorized,
	  or couldn't be processed processed, the AS returns an error response response, as described in
	  <xref target="errorsIntro"/>.</t> target="errorsIntro" format="default"/>.</t>
          <t>In a successful response, the AS encodes the response parameters in
	  a map.  If CoAP is used, this MUST <bcp14>MUST</bcp14> be encoded as a CBOR map, map; if
	  HTTP is
    used used, the JSON encoding specified in section 2.2 of <xref target="RFC7662"/> target="RFC7662"
	  sectionFormat="of" section="2.2"/>
	  is used.  The map containing the response payload  includes the same
	  required and optional parameters as in Section 2.2 of
	  <xref target="RFC7662"/> target="RFC7662" sectionFormat="of" section="2.2"/>, with the following additions:

    <list style="hanging">
        <t hangText="ace_profile">
	OPTIONAL.
	  additions:</t>
          <dl newline="true" spacing="normal">
            <dt>ace_profile:</dt>
            <dd>This parameter is <bcp14>OPTIONAL</bcp14>.  This indicates the profile that
	    the RS MUST <bcp14>MUST</bcp14> use with the
	    client.  See <xref target="paramProfile"/> 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.</t>
	<t hangText="cnonce">
	  OPTIONAL.  A client.</dd>
            <dt>cnonce:</dt>
            <dd>This parameter is <bcp14>OPTIONAL</bcp14>.  This is a
	    client-nonce provided to the AS by the client.
	    The RS MUST <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"/> target="asInfo" format="counter"/> and
	    <xref target="cnonceParamToken"/>.
	</t>
	<t hangText="exi">
	  OPTIONAL. The 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>cti:</dt>
	    <dd>This parameter is <bcp14>OPTIONAL</bcp14>.  This is the "cti" claim associated to
	    this access token.
	    This parameter has the same meaning and processing rules as the
	    "jti" parameter defined in <xref target="RFC7662" sectionFormat="of"
	    section="3.1.2"/> except that its value is a byte string when encoded
	    in CBOR and is the base64url encoding of this byte string without
	    padding when encoded in JSON <xref target="RFC4648"
	    format="default"/>.</dd>
            <dt>exi:</dt>
            <dd>This parameter is <bcp14>OPTIONAL</bcp14>. This is the
	    "expires-in" claim associated to this access token.
	    See <xref target="tokenExpiration"/>.
	</t>
    </list>
    </t>

    <t>Furthermore target="tokenExpiration" format="default"/>.
	    </dd>
          </dl>
          <t>Furthermore, <xref target="I-D.ietf-ace-oauth-params"/> target="RFC9201" format="default"/> defines
    more parameters that the AS MUST <bcp14>MUST</bcp14> be able to use when responding to a
    request to the introspection endpoint.</t>
          <t>For example, <xref target="fig:introRes"/> target="fig_introRes" format="default"/> shows an AS
    response to the introspection request in <xref target="fig:introReq"/>. target="fig_introReq" format="default"/>.
    Note that this example contains the "cnf" parameter defined in
    <xref target="I-D.ietf-ace-oauth-params"/>. target="RFC9201" format="default"/>.

          </t>
          <figure align="center" anchor="fig:introRes"
            title="Example introspection response.">
      <artwork align="left"><![CDATA[ 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" : true,
  "scope" : "read",
  "ace_profile" : "coap_dtls",
  "cnf" : {
    "COSE_Key" : {
      "kty" : "Symmetric",
      "kid" : b64'39Gqlw',
      "k" : b64'hJtXhkV8FJG+Onbc6mxCcQh'
    }
  }
}
      ]]></artwork>
    </figure></t>
      ]]></sourcecode>
          </figure>
        </section>
        <section anchor="errorsIntro" title="Error Response"> 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 interactions, as defined in
    Section 2.3 of
	  <xref target="RFC7662"/>, target="RFC7662" sectionFormat="of" section="2.3"/>, with the
	  following differences:

    <list style="symbols">
      <t>If differences:</t>
          <ul spacing="normal">
            <li>If content is sent and CoAP is used used, the payload MUST <bcp14>MUST</bcp14> be
	    encoded as a
	    CBOR map and the Content-Format "application/ace+cbor" MUST <bcp14>MUST</bcp14>
	    be used.
	    For HTTP HTTP, the encoding defined in section 2.3 of <xref target="RFC6749"/> target="RFC6749" sectionFormat="of"
	    section="2.3"/> is used.</t>

      <t>If used.</li>
            <li>If the credentials used by the requesting entity (usually the RS)
	    are invalid invalid, the AS MUST <bcp14>MUST</bcp14> respond with the response code
	    equivalent to the
	    CoAP code 4.01 (Unauthorized) and use the required and optional
	    parameters from Section 2.3 in <xref target="RFC7662"/>.</t>

      <t>If 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 MUST <bcp14>MUST</bcp14> respond with a response code
      equivalent to the CoAP code 4.03 (Forbidden).  In this case case, no payload is
      returned.</t>

      <t>The
      returned.</li>
            <li>The parameters "error", "error_description" "error_description", and "error_uri" MUST <bcp14>MUST</bcp14>
      be abbreviated using the codes specified in <xref
      target="fig:cborTokenParameters"/>.</t>

      <t>The target="table_cborTokenParameters" format="default"/>.</li>
            <li>The error codes MUST <bcp14>MUST</bcp14> be abbreviated using the codes specified in
      the registry defined by <xref target="IANAErrorCBORMappings"/>.</t>
    </list>
    </t> 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 MUST <bcp14>MUST</bcp14> instead
    respond with an introspection response with the "active" field set to
    "false".</t>
        </section>
        <section anchor="introParamsCbor"
	   title="Mapping numbered="true" toc="default">
          <name>Mapping Introspection Parameters to CBOR"> CBOR</name>
          <t>If CBOR is used, the introspection request and response parameters MUST <bcp14>MUST</bcp14>
    be mapped to CBOR types types, as specified in the registry defined by <xref
    target="IANAIntrospectionEndpointCBORMappingsRegistry"/>, 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"/> target="RFC8392" format="default"/>
    and the abbreviations of parameters with the same name from
    <xref target="tokenCborParams"/>.

    <figure align="center" anchor="fig:cborIntrospectionParameters"
            title="CBOR target="tokenCborParams" format="default"/>.
          </t>
          <table anchor="table_cborIntrospectionParameters">
            <name>CBOR Mappings to for Token Introspection Parameters.">
      <artwork align="left"><![CDATA[
    /-------------------+----------+-------------------------\
    | Parameter name    | CBOR Key | Value Type              |
    |-------------------+----------+-------------------------|
    | iss               | 1        | text string             |
    | sub               | 2        | text string             |
    | aud               | 3        | text string             |
    | exp               | 4        | integer 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>iss</td>
		<td>1</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>sub</td>
		<td>2</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>aud</td>
		<td>3</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>exp</td>
		<td>4</td>
		<td>integer or              |
    |                   |          | floating-point number |
    | nbf               | 5        | integer number</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>nbf</td>
		<td>5</td>
		<td>integer or              |
    |                   |          | floating-point number |
    | iat               | 6        | integer number</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>iat</td>
		<td>6</td>
		<td>integer or              |
    |                   |          | floating-point number |
    | cti               | 7        | byte string             |
    | scope             | 9        | text or byte string     |
    | active            | 10       | True number</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>cti</td>
		<td>7</td>
		<td>byte string</td>
		<td>RFC 9200</td>
	      </tr>
	      <tr>
		<td>scope</td>
		<td>9</td>
		<td>text or False           |
    | token             | 11       | byte string             |
    | client_id         | 24       | text string             |
    | error             | 30       | integer                 |
    | error_description | 31       | text string             |
    | error_uri         | 32       | text string             |
    | token_type_hint   | 33       | text string             |
    | token_type        | 34       | integer                 |
    | username          | 35       | text string             | string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>active</td>
		<td>10</td>
		<td>True or False</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>token</td>
		<td>11</td>
		<td>byte string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>client_id</td>
		<td>24</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>error</td>
		<td>30</td>
		<td>integer</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>error_description</td>
		<td>31</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>error_uri</td>
		<td>32</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>token_type_hint</td>
		<td>33</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>token_type</td>
		<td>34</td>
		<td>integer</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>username</td>
		<td>35</td>
		<td>text string</td>
		<td><xref target="RFC7662" format="default"/></td>
	      </tr>
	      <tr>
		<td>ace_profile</td>
		<td>38</td>
		<td>integer</td>
		<td>RFC 9200</td>
	      </tr>
	      <tr>
		<td>cnonce</td>
		<td>39</td>
		<td>byte string</td>
		<td>RFC 9200</td>
	      </tr>
<!-- [rfced] For exi's type, the word "unsigned" has been removed because
it does not appear in the IANA registry. Please review and let us know if
this should be handled otherwise.

Original:
    | ace_profile exi               | 38 40       | unsigned integer                 |
    | cnonce            | 39       | byte string             |  |[this document]|

Current:
    | exi               | 40   | unsigned integer              |
    \-------------------+----------+-------------------------/
        ]]></artwork>
      </figure>
    </t> RFC 9200      |
-->
	      <tr>
		<td>exi</td>
		<td>40</td>
		<td>integer</td>
		<td>RFC 9200</td>
	      </tr>
	    </tbody>
	  </table>
        </section>
      </section>

</section><!--
      <!-- introspection endpoint -->

<section anchor="accessToken" title="The numbered="true" toc="default">
        <name>The Access Token"> Token</name>
        <t>In this framework framework, the use of CBOR Web Token (CWT) as
    specified in <xref target="RFC8392"/> target="RFC8392" format="default"/> is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.
        </t>
        <t>In order to facilitate offline processing of access tokens,
  this document uses the "cnf" claim from <xref
  target="RFC8747"/> target="RFC8747" format="default"/> and the "scope" claim from <xref target="RFC8693"/> target="RFC8693" format="default"/> for
  JWT- and CWT-encoded tokens.  In addition to string encoding specified for
  the "scope" claim, a binary encoding MAY <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 MAY <bcp14>MAY</bcp14> include an
  "ace_profile" claim in the access token, with the same syntax and semantics
  as defined in <xref target="paramProfile"/>.</t> target="paramProfile" format="default"/>.</t>
        <t>If the client submitted a client-nonce parameter in the access token
	request <xref target="cnonceParamToken"/>, (<xref target="cnonceParamToken" format="default"/>), the AS MUST
	<bcp14>MUST</bcp14> include the value of
	this parameter in the "cnonce" claim specified here.  The "cnonce" claim
	uses binary encoding.</t>
        <section anchor="tokenAuthInfoEndpoint"
	   title="The numbered="true" toc="default">
          <name>The Authorization Information Endpoint"> 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 protocol, such as CoAP. Profiles of this framework MAY <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 MUST <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 MUST media type <bcp14>MUST</bcp14> reflect the format of the token,
  e.g. application/cwt
  e.g., "application/cwt", for CBOR Web Tokens, Tokens; if no Content-Format or Media
  Type media
  type is defined for the token format, application/octet-stream MUST "application/octet-stream" <bcp14>MUST</bcp14> be
  used.</t>
          <t>The RS receiving the token MUST <bcp14>MUST</bcp14> verify the validity of the
	  token.  If the
	  token is valid, the RS MUST <bcp14>MUST</bcp14> respond to the POST request with a
	  response code equivalent to CoAP's CoAP code 2.01 (Created).
  <xref target="verifyToken"/> target="verifyToken" format="default"/> outlines how an RS MUST <bcp14>MUST</bcp14> proceed to verify the
  validity of an access token.</t>
          <t>The RS MUST <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, request and
  therefore not stored at the RS.</t>
          <t>When using this framework framework, it is RECOMMENDED <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, 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 server, as it must consider every access token and calculate the
	  actual permissions of the client.  Also, tokens may contradict each other 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 MUST <bcp14>MUST</bcp14> respond with a response code equivalent to the CoAP
  code 4.00 (Bad Request).</t>
          <t>The RS MAY <bcp14>MAY</bcp14> make an introspection request to validate the token before
  responding to the POST request to the authz-info endpoint, e.g. 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 MUST <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 allow 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 an a url-path is '/authz-info',
  however '/authz-info';
	  however, implementations are not required to use this name and can define
	  their own instead.</t>
          <section anchor="verifyToken" title="Verifying numbered="true" toc="default">
            <name>Verifying an Access Token"> Token</name>
            <t>When an RS receives an access token, it MUST <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 COSE, while a JWT token uses JOSE. JSON Object Signing and Encryption (JOSE).
<!--[rfced] Should "token-by-reference" be "reference token" in this sentence?

Original:
   The type of token also has an influence on the verification
   procedure since tokens may be self-contained whereby token
   verification may happen locally at the RS while a token-by-reference
   requires further interaction with the authorization server, for
   example using token introspection, to obtain the claims associated
   with the token reference.
-->
    The type of token also has an
    influence on the verification procedure since tokens may be self-contained,
    whereby token verification may happen locally at the RS, while a
    token-by-reference requires further interaction with the authorization
    server, for example, using token introspection, to obtain the claims
    associated with the token reference.  Self-contained tokens MUST, <bcp14>MUST</bcp14> at
    least be integrity protected protected, but they MAY <bcp14>MAY</bcp14> also be encrypted.</t>
            <t>For self-contained tokens tokens, the RS MUST <bcp14>MUST</bcp14> process the security
	    protection of the token first, as specified by the respective token format.
	    For CWT CWT, the description can be found in <xref target="RFC8392"/> and target="RFC8392"
	    format="default"/>; for
    JWT
	    JWT, the relevant specification is <xref target="RFC7519"/>. target="RFC7519" format="default"/>.
	    This MUST <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 reference, the RS needs to obtain
    the claims first. When the RS uses token introspection introspection, the relevant
    specification is <xref target="RFC7662"/> target="RFC7662" format="default"/> with CoAP transport specified in
    <xref target="introspectionEndpoint"/>. target="introspectionEndpoint" format="default"/>. </t>
            <t>Errors may happen during this initial processing stage:
	<list style="symbols">

	  <t>If
            </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 MUST <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).</t>

	  <t>If
	  (Unauthorized).</li>
              <li>If the claims cannot be obtained obtained, the RS MUST <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).</t>
	</list>
	</t>
	  Request).</li>
            </ul>
            <t>Next, the RS MUST <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:

    <list style="hanging">
      <t hangText="iss">The
            </t>
            <dl newline="true" spacing="normal">
              <dt>iss</dt>
              <dd>The issuer claim (if present) must identify the AS that
	      has produced the security protection for the access token.  If that is
	      not the case case, the RS MUST <bcp14>MUST</bcp14> discard the token.  If this was an
	      interaction with authz-info, the RS MUST <bcp14>MUST</bcp14> also respond with a
	      response code equivalent
	      to the CoAP code 4.01 (Unauthorized).</t>
      <t hangText="exp">The (Unauthorized).</dd>
              <dt>exp</dt>
              <dd>The expiration date must be in the future.
	      If that is not the case case, the RS MUST <bcp14>MUST</bcp14> discard the token.  If
	      this was an
	      interaction with authz-info authz-info, the RS MUST <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. </t>
      <t hangText="aud">The </dd>
              <dt>aud</dt>
              <dd>The audience claim must refer to an audience that
	      the RS identifies with. If that is not the case case, the RS MUST <bcp14>MUST</bcp14>
	      discard the
	      token.  If this was an interaction with authz-info, the RS MUST
	      <bcp14>MUST</bcp14> also
	      respond with a response code equivalent to the CoAP code 4.03
      (Forbidden).</t>
      <t hangText="scope">The
	      (Forbidden).</dd>
              <dt>scope</dt>
              <dd>The RS must recognize value of the scope claim.
	      If that is not the case case, the RS MUST <bcp14>MUST</bcp14> discard the token.  If
	      this was an
	      interaction with authz-info, the RS MUST <bcp14>MUST</bcp14> also respond with a
	      response code
	      equivalent to the CoAP code 4.00 (Bad Request).  The RS MAY <bcp14>MAY</bcp14>
	      provide
	      additional information in the error response, response to clarify what
	      went wrong.</t>
    </list></t> 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 Subject (sub) 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 expires_in (exi) claim
    MUST
    <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  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 MAY <bcp14>MAY</bcp14> use the error
	    codes from
    Section 3.1 of <xref target="RFC6750"/>, target="RFC6750" sectionFormat="of" section="3.1"/> to
	    provide additional details to the client.</t>
          </section>
          <section anchor="protAuthzInfo" title="Protecting numbered="true" toc="default">
            <name>Protecting the Authorization Information Endpoint"> 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
            <t>Specifically, it SHOULD NOT <bcp14>SHOULD NOT</bcp14> be possible to perform GET, DELETE
	    DELETE, or PUT on the authz-info endpoint.</t>
            <t>The RS SHOULD <bcp14>SHOULD</bcp14> implement rate limiting rate-limiting measures to mitigate
	    attacks aiming
	    to overload the processing capacity of the RS by repeatedly submitting
	    tokens. For CoAP-based communication communication, the RS could use the mechanisms from
	    <xref target="RFC8516"/> target="RFC8516" format="default"/> to indicate that it is overloaded.</t>
          </section>
        </section>
        <section anchor="requestC2RS" title="Client numbered="true" toc="default">
          <name>Client Requests to the RS"> RS</name>
          <t>Before sending a request to an RS, the client MUST <bcp14>MUST</bcp14> verify that the keys
  used to protect this communication are still valid. See <xref
  target="keyExpiration"/> 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, client and the target resource
  requires authorization, the RS MUST <bcp14>MUST</bcp14> first verify that it has an access token
  that authorizes this request, request and that the client has performed the
  proof-of-possession binding for that token to the request.</t>
          <t>The response code MUST <bcp14>MUST</bcp14> be 4.01 (Unauthorized) in case the client has
  not performed the proof-of-possession, 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 MUST <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 MUST <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 dumb 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 available, which can be achieved only when the client is
  authenticated.</t>
          <t>Note: The RS MAY <bcp14>MAY</bcp14> use introspection for timely validation of an
  access token, token at the time when a request is presented.</t>
          <t>Note: Matching the claims of the access token (e.g., scope) to a specific
  request is application specific.</t>
          <t>If the request matches a valid token and the client has performed the
  proof-of-possession
  proof of possession for that token, the RS continues to process the request
  as specified by the underlying application.</t>
        </section>
        <section anchor="tokenExpiration" title="Token Expiration"> 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.  Here follows  The following is
	  a list of the possibilities including what functionality they require of the
	  RS.</t>

  <t><list style="symbols">
    <t>The
          <ul spacing="normal">
            <li>The token is a CWT and includes an "exp" claim and possibly the
	    "nbf" claim.  The RS verifies these by comparing them to values from
	    its internal clock clock, as defined in <xref target="RFC7519"/>. target="RFC7519" format="default"/>.  In
	    this
    case case, the RS's internal clock must reflect the current date and time, 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.</t>

    <t>The
	    specification.</li>
            <li>The RS verifies the validity of the token by performing an
	    introspection request request, as specified in <xref
    target="introspectionEndpoint"/>. 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).</t>

    <t>In 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 "exi" ("expires in") can be used, 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.
	    i.e., CWTs and JWTs. For CWTs CWTs, this parameter is encoded as an unsigned integer,
	    while JWTs encode this as JSON number.</t> number.</li>
            <li>
              <t> Processing this claim requires that the RS does the following:
    <list style="symbols">
      <t>For
              </t>
              <ul spacing="normal">
                <li>For each token the RS receives, receives that contains an "exi" claim:
      Keep claim,
		keep track of the time it received that token and revisit that list
		regularly to expunge expired tokens.</t> tokens.</li>
                <li>
                  <t>Keep track of the identifiers of tokens containing the "exi"
      claim that have expired (in order to avoid accepting them again).
      In order to avoid an unbounded memory usage growth, this MUST <bcp14>MUST</bcp14> be
      implemented in the following way when the "exi" claim is used:
      <list style="symbols">
	<t>When
                  </t>
                  <ul spacing="normal">
                    <li>When creating the token, the AS MUST <bcp14>MUST</bcp14> add a 'cti' claim (
	or 'jti' for JWTs) to the access token.  The value of this claim
	MUST
	<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 'exi' claim, issued by this AS for the
	RS.</t>
	<t>The
	RS.</li>
                    <li>The RS MUST <bcp14>MUST</bcp14> store the highest sequence number of an expired
	token containing the "exi" claim that it has seen, seen and treat
	tokens with lower sequence numbers as expired.  Note that
        this could lead to discarding valid tokens with lower sequence numbers, 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.</t>
      </list></t>
    </list></t>
  </list></t> time.</li>
                  </ul>
                </li>
              </ul>
            </li>
          </ul>
          <t>If a token that authorizes a long running request long-running request, such as a CoAP
  Observe <xref target="RFC7641"/> target="RFC7641" format="default"/>, expires, the RS MUST <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 long-running
  request.</t>
        </section>
        <section anchor="keyExpiration" title="Key Expiration"> 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, 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, 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 MUST <bcp14>MUST</bcp14> be used to
  inform the client about the validity of an access token:

  <list style="symbols">
    <t>The

          </t>
          <ul spacing="normal">
            <li>The client knows a default validity time for all tokens it is
    using (i.e. (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,
    AS or published by the AS in a way that the client can query.</t>
    <t>The query.</li>
            <li>The AS informs the client about the token validity using the
    "expires_in" parameter in the Access Information.</t>
  </list>
  </t> Information.</li>
          </ul>
          <t>A client that is not able to obtain information about the expiration of a
  token MUST NOT <bcp14>MUST NOT</bcp14> use this token.</t>
        </section>

</section><!--
      </section>
      <!-- access token -->

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

<section anchor="security" title="Security Considerations"> 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"/> target="RFC6749" format="default"/> apply
  to this work.  Furthermore  Furthermore, <xref target="RFC6819"/> target="RFC6819" format="default"/>
  provides additional security considerations for OAuth OAuth, which apply to IoT
  deployments as well.  If the introspection endpoint is used,
  the security considerations from <xref target="RFC7662"/> target="RFC7662" format="default"/> also apply.</t>
      <t>The following subsections address issues specific to this document and
  it's
      its use in constrained environments.</t>
      <section anchor="tokenProtection" title="Protecting Tokens"> 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
	digest, e.g., a Message Authentication Code (MAC) or an Authenticated
	Encryption with Associated Data (AEAD)
	algorithm.  Consequently, the token integrity protection MUST <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.
	proof of possession.  If the access token contains the symmetric key,
	this symmetric key MUST <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. (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
      Therefore, a token with a multi-recipient multirecipient audience MUST <bcp14>MUST</bcp14> be protected
      with an asymmetric signature.
      </t> 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 MUST NOT <bcp14>MUST NOT</bcp14> be used as a proof-of-possession key with
      multiple resource servers 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 SHOULD <bcp14>SHOULD</bcp14> scope these access tokens to a specific permission.</t>
        <t>In certain situations situations, it may be necessary to revoke an access
	token that is still valid.  Client-initiated revocation is specified
	in <xref target="RFC7009"/> 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, devices needing
	access tokens with relatively long lifetimes, lifetimes and would therefore
	necessitate further standardization work that is out of scope for
	this document.</t>
    </section><!--token
      </section>
      <!--token protection-->

    <section anchor="commSec" title="Communication Security"> numbered="true" toc="default">
        <name>Communication Security</name>
        <t>Communication with the authorization server MUST <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 eavesdropper,
      thereby completely negating proof-of-possession security.
      The requirements for communication security of profiles are specified
      in <xref target="oauthProfile"/>.</t> target="oauthProfile" format="default"/>.</t>
        <t>Additional protection for the access token can be applied by
	encrypting it, for example example, encryption of CWTs is specified in Section 5.1
      of
	<xref target="RFC8392"/>. target="RFC8392" sectionFormat="of" section="5.1"/>.  Such additional
	protection can be necessary
	if the token is later transferred over an insecure connection
      (e.g.
	(e.g., when it is sent to the authz-info endpoint).</t>
        <t>Care must by 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 techniques, and by using hardware
	security.</t>
    </section><!--communication
      </section>
      <!--communication security-->

    <section anchor="keys" title="Long-Term Credentials"> 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, communications and authenticate to the AS.  These credentials
      need to be protected against unauthorized access.  In constrained
      devices,
      devices deployed in publicly accessible places, such protection can
      be difficult to achieve without specialized hardware (e.g. (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 MUST NOT <bcp14>MUST NOT</bcp14> lead to a
      compromise of other credentials not linked to that device, therefore device; therefore,
      secret keys used for authentication MUST NOT <bcp14>MUST NOT</bcp14> be shared between more than
      two parties.</t>
        <t>Operators of the clients or RS SHOULD 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 SHOULD <bcp14>SHOULD</bcp14> have procedures for decommissioning devices, devices
      that include securely erasing credentials and other security critical security-critical
      material in the devices being decommissioned.</t>
    </section><!--credential
      </section>
      <!--credential livecycle-->

    <section anchor="unprotected-as-information"
	       title="Unprotected numbered="true" toc="default">
        <name>Unprotected AS Request Creation Hints"> 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"/>) target="asInfo" format="default"/>) are
	authentic. Therefore, the C
	therefore MUST
	<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" title="Minimal numbered="true" toc="default">
        <name>Minimal Security Requirements for Communication"> Communication</name>
        <t>This section summarizes the minimal requirements for the
	communication security of the different protocol interactions.

	<list style="hanging">
	  <t hangText="C-AS">All
        </t>
        <dl newline="true" spacing="normal">
          <dt>C-AS</dt>
          <dd>All communication between the client and the
	  Authorization Server MUST
	  authorization server <bcp14>MUST</bcp14> be encrypted, encrypted and integrity and
	  replay
	  protected. Furthermore Furthermore, responses from the AS to the client MUST <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 authorization server
	  have previously exchanged either a shared secret or their public
	  keys in order to negotiate a secure communication. Furthermore Furthermore, the
	  client MUST <bcp14>MUST</bcp14> be able to determine whether an AS has the authority
	  to issue access tokens for a certain RS.  This can can, for example example, be
	  done through pre-configured lists, preconfigured lists or through an online lookup
	  mechanism that in turn also must be secured.
	  </t>

	  <t hangText="RS-AS">The
	  </dd>
          <dt>RS-AS</dt>
          <dd>The communication between the Resource
	  Server resource
	  server and the Authorization Server authorization server via the introspection endpoint
	  MUST
	  <bcp14>MUST</bcp14> be encrypted, encrypted and integrity and replay protected. Furthermore Furthermore,
	  responses from the AS to the RS MUST <bcp14>MUST</bcp14> be bound to the RS's request.
	  This requires that the RS and the Authorization Server authorization server
	  have previously exchanged either a shared secret, secret or their public
	  keys in order to negotiate a secure communication. Furthermore Furthermore, the
	  RS MUST <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,
	  band but could also be performed through an online lookup mechanism mechanism,
	  provided that it is also secured in the same way.</t>

	  <t hangText="C-RS">The way.</dd>
          <dt>C-RS</dt>
          <dd>The initial communication between the client
	  and the Resource Server can not 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 authentication, it is RECOMMEND <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 MUST <bcp14>MUST</bcp14> be established between the
	  client and RS for the actual resource request.  This protocol MUST <bcp14>MUST</bcp14>
	  provide confidentiality, integrity integrity, and replay protection 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 or key, a shared
	  symmetric key from the claims in the token token, or an introspection
	  request.  Since ACE does not provide profile negotiation between the
	  C and RS, the client MUST <bcp14>MUST</bcp14> have learned what profile the RS
	  supports (e.g. (e.g., from the AS or pre-configured) preconfigured) and initiate initiated the
	  communication accordingly.</t>
	</list></t> accordingly.</dd>
        </dl>
      </section>
      <section anchor="nonce" title="Token numbered="true" toc="default">
        <name>Token Freshness and Expiration"> 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 (cnonce) defined in <xref target="asInfo"/> 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 "exp" 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, valid and how critical timely expiration of the access token is.</t>
        <t>The expiration mechanism implemented by the "exi" claim, based on
	the first time the RS sees the token token, was defined to provide a more
	predictable alternative.  The "exi" approach has some drawbacks that
	need to be considered:
	<list>
	  <t>A
        </t>
        <ul spacing="normal">
          <li>A malicious client may hold back tokens with the "exi" claim in
	  order to prolong their lifespan.</t>
	  <t>If lifespan.</li>
        <li>
	  If an RS loses state (e.g. (e.g., due to an unscheduled reboot), it
	  may lose the current values of counters tracking the "exi" claims of
	  tokens it is storing.</t>
	</list> storing.</li>
	</ul>
        <t>
	The first drawback is inherent to the deployment scenario and the "exi"
	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 "exi" counters to persistent memory.</t>
      </section>
      <section anchor="mixnmatch" title="Combining Profiles"> 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 previously defined MQTT-TLS profile is used between
      the client and the RS in combination with a previously-defined previously defined
      CoAP-DTLS profile for interactions between the client and the AS. The
      new profile that combines existing profiles MUST <bcp14>MUST</bcp14> specify how the
      existing profiles' security properties are achieved. Any Therefore, any profile
      therefore MUST
      <bcp14>MUST</bcp14> clearly specify its security requirements and MUST <bcp14>MUST</bcp14>
      document if its security depends on the combination of various
      protocol interactions.</t>
      </section>
      <section anchor="infoLeak" title="Unprotected Information"> 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, all potentially
	include
	includes sending information over an unprotected channel.
	These messages may leak information to an adversary, adversary or may be
	manipulated by active attackers to induce incorrect behavior.  For
	example
	example, error responses for requests to the Authorization Information 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, cases where this assessment does not apply, detailed error
	messages can be replaced by more generic ones.</t>
        <t>In some scenarios scenarios, it may be possible to protect the
	communication with the authz-info endpoint (e.g. (e.g., through
	DTLS with only server-side authentication). In cases where
	this is not possible, it is RECOMMENDED <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 Unauthorized Resource Request message (see <xref
	target="rreq"/>) target="rreq" format="default"/>) is used, the client MUST <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 "ace_profile"
	claim requesting the use of said obsolete profile.  Resource Owners owners
	should update the configuration of their RS's RSs to prevent them from
	using such obsolete profiles.</t>
      </section>
      <section anchor="audience" title="Identifying Audiences"> numbered="true" toc="default">
        <name>Identifying Audiences</name>
        <t>The audience claim claim, as defined in <xref target="RFC7519"/> target="RFC7519" format="default"/>,
	and the equivalent "audience" parameter from
	<xref target="RFC8693"/> 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 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, RS and asymmetric keys are used,
	the RS can be uniquely identified by a hash of its public key.
	If this approach is used used, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to apply the
	procedure from section 3 of <xref target="RFC6920"/>.</t> 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, 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 NOT RECOMMENDED <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 "audience" parameter, 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 "audience" can either be provisioned to the client as part of its
	configuration,
	configuration or dynamically looked up by the client in some
	directory. In the latter case case, the integrity and	correctness of the
	directory data must be assured.  Note that the "audience" hint
	provided by the RS as part of the "AS Request Creation Hints" <xref
	target="asInfo"/> (<xref
	target="asInfo" format="default"/>) is not typically source authenticated and
	integrity
	protected, protected and should therefore not be treated a trusted value.</t>
      </section>
      <section anchor="introDos" title="Denial numbered="true" toc="default">
        <name>Denial of Service Against or with
					Introspection"> 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 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 MUST NOT <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 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, considered in order to
	mitigate distributed attacks.</t>
      </section>
    </section>
    <section anchor="privacy" title="Privacy Considerations"> 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 grants, this can be prevented
      by the Resource Owner. 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 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 SHOULD <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, wire or be able to
      acquire the access tokens in some other way.  In the case of CWTs CWTs,
      the token may, e.g., reveal the audience, the scope 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 proof of possession should be aware
      of the consequences of using the same key pair for proof-of-possession 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, requests or even
      to determine the client's identity.</t>
      <t>An unprotected response to an unauthorized request (see
      <xref target="asInfo"/>) 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" title="IANA Considerations"> 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
-->

      <t>This document creates several registries with a registration policy of
  "Expert Review";
  Expert Review; guidelines to the experts are given in
  <xref target="IANAinstructions"/>.</t> target="IANAinstructions" format="default"/>.</t>
      <section anchor="IANAASInformation"
	   title="ACE numbered="true" toc="default">
        <name>ACE Authorization Server Request Creation Hints"> Hints</name>
        <t>This specification establishes the IANA "ACE Authorization Server
    Request Creation Hints" registry. The registry has been created to use the
    "Expert Review" registration procedure <xref target="RFC8126"/>.
    It should be noted that, in addition to the expert review, some portions of
    the registry require a specification, potentially a Standards Track RFC, be
    supplied as well.</t> registry.</t>
        <t>The columns of the registry are:

    <list style='hanging'>
      <t hangText='Name'>The are:</t>
        <dl newline="false">
          <dt>Name:</dt>
          <dd>The name of the parameter</t>

      <t hangText='CBOR Key'>CBOR parameter.</dd>
          <dt>CBOR Key:</dt>
          <dd>CBOR map key for the parameter.  Different ranges
      of values use different registration policies <xref target="RFC8126"/>. 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.</t>

      <t hangText='Value Type'>The Use.</dd>
          <dt>Value Type:</dt>
          <dd>The CBOR data types allowable for the values of
      this parameter.</t>

      <t hangText='Reference'>This parameter.</dd>
          <dt>Reference:</dt>
          <dd>This contains a pointer to the public
      specification of the request creation hint Request Creation Hint abbreviation, if one
      exists.</t>
    </list></t>
      exists.</dd>
        </dl>
	<t>This registry will be has been initially populated by the values in <xref target="fig:asinfo"/>. target="table_asinfo"/>. The Reference column for all of these entries will be is this document.</t>
      </section>
      <section anchor="IANAcoreRT" title="CoRE numbered="true" toc="default">
        <name>CoRE Resource Type Registry"> Registry</name>
        <t>IANA is requested to register 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"/> target="IANA.CoreParameters" format="default"/> registry:</t>

    <t><?rfc subcompact="yes"?>
    <list style='symbols'>
      <t>Value: <spanx style="verb">ace.ai</spanx></t>
      <t>Description: ACE-OAuth
        <dl newline="false" spacing="compact">
          <dt>Value:</dt>
	  <dd><tt>ace.ai</tt></dd>
          <dt>Description:</dt>
	  <dd>ACE-OAuth authz-info endpoint resource.</t>
      <t>Reference: [this document]</t>
    </list></t> 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"
	   title="OAuth numbered="true" toc="default">
        <name>OAuth Extensions Error Registration"> Registration</name>
        <t>This specification registers the following error values in the OAuth
    Extensions Error registry
    <xref target="IANA.OAuthExtensionsErrorRegistry"/>.</t>

    <t><?rfc subcompact="yes"?>
    <list style='symbols'>
      <t>Error name: <spanx style="verb">unsupported_pop_key</spanx></t>
      <t>Error 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: token location:</dt>
	  <dd>token error response</t>
      <t>Related response</dd>
          <dt>Related protocol extension: [this document]</t>
      <t>Change Controller: IESG</t>
      <t>Specification document(s): <xref target="errorsToken"/> of
      [this document]</t>
    </list></t>

    <t><?rfc subcompact="yes"?>
    <list style='symbols'>
      <t>Error name: <spanx style="verb">incompatible_ace_profiles</spanx></t>
      <t>Error 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: token location:</dt>
	  <dd>token error response</t>
      <t>Related response</dd>
          <dt>Related protocol extension: [this document]</t>
      <t>Change Controller: IESG</t>
      <t>Specification document(s): <xref target="errorsToken"/> of
      [this document]</t>
    </list></t> 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"
	   title="OAuth numbered="true" toc="default">
        <name>OAuth Error Code CBOR Mappings Registry"> Registry</name>
        <t>This specification establishes the IANA "OAuth Error Code
    CBOR Mappings" registry.  The 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 "Expert
    Review" registration procedure <xref target="RFC8126"/>, except
    for the value range designated for private use.</t> ...")
has been removed.
-->
        <t>The columns of the registry are:

    <list style='hanging'>
      <t hangText='Name'>The are:</t>
        <dl newline="false">
          <dt>Name:</dt>
          <dd>The OAuth Error Code name, refers to the name in
      Section 5.2. of
	  <xref target="RFC6749"/>, target="RFC6749" sectionFormat="of" section="5.2"/>, e.g., "invalid_request".</t>

      <t hangText='CBOR Value'>CBOR
	  "invalid_request".</dd>
          <dt>CBOR Value:</dt>
<dd>CBOR abbreviation for this error code.
Integer values less than -65536 are marked as "Private Use", Private Use; all other values use
the registration policy "Expert Review" Expert Review <xref target="RFC8126"/>.</t>

      <t hangText='Reference'>This 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.</t>
    </list></t> 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 will be has been initially populated by the values in <xref target="fig:cborErrorCodes"/>. target="table_cborErrorCodes"/>. The Reference column for all of these entries will be is this document.</t>

      </section>
      <section anchor="IANAGrantTypeMappings"
	   title="OAuth numbered="true" toc="default">
        <name>OAuth Grant Type CBOR Mappings"> Mappings</name>
        <t>This specification establishes the IANA "OAuth Grant Type CBOR Mappings"
    registry.  The registry has been created to use the "Expert Review"
    registration procedure <xref target="RFC8126"/>, except for the value range
    designated for private use. </t>
    registry.</t>
        <t>The columns of this registry are:

    <list style='hanging'>
      <t hangText='Name'>The are:</t>
        <dl newline="false">
          <dt>Name:</dt>
          <dd>The name of the grant type type, as specified in
      Section 1.3 of
      <xref target="RFC6749"/>.</t>

      <t hangText='CBOR Value'>CBOR 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", Private Use; all other values use
      the registration policy "Expert Review" Expert Review <xref target="RFC8126"/>.</t>

      <t hangText='Reference'>This 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.</t>

      <t hangText='Original Specification'>This exists.</dd>
          <dt>Original Specification:</dt>
          <dd>This contains a pointer to
      the public specification of the grant type, if one exists.</t>
    </list></t> exists.</dd>
        </dl>

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

      </section>
      <section anchor="IANAOAuthTokenType" title="OAuth numbered="true" toc="default">
        <name>OAuth Access Token Types"> Types</name>
        <t>This section registers the following new token type in the
    "OAuth Access Token Types" registry <xref
    target="IANA.OAuthAccessTokenTypes"/>.</t>
    <t><?rfc subcompact="yes"?>
    <list style='symbols'>
      <t>Type name: <spanx style="verb">PoP</spanx></t>
      <t>Additional 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: "cnf", Parameters:</dt>
	  <dd>"cnf", "rs_cnf"
      see section 3.3 of (see <xref target="I-D.ietf-ace-oauth-params"/>.</t>
      <t>HTTP target="RFC8747" sectionFormat="of" section="3.1"/> <xref target="RFC9201"
	  sectionFormat="of" section="3.2"/>).</dd>
          <dt>HTTP Authentication Scheme(s): N/A</t>
      <t>Change Controller: IETF</t>
      <t>Specification document(s): [this document]</t>
    </list></t> 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"
	   title="OAuth numbered="true" toc="default">
        <name>OAuth Access Token Type CBOR Mappings"> Mappings</name>
        <t>This specification established establishes the IANA "OAuth Access Token Type CBOR
     Mappings" registry.  The registry has been created to use the "Expert
     Review" registration procedure <xref target="RFC8126"/>, except for the
     value range designated for private use. </t> registry.</t>
        <t>The columns of this registry are:

    <list style='hanging'>
      <t hangText='Name'>The are:</t>
        <dl newline="false">
          <dt>Name:</dt>
          <dd>The name of the token type type, as registered in the
      OAuth
      "OAuth Access Token Types Types" registry, e.g., "Bearer".</t>

      <t hangText='CBOR Value'>CBOR "Bearer".</dd>
          <dt>CBOR Value:</dt>
          <dd>CBOR abbreviation for this token type. Integer
      values less than -65536 are marked as "Private Use", Private Use; all other values use
      the registration policy "Expert Review" Expert Review <xref target="RFC8126"/>.</t>

      <t hangText='Reference'>This 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.</t>

      <t hangText='Original Specification'>This exists.</dd>
          <dt>Original Specification:</dt>
          <dd>This contains a pointer to
      the public specification of the OAuth token type, if one exists.</t>
    </list></t> exists.</dd>
        </dl>
        <section anchor="IANATokenTypeMappingsInitial" title="Initial numbered="true" toc="default">
          <name>Initial Registry Contents">
      <t>
        <?rfc subcompact="yes"?>
        <list style='symbols'>
          <t>Name: <spanx style="verb">Bearer</spanx></t>
          <t>Value:  1</t>
          <t>Reference:  [this document]</t>
	  <t>Original Specification:  <xref target="RFC6749"/></t>
        </list>
      </t>
      <t>
        <?rfc subcompact="yes"?>
        <list style='symbols'>
          <t>Name: <spanx style="verb">PoP</spanx></t>
          <t>Value: 2</t>
          <t>Reference: [this document]</t>
	  <t>Original Specification:  [this document]</t>
        </list>
      </t> 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"
	   title="ACE numbered="true" toc="default">
        <name>ACE Profile Registry"> Registry</name>
        <t>This specification establishes the IANA "ACE Profile" registry.  The
   registry has been created to use the "Expert Review" registration
   procedure <xref target="RFC8126"/>.  It should be noted that, in addition to
   the expert review, some portions of the registry require a specification,
   potentially a Standards Track RFC, be supplied as well.</t> </t>
        <t>The columns of this registry are:

    <list style='hanging'>
      <t hangText='Name'> are:</t>
        <dl newline="false">
          <dt>Name:</dt>
          <dd> The name of the profile, profile to be used as the value of
	  the profile attribute.</t>

      <t hangText='Description'> attribute.</dd>
          <dt>Description:</dt>
          <dd> Text giving an overview of the profile and
	  the context it is developed for.</t>

      <t hangText='CBOR Value'>CBOR for.</dd>
          <dt>CBOR Value:</dt>
          <dd>CBOR abbreviation for this profile name. Different ranges of values use different registration policies <xref
      target="RFC8126"/>.
	  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". Expert Review.  Integer values less than
	  -65536 are marked as Private Use.</t>

      <t hangText='Reference'>This Use.</dd>
          <dt>Reference:</dt>
          <dd>This contains a pointer to the public
      specification of the profile abbreviation, if one exists.</t>
   </list></t>

   <t>This registry will be initially empty and will be populated by the
   registrations from the ACE framework profiles.</t> exists.</dd>
        </dl>
      </section>
      <section anchor="IANAOAuthParameter"
	   title="OAuth numbered="true" toc="default">
        <name>OAuth Parameter Registration"> Registration</name>
        <t>This specification registers the following parameter in the "OAuth
    Parameters" registry <xref target="IANA.OAuthParameters"/>:</t>
    <t><?rfc subcompact="yes"?>
    <list style='symbols'>
      <t>Name: <spanx style="verb">ace_profile</spanx></t>
      <t>Parameter target="IANA.OAuthParameters" format="default"/>:</t>
        <dl newline="false" spacing="compact">
          <dt>Name:</dt>
	  <dd><tt>ace_profile</tt></dd>
          <dt>Parameter Usage Location: token response</t>
      <t>Change Controller: IESG</t>
      <t>Reference: Location:</dt>
	  <dd>token response</dd>
          <dt>Change Controller:</dt>
	  <dd>IETF</dd>
          <dt>Reference:</dt>
	  <dd>Sections <xref target="tokenResponse"/> target="tokenResponse" format="counter"/> and
	  <xref target="paramProfile"/> target="paramProfile" format="counter"/> of [this document]</t>
    </list></t> RFC 9200</dd>
        </dl>
      </section>
      <section anchor="IANAOAuthParameterMappingsRegistry"
	   title="OAuth numbered="true" toc="default">
        <name>OAuth Parameters CBOR Mappings Registry"> Registry</name>
        <t>This specification establishes the IANA "OAuth Parameters CBOR Mappings"
    registry.  The registry has been created to use the "Expert Review"
    registration procedure <xref target="RFC8126"/>, except for the value range
    designated for private use.</t>
    registry.</t>
        <t>The columns of this registry are:

    <list style='hanging'>
      <t hangText='Name'>The are:</t>
        <dl newline="false">
          <dt>Name:</dt>
          <dd>The OAuth Parameter name, refers to the name in
      the OAuth parameter registry, e.g., "client_id".</t>

      <t hangText='CBOR Key'>CBOR "client_id".</dd>
          <dt>CBOR Key:</dt>
          <dd>CBOR map key for this parameter.  Integer
      values less than -65536 are marked as "Private Use", Private Use; all other values use
      the registration policy "Expert Review" Expert Review <xref target="RFC8126"/>.</t>

      <t hangText='Value Type'>The target="RFC8126" format="default"/>.</dd>
          <dt>Value Type:</dt>
          <dd>The allowable CBOR data types for values
      of this parameter.</t>

      <t hangText='Reference'>This parameter.</dd>
          <dt>Reference:</dt>
          <dd>This contains a pointer to the public
	  specification of the OAuth parameter abbreviation, if one exists.</t>
    </list></t> exists.</dd>
	  <dt>Original Specification</dt>
	  <dd>This contains a pointer to the public
	        specification of the OAuth parameter, if one exists.</dd>
        </dl>

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

      </section>
      <section anchor="IANAOAuthIntrospectionResponseParameterRegistration"
	   title="OAuth numbered="true" toc="default">
        <name>OAuth Introspection Response Parameter Registration"> Registration</name>
        <t>This specification registers the following parameters in the OAuth
    Token Introspection Response registry <xref
    target="IANA.TokenIntrospectionResponse"/>.</t>
    <t>
      <?rfc subcompact="yes"?>
      <list style='symbols'>
        <t>Name: <spanx style="verb">ace_profile</spanx></t>
        <t>Description: The 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.</t>
        <t>Change Controller: IESG</t>
        <t>Reference: <xref target="introRes"/> of [this document]</t>
      </list>
    </t>
    <t>
      <?rfc subcompact="yes"?>
      <list style='symbols'>
        <t>Name: <spanx style="verb">cnonce</spanx></t>
        <t>Description: "client-nonce". 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.</t>
        <t>Change Controller: IESG</t>
        <t>Reference: <xref target="introRes"/> of [this document]</t>
      </list>
    </t>
    <t>
      <?rfc subcompact="yes"?>
      <list style='symbols'>
        <t>Name: <spanx style="verb">exi</spanx></t>
        <t>Description: "Expires 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 from form of
	token expiration for devices that cannot synchronize their internal
	clocks.</t>
        <t>Change Controller: IESG</t>
        <t>Reference: <xref target="introRes"/> of [this document]</t>
      </list>
    </t>
	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"
	   title="OAuth numbered="true" toc="default">
        <name>OAuth Token Introspection Response CBOR Mappings Registry"> Registry</name>
        <t>This specification establishes the IANA "OAuth Token Introspection
    Response CBOR Mappings" registry.  The registry has been created to use the
    "Expert Review" registration procedure <xref target="RFC8126"/>, except for
    the value range designated for private use.</t> registry.</t>
        <t>The columns of this registry are:

    <list style='hanging'>
      <t hangText='Name'>The are:</t>
        <dl newline="false">
          <dt>Name:</dt>
          <dd>The OAuth Parameter name, refers to the name in
      the OAuth parameter registry, e.g., "client_id".</t>

      <t hangText='CBOR Key'>CBOR "client_id".</dd>
          <dt>CBOR Key:</dt>
          <dd>CBOR map key for this parameter.  Integer
      values less than -65536 are marked as "Private Use", Private Use; all other values use
      the registration policy "Expert Review" Expert Review <xref target="RFC8126"/>.</t>

      <t hangText='Value Type'>The target="RFC8126" format="default"/>.</dd>
          <dt>Value Type:</dt>
          <dd>The allowable CBOR data types for values
      of this parameter.</t>

      <t hangText='Reference'>This parameter.</dd>
          <dt>Reference:</dt>
          <dd>This contains a pointer to the public
	  specification of the introspection response parameter abbreviation, if
	  one exists.</t>
    </list></t>

    <t>This 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 will be has been initially populated by the values in <xref target="fig:cborIntrospectionParameters"/>.
target="table_cborIntrospectionParameters"/>. The Reference column for all of these entries will be 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"/>.</t> target="RFC8392" format="default"/>.</t>
      </section>
      <section anchor="IANAJWTClaims" title="JSON numbered="true" toc="default">
        <name>JSON Web Token Claims"> 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"/>:</t>

    <t><?rfc subcompact="yes"?>
    <list style='symbols'>
      <t>Claim Name: <spanx style="verb">ace_profile</spanx></t>
      <t>Claim Description: The 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.</t>
      <t>Change Controller: IESG</t>
      <t>Reference: <xref target="accessToken"/> of [this document]</t>
    </list></t>

    <t><?rfc subcompact="yes"?>
    <list style='symbols'>
      <t>Claim Name: <spanx style="verb">cnonce</spanx></t>
      <t>Claim Description: "client-nonce". 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.</t>
      <t>Change Controller: IESG</t>
      <t>Reference: <xref target="accessToken"/> of [this document]</t>
    </list></t>

    <t><?rfc subcompact="yes"?>
    <list style='symbols'>
      <t>Claim Name: <spanx style="verb">exi</spanx></t>
      <t>Claim Description: "Expires 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 from form of
      token expiration for devices that cannot synchronize their internal
      clocks.</t>
      <t>Change Controller: IESG</t>
      <t>Reference: <xref target="tokenExpiration"/> of [this document]</t>
    </list></t>
      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" title="CBOR numbered="true" toc="default">
        <name>CBOR Web Token Claims"> Claims</name>
        <t>This specification registers the following new claims in the "CBOR
    Web Token (CWT) Claims" registry <xref
    target="IANA.CborWebTokenClaims"/>.</t>

    <t><?rfc subcompact="yes"?>
    <list style='symbols'>
      <t>Claim Name: <spanx style="verb">ace_profile</spanx></t>
      <t>Claim Description: The 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.</t>
      <t>JWT with.</dd>
          <dt>JWT Claim Name: ace_profile</t>
      <t>Claim Key: TBD (suggested: 38)</t>
      <t>Claim Name:</dt>
	  <dd>ace_profile</dd>
          <dt>Claim Key:</dt>
	  <dd>38</dd>
          <dt>Claim Value Type(s): integer</t>
      <t>Change Controller: IESG</t>
      <t>Specification Document(s): <xref target="accessToken"/> of [this
      document]</t>
    </list></t>

    <t><?rfc subcompact="yes"?>
    <list style='symbols'>
      <t>Claim Name: <spanx style="verb">cnonce</spanx></t>
      <t>Claim Description: The 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.</t>
      <t>JWT client.</dd>
          <dt>JWT Claim Name: cnonce</t>
      <t>Claim Key: TBD (suggested: 39)</t>
      <t>Claim Name:</dt>
	  <dd>cnonce</dd>
          <dt>Claim Key:</dt>
	  <dd>39</dd>
          <dt>Claim Value Type(s): byte string</t>
      <t>Change Controller: IESG</t>
      <t>Specification Document(s): <xref target="accessToken"/> of [this
      document]</t>
    </list></t>

    <t><?rfc subcompact="yes"?>
    <list style='symbols'>
      <t>Claim Name: <spanx style="verb">exi</spanx></t>
      <t>Claim Description: The 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.</t>
      <t>JWT seconds.</dd>
          <dt>JWT Claim Name: exi</t>
      <t>Claim Key: TBD (suggested: 40)</t>
      <t>Claim Name:</dt>
	  <dd>exi</dd>
          <dt>Claim Key:</dt>
	  <dd>40</dd>
          <dt>Claim Value Type(s): integer</t>
      <t>Change Controller: IESG</t>
      <t>Specification Document(s): <xref target="tokenExpiration"/> of [this
      document]</t>
    </list></t>

     <t><?rfc subcompact="yes"?>
    <list style='symbols'>
      <t>Claim Name: <spanx style="verb">scope</spanx></t>
      <t>Claim Description: The Type(s):</dt>
	  <dd>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 token, as defined in <xref target="RFC6749"/>.</t>
      <t>JWT target="RFC6749"
	  format="default"/>.</dd>
          <dt>JWT Claim Name: scope</t>
      <t>Claim Key: TBD (suggested: 9)</t>
      <t>Claim Name:</dt>
	  <dd>scope</dd>
          <dt>Claim Key:</dt>
	  <dd>9</dd>
          <dt>Claim Value Type(s): byte Type(s):</dt>
	  <dd>byte string or text string</t>
      <t>Change Controller: IESG</t>
      <t>Specification Document(s): Section 4.2 of
      <xref target="RFC8693"/></t>
     </list></t> 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" title="Media numbered="true" toc="default">
        <name>Media Type Registrations"> Registration</name>
        <t>This specification registers the 'application/ace+cbor' "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"/>.</t>

    <t>Type name: application</t>

    <t>Subtype name: ace+cbor</t>

    <t>Required parameters: N/A</t>

    <t>Optional parameters: N/A</t>

    <t>Encoding considerations: Must 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 [this document].</t>

    <t>Security considerations: See RFC 9200.</dd>
        <dt>Security considerations:</dt>
	<dd>See <xref target="security"/> target="security" format="default"/> of [this
    document]</t>

    <t>Interoperability considerations: N/A</t>

    <t>Published specification: [this document]</t>

    <t>Applications 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: The type:</dt>
	<dd>The type is used by
	authorization servers, clients clients, and resource servers that support the ACE
	framework with CBOR encoding encoding, as specified in [this document].</t>

    <t>Fragment RFC 9200.</dd>
        <dt>Fragment identifier considerations: N/A </t>

    <t>Additional information: N/A</t>

    <t>Person considerations:</dt>
	<dd>N/A</dd>
        <dt>Additional information:</dt>
	<dd>N/A</dd>
        <dt>Person &amp; email address to contact for further information:
    &lt;iesg@ietf.org&gt;</t>

    <t>Intended usage: COMMON</t>

    <t>Restrictions on usage: none</t>

    <t>Author: Ludwig information:</dt>
	<dd><br/>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;</t>

    <t>Change controller: IESG</t> &lt;ludwig.seitz@combitech.se&gt;</dd>
        <dt>Change controller:</dt>
	<dd>IETF</dd>
    </dl>
      </section>
      <section anchor="IANAcoapContentFormat" title="CoAP numbered="true" toc="default">
        <name>CoAP Content-Format Registry">
    <t>This specification registers the Registry</name>
        <t>The following entry to has been registered in the "CoAP
    Content-Formats" registry:</t>
    <t>Media Type: application/ace+cbor</t>
    <t>Encoding: -</t>
    <t>ID: TBD (suggested: 19)</t>
    <t>Reference: [this document]</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" title="Expert numbered="true" toc="default">
        <name>Expert Review Instructions"> 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 Reviewers should take into consideration the following points:
    <list style="symbols">
      <t>Point
        </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,
      registered and that the point is likely to be used in deployments.  The
      zones tagged as private use Private Use are intended for testing purposes and closed
      environments; code points in other ranges should not be assigned for
      testing.</t>

      <t>Specifications
      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.</t>

      <t>Experts 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
      Standards Track documents does not mean that a standards track 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.</t>

      <t>Since 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"/> 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, differences that are motivated by
      the use case and that cannot be easily or efficiently addressed by
      comparable OAuth parameters.</t>
    </list></t> parameters.</li>
        </ul>
      </section>

</section><!--
    </section>
    <!-- IANA considerations -->

<section anchor="Acknowledgments" title="Acknowledgments">
  <t>This document is a product of the ACE working group of the IETF.</t>

  <t>Thanks to Eve Maler for her contributions to the use of
  OAuth 2.0 and UMA in IoT scenarios, Robert Taylor for his discussion
  input, and Malisa Vucinic for his input on the predecessors of this
  proposal.</t>

  <t>Thanks to the authors of draft-ietf-oauth-pop-key-distribution, from where
  parts of the security considerations where copied.</t>

  <t>Thanks to Stefanie Gerdes, Olaf Bergmann, and Carsten
  Bormann for contributing their work on AS discovery from
  draft-gerdes-ace-dcaf-authorize (see <xref target="asDiscovery"/>) and
  the considerations on multiple access tokens.</t>

  <t>Thanks to Jim Schaad and Mike Jones for their comprehensive reviews.</t>

  <t>Thanks to Benjamin Kaduk for his input on various questions related to
  this work.</t>

  <t>Thanks to Cigdem Sengul for some very useful review comments.</t>

  <t>Thanks to Carsten Bormann for contributing the text for the CoRE Resource
  Type registry.</t>

  <t>Thanks to Roman Danyliw for suggesting the <xref target="app:diffOAuth"/>
  (including its contents).</t>

  <t>Ludwig Seitz and Goeran Selander worked on this document as part of
  the CelticPlus project CyberWI, with funding from Vinnova. Ludwig Seitz
  was also received further funding for this work by Vinnova in the context of
  the CelticNext project Critisec.</t>
</section>

    <!-- 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"/>

<!-- References split into informative and normative [I-D.ietf-ace-oauth-params] companion document RFC 9201 -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top,

<reference anchor='RFC9201' target="https://www.rfc-editor.org/info/rfc9201">
<front>
<title>Additional OAuth Parameters for Authentication and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either Authorization in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;
      &RFC3986;
      &RFC6347;
      &RFC6749;
      &RFC6750;
      &RFC6838;
      &RFC6920;
      &RFC8949;
      &RFC7252;
      &RFC7519;
      &RFC7662;
      &RFC8126;
      &RFC8152;
      &RFC8174;
      &RFC8392;
      &RFC8693;
      &RFC8747;
      &I-D.ietf-ace-oauth-params; 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/oauth-parameters.xhtml#token-types"> target="https://www.iana.org/assignments/oauth-parameters">
          <front>
            <title>OAuth Access Token Types</title>
            <author>
              <organization>IANA</organization>
            </author>
	  <date/>
          </front>
        </reference>

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

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

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

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

        <reference anchor="IANA.OAuthExtensionsErrorRegistry" target="https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error"> target="https://www.iana.org/assignments/oauth-parameters">
          <front>
            <title>OAuth Extensions Error Registry</title>
            <author>
              <organization>IANA</organization>
            </author>
  <date/>
          </front>
        </reference>

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

    <references title="Informative References">
      &RFC4949;
      &RFC6690;
      &RFC6819;
      &RFC7009;
      &RFC7228;
      &RFC7231;
      &RFC7521;
      &RFC7540;
      &RFC7591;
      &RFC7641;
      &RFC7744;
      &RFC7959;
      &RFC8252;
      &RFC8259;
      &RFC8414;
      &RFC8446;
      &RFC8516;
      &RFC8613;
      &RFC8628;
      &I-D.ietf-tls-dtls13;
      &I-D.erdtman-ace-rpcc;
      &I-D.ietf-quic-transport;
      &I-D.ietf-ace-oscore-profile;
      &I-D.ietf-ace-dtls-authorize;

      <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>.
-->

<!-- [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. B." initials="C." surname="Margi"/>
            <author initials="B.T." initials="B." surname="de Oliveira"/>
            <author initials="G.T." initials="G." surname="de Sousa"/>
            <author initials="M.A." initials="M." surname="Simplicio Jr"/>
            <author initials="P.S.L.M." initials="P." surname="Barreto"/>
            <author initials="T.C.M.B." initials="T." surname="Carvalho"/>
            <author initials="M." surname="Naeslund"/>
            <author initials="R." surname="Gold"/>
            <date year="2010" month="August" /> month="August"/>
          </front>
	  <seriesInfo name="Proceedings name="DOI" value="10.1109/ICCCN.2010.5560028"/>
          <refcontent>Proceedings of the" value="19th the 19th International Conference on Computer
	  Communications and Networks (ICCCN)"/> 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>
        <seriesInfo name="OASIS" value="Standard"/>
          <refcontent>OASIS Standard</refcontent>
        </reference>

        <reference anchor="BLE" target="https://www.bluetooth.com/specifications/bluetooth-core-specification/">
          <front>
          <title>Bluetooth Core
            <title>Core Specification v5.1</title>
            <author initials="" surname="Bluetooth SIG"/> 5.3</title>
            <author>
	      <organization>Bluetooth Special Interest Group</organization>
	    </author>
            <date year="2019" month="January"/> year="2021" month="July"/>
          </front>
          <seriesInfo name="Section" value="4.4"/>
        </reference>
      </references>
    </references>
    <section title="Design Justification" anchor="constraints"> 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"/> 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:

        <list style="hanging">

          <t hangText="Low

      </t>
      <dl newline="true" spacing="normal">
        <dt>Low Power Radio:"><vspace blankLines="1"/> Radio:</dt>
        <dd>
          Many IoT devices are equipped with a small battery which 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"/>. 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
	  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.
	  <vspace blankLines="0"/>
          </t>

          <t hangText="Low
        </dd>
        <dt>Low CPU Speed:"><vspace blankLines="1"/> 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 trusted, third-party-assisted secret key establishment
          using transport- or application-layer security.
	  <vspace blankLines="0"/></t>

          <t hangText="Small
        </dd>
        <dt>Small Amount of Memory:"> <vspace blankLines="1"/> 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 has have
          an impact on memory and code footprints.<vspace blankLines="0"/>
          </t>

          <t hangText="User footprints.
        </dd>
        <dt>User Interface Limitations:"> <vspace blankLines="1"/> 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 smart phones smartphones and tablets.
	  <vspace blankLines="1"/></t>

          <t hangText="Communication Constraints:"> <vspace blankLines="1"/>
        </dd>
        <dt>Communication Constraints:</dt>
        <dd>
          <t>
          In certain constrained settings settings, an IoT device may not be able to
          communicate with a given device at all times.  Devices may be
          sleeping,
          sleeping or just disconnected from the Internet because of general
          lack of connectivity in the area, area for cost reasons, or for security
          reasons, e.g., to avoid an entry point for Denial-of-Service denial-of-service attacks.

          <vspace blankLines="1"/>
          </t>
          <t>
          The communication interactions this framework builds upon (as shown
          graphically in <xref target="fig:protocolFlow"/>) 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 protocols, such as HTTP, HTTP or even protocols
          such as
          Bluetooth Smart communication communication, that do not
          necessarily use IP, IP could also be used.  The latter raises the need
          for application-layer security over the various interfaces.</t>
        </list>
      </t>
        </dd>
      </dl>
      <t>In the light of these constraints constraints, we have made the following design
      decisions:

        <list style="hanging">

          <t hangText="CBOR,
      decisions:</t>
      <dl newline="true" spacing="normal">
        <dt>CBOR, COSE, CWT:"><vspace blankLines="1"/> CWT:</dt>
        <dd>
	  When using this framework, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to use CBOR
	  <xref target="RFC8949"/> target="RFC8949" format="default"/> as the data format.  Where CBOR data
	  needs to be
	  protected, the use of COSE <xref target="RFC8152"/> target="RFC8152" format="default"/> is RECOMMENDED.
	  <bcp14>RECOMMENDED</bcp14>.
	  Furthermore, where self-contained tokens are needed, it is RECOMMENDED
	  <bcp14>RECOMMENDED</bcp14>
	  to use of CWT <xref target="RFC8392"/>. 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 memory, and the size of libraries that devices
	  need to support.
	  <vspace blankLines="1"/></t>

	  <t hangText="CoAP:"><vspace blankLines="1"/>
       </dd>
        <dt>CoAP:</dt>
        <dd>
	  When using this framework, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to use of CoAP
	  <xref target="RFC7252"/> target="RFC7252" format="default"/> instead of HTTP.  This does not
	  preclude the
	  use of other protocols specifically aimed at constrained devices, like,
	  e.g., Bluetooth Low Energy (see <xref target="coap"/>). 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 memory, and the size of
	  libraries that devices need to support.
	  <vspace blankLines="1"/></t>

	  <t hangText="Access Information:"><vspace blankLines="1"/>
        </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"/>). target="tokenResponse" format="default"/>).  This
	  aims at
	  enabling scenarios where a powerful client, client supporting multiple
	  profiles,
	  profiles needs to interact with an RS for which it does not know the
	  supported profiles and the raw public key.
	  <vspace blankLines="1"/></t>

	  <t hangText="Proof-of-Possession:"><vspace blankLines="1"/>
        </dd>
        <dt>Proof of Possession:</dt>
        <dd>
	  This framework makes use of proof-of-possession tokens, using
	  the "cnf" claim <xref target="RFC8747"/>. target="RFC8747" format="default"/>.  A request
	  parameter "cnf" and a Response parameter "cnf", both having a
	  value space semantically and syntactically identical to the "cnf"
	  claim, are defined for the token endpoint, 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 middle-boxes, middleboxes, which could be able
	  to steal bearer tokens and use them to gain unauthorized access.
	  <vspace blankLines="1"/> </t>

	  <t hangText="Authz-Info endpoint:"><vspace blankLines="1"/>
        </dd>
        <dt>Authz-Info endpoint:</dt>
        <dd>
	  This framework introduces a new way of providing access tokens
	  to an RS by exposing a an authz-info endpoint, 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, loss and the
	  need to retransmit the whole message if one packet gets lost.
	  Thus
	  Thus, separating sending of the request and sending of the access
	  tokens helps to reduce fragmentation.
	  <vspace blankLines="1"/></t>

	  <t hangText="Client
        </dd>
        <dt>Client Credentials Grant:"><vspace blankLines="1"/> Grant:</dt>
        <dd>
	  In this framework framework, the use of the client credentials grant is
	  RECOMMENDED
	  <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
	  pre-arrange
	  prearrange authorization with the AS, AS based on the client's own
	  credentials.  The client can then (without manual intervention) obtain
	  access tokens from the AS.
	  <vspace blankLines="1"/></t>

	  <t hangText="Introspection:"><vspace blankLines="1"/>
        </dd>
        <dt>Introspection:</dt>
        <dd>
	  In this framework framework, the use of access token introspection is RECOMMENDED
	  <bcp14>RECOMMENDED</bcp14>
	  in cases where the client is constrained in a way that it can not cannot
	  easily obtain new access tokens (i.e. (i.e., it has connectivity issues
	  that prevent it from communicating with the AS). In that case case,
	  it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to use a long-term token, token that could be a
	  simple reference.  The RS is assumed to be able to communicate
	  with the AS, AS and can therefore perform introspection, 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.
	  <vspace blankLines="1"/></t>

	</list>
      </t>
        </dd>
      </dl>
    </section>
    <section anchor="app:rolesAndResponsibilities" title="Roles and Responsibilities">
      <t><list style="hanging">
	<t hangText="Resource Owner">
	  <list style="symbols">
	    <t>Make 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.</t>
	    <t>Make
	    with.</li>
            <li>Make sure that clients can discover the AS that is in charge
	    of the RS.</t>
	    <t>If RS.</li>
            <li>If the client-credentials grant is used, make sure that the AS
	    has the necessary, up-to-date, up-to-date access control policies for the
	    RS.</t>
	  </list>
	  <vspace blankLines="0"/>
	</t>
	<t hangText="Requesting Party">
	  <list style="symbols">
	    <t>Make
	    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.</t>
	    <t>Make AS.</li>
            <li>Make sure that the client is configured to follow the security
	    requirements of the Requesting Party requesting party when issuing requests
	    (e.g., minimum communication security requirements, requirements or trust
	    anchors).</t>
	    <t>Register
	    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.</t>
          </list>
	  <vspace blankLines="0"/>
        </t>
	<t hangText="Authorization Server">
	  <list style="symbols">
	    <t>Register client.</li>
          </ul>
        </dd>
        <dt>Authorization Server</dt>
        <dd>
          <ul spacing="normal">
            <li>Register the RS and manage corresponding security contexts.</t>
            <t>Register contexts.</li>
            <li>Register clients and authentication credentials.</t>
	    <t>Allow Resource Owners credentials.</li>
            <li>Allow resource owners to configure and update access control
	    policies related to their registered RSs.</t>
	    <t>Expose RSs.</li>
            <li>Expose the token endpoint to allow  clients to request
	    tokens.</t>
            <t>Authenticate
	    tokens.</li>
            <li>Authenticate clients that wish to request a token.</t>
	    <t>Process token.</li>
            <li>Process a token request using the authorization
	    policies configured for the RS.</t>
	    <t>Optionally:  Expose RS.</li>
            <li>Optionally, expose the introspection endpoint that allows
	    RS's
	    RSs to submit token introspection requests.</t>
	    <t>If requests.</li>
            <li>If providing an introspection endpoint: Authenticate endpoint, authenticate RSs that
	    wish to get an introspection response.</t>
	    <t>If response.</li>
            <li>If providing an introspection endpoint: Process endpoint, process token
	    introspection requests.</t>
	    <t>Optionally: Handle token revocation.</t>
	    <t>Optionally: Provide requests.</li>
            <li>Optionally, handle token revocation.</li>
            <li>Optionally, provide discovery metadata. See <xref
	    target="RFC8414"/></t>
	    <t>Optionally: Handle target="RFC8414" format="default"/>.</li>
            <li>Optionally, handle refresh tokens.</t>
          </list><vspace blankLines="0"/>
	</t>
        <t hangText="Client">
	  <list style="symbols">
	    <t>Discover 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.</t> request.</li>
            <li>
              <t>Submit the token request (see step (A) of
	    <xref target="fig:protocolFlow"/>).
	      <list style="symbols">
		<t>Authenticate target="fig_protocolFlow" format="default"/>).
              </t>
              <ul spacing="normal">
                <li>Authenticate to the AS.</t>
		<t>Optionally AS.</li>
                <li>Optionally (if not pre-configured): Specify preconfigured), specify which RS, which
		resource(s), and which action(s) the request(s) will
		target.</t>
		<t>If
		target.</li>
                <li>If raw public keys (rpk) (RPKs) or certificates are used, make sure
		the AS has the right rpk RPK or certificate for this client.</t>
	      </list>
	    </t> client.</li>
              </ul>
            </li>
            <li>
              <t>Process the access token and Access Information (see step (B)
	    of <xref target="fig:protocolFlow"/>).
	       <list style="symbols">
		<t>Check target="fig_protocolFlow" format="default"/>).
              </t>
              <ul spacing="normal">
                <li>Check that the Access Information provides the necessary
		security parameters (e.g., PoP key, key or information on
		communication security protocols supported by the RS).</t>
		<t>Safely RS).</li>
                <li>Safely store the proof-of-possession key.</t>
		<t>If key.</li>
                <li>If provided by the AS: Safely AS, safely store the refresh token.</t>
	      </list>
	    </t> token.</li>
              </ul>
            </li>
            <li>
              <t>Send the token and request to the RS (see step (C) of
	    <xref target="fig:protocolFlow"/>).
	      <list style="symbols">
		<t>Authenticate target="fig_protocolFlow" format="default"/>).
              </t>
              <ul spacing="normal">
                <li>Authenticate towards the RS (this could coincide with the
		proof of possession process).</t>
		<t>Transmit
		proof-of-possession process).</li>
                <li>Transmit the token as specified by the AS (default is to the
		authz-info endpoint, endpoint; alternative options are specified by
		profiles).</t>
		<t>Perform
		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).</t>
	      </list>
	    </t>
	    <t>Process procedure).</li>
              </ul>
            </li>
            <li>Process the RS response (see step (F) of
	    <xref target="fig:protocolFlow"/>) target="fig_protocolFlow" format="default"/>) of the RS.</t>
          </list><vspace blankLines="0"/>
	</t>
	<t hangText="Resource Server">
	  <list style="symbols">
	    <t>Expose RS.</li>
          </ul>
        </dd>
        <dt>Resource Server</dt>
        <dd>
          <ul spacing="normal">
            <li>Expose a way to submit access tokens. By default default, this is
	    the authz-info endpoint.</t> endpoint.</li>
            <li>
              <t>Process an access token.
	      <list style="symbols">
		<t>Verify
              </t>
              <ul spacing="normal">
                <li>Verify the token is from a recognized AS.</t>
		<t>Check AS.</li>
                <li>Check the token's integrity.</t>
		<t>Verify integrity.</li>
                <li>Verify that the token applies to this RS.</t>
		<t>Check RS.</li>
                <li>Check that the token has not expired (if the token provides
		expiration information).</t>
		<t>Store information).</li>
                <li>Store the token so that it can be retrieved in the context
		of a matching request.</t>
	      </list> request.</li>
              </ul>
              <t>
	      Note: The order proposed here is not normative, 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 non-applicable nonapplicable or invalid tokens, tokens before
	      performing expensive cryptographic operations (e.g. (e.g., doing an
	      expiration check before verifying a signature).
	      <vspace blankLines="0"/>
              </t>
            </li>
            <li>
              <t>Process a request.
	     <list style="symbols">
	        <t>Set
              </t>
              <ul spacing="normal">
                <li>Set up communication security with the client.</t>
		<t>Authenticate client.</li>
                <li>Authenticate the client.</t>
		<t>Match client.</li>
                <li>Match the client against existing tokens.</t>
		<t>Check tokens.</li>
                <li>Check that tokens belonging to the client actually
		authorize the requested action.</t>
		<t>Optionally: Check action.</li>
                <li>Optionally, check that the matching tokens are still valid,
		using introspection (if this is possible.)</t>
	      </list>
	    </t>
	    <t>Send possible.)</li>
              </ul>
            </li>
            <li>Send a response following the agreed upon communication
	    security mechanism(s).</t>
	    <t>Safely mechanism(s).</li>
            <li>Safely store credentials credentials, such as raw public keys keys, for
	    authentication or proof-of-possession keys linked to access
	    tokens.</t>
          </list>
	</t>
      </list></t>
	    tokens.</li>
          </ul>
        </dd>
      </dl>
    </section>
    <!-- ***************************************************** -->
<section anchor="app:profileRequirements" title="Requirements anchor="app_profileRequirements" numbered="true" toc="default">
      <name>Requirements on Profiles"> Profiles</name>
      <t>This section lists the requirements on profiles of this framework, framework
      for the convenience of profile designers.

  <list style="symbols">
    <t>Optionally designers.</t>
      <ul spacing="normal">
        <li>Optionally, define new methods for the client to discover the
	necessary permissions and AS for accessing a resource, resource different from
	the one proposed in Sections <xref target="asDiscovery"/>. target="asDiscovery" format="counter"/> and <xref target="specs"/>
    </t>

    <t>Optionally
	target="specs" format="counter"/></li>
        <li>Optionally, specify new grant types.
    <xref target="authorizationGrants"/></t>

    <t>Optionally types
	(<xref target="authorizationGrants" format="default"/>).</li>
        <li>Optionally, define the use of client certificates as client credential
    type. <xref target="clientCredentials"/></t>

    <t>Specify
	type (<xref target="clientCredentials" format="default"/>).</li>
        <li>Specify the communication protocol the client and RS the must use
	(e.g., CoAP). CoAP) (Sections <xref target="oauthProfile"/> target="oauthProfile" format="counter"/> and <xref
    target="paramProfile"/></t>

    <t>Specify
	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,
	encryption and integrity and replay protection. <xref
    target="paramProfile"/></t>

    <t>Specify protection (<xref target="paramProfile"
	format="default"/>).</li>
        <li>Specify how the client and the RS mutually authenticate. <xref
    target="specs"/></t>

    <t>Specify authenticate (<xref target="specs"
	format="default"/>).</li>
        <li>Specify the proof-of-possession protocol(s) and how to select one, 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"/></t>

    <t>Specify
	protocol (<xref target="paramTokenType" format="default"/>).</li>
        <li>Specify a unique ace_profile identifier. <xref
    target="paramProfile"/></t>

    <t>If identifier (<xref target="paramProfile"
	format="default"/>).</li>
        <li>If introspection is supported: Specify supported, specify the communication and security
	protocol for introspection. <xref target="introspectionEndpoint"/></t>

    <t>Specify 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 protection,  and a binding between requests and responses. responses (Sections <xref
    target="oauthProfile"/>
	target="oauthProfile" format="counter"/> and <xref target="tokenEndpoint"/></t>

    <t>Specify target="tokenEndpoint"
	format="counter"/>).</li>
        <li>Specify how/if the authz-info endpoint is protected, including
	how error responses are protected. <xref
    target="tokenAuthInfoEndpoint"/></t>

    <t>Optionally protected (<xref target="tokenAuthInfoEndpoint"
	format="default"/>).</li>
        <li>Optionally, define other methods of token transport than the authz-info
    endpoint. <xref target="tokenAuthInfoEndpoint"/></t>

  </list>

  </t>
	endpoint (<xref target="tokenAuthInfoEndpoint" format="default"/>).</li>
      </ul>
    </section>
    <section anchor="app:registration"
	 title="Assumptions anchor="app_registration" numbered="true" toc="default">
      <name>Assumptions on AS Knowledge about the C and RS"> 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.

  <list style="symbols">
    <t>The

      </t>
      <ul spacing="normal">
        <li>The identifier of the client or RS.</t>
    <t>The RS.</li>
        <li>The profiles that the client or RS supports.</t>
    <t>The supports.</li>
        <li>The scopes that the RS supports.</t>
    <t>The supports.</li>
        <li>The audiences that the RS identifies with.</t>
    <t>The 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.</t>
    <t>The supports.</li>
        <li>The types of access tokens the RS supports (e.g., CWT).</t>
    <t>If 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.</t>
    <t>The supports.</li>
        <li>The expiration time for access tokens issued to this RS
	(unless the RS accepts a default time chosen by the AS).</t>
    <t>The AS).</li>
        <li>The symmetric key shared between the client and AS (if any).</t>
    <t>The any).</li>
        <li>The symmetric key shared between the RS and AS (if any).</t>
    <t>The any).</li>
        <li>The raw public key of the client or RS (if any).</t>
    <t>Whether any).</li>
        <li>Whether the RS has synchronized time (and thus is able to use the 'exp'
	claim) or not.</t>
  </list>
 </t> not.</li>
      </ul>
    </section>
    <section anchor="app:diffOAuth" title="Differences anchor="app_diffOAuth" numbered="true" toc="default">
      <name>Differences to OAuth 2.0"> 2.0</name>
      <t>This document adapts OAuth 2.0 to be suitable for constrained environments.
      This sections section lists the main differences from the normative requirements of
      OAuth 2.0.

      <list style="symbols">
	<t>Use 2.0.</t>
      <dl newline="true" spacing="normal">
        <dt>Use of TLS -- OAuth TLS</dt>
	<dd>OAuth 2.0 requires the use of TLS both to protect the
	communication between the AS and client when requesting an access token; token,
	between the client and RS when accessing a resource resource, and between the AS and RS if
	introspection is used.  This framework requires similar security
	properties,
	properties but does not require that they be realized with TLS.
	See <xref target="oauthProfile"/>.</t>

	<t>Cardinality target="oauthProfile" format="default"/>.</dd>
        <dt>Cardinality of "grant_type" parameter -- In parameter</dt>
	<dd>In client-to-AS requests
	using OAuth 2.0, the "grant_type" parameter is required (per
	<xref target="RFC6749"/>). target="RFC6749" format="default"/>).  In this framework, this parameter
	is optional.  See <xref target="tokenRequest"/>.</t>

	<t>Encoding target="tokenRequest" format="default"/>.</dd>
        <dt>Encoding of "scope" parameter -- In parameter</dt>
	<dd>In client-to-AS requests using OAuth
	2.0, the "scope" parameter is string encoded (per
	<xref target="RFC6749"/>). target="RFC6749" format="default"/>).  In this framework, this parameter
	may also be
	encoded as a byte string.  See <xref target="tokenRequest"/>.</t>

	<t>Cardinality target="tokenRequest"
	format="default"/>.</dd>
        <dt>Cardinality of "token_type" parameter -- in parameter</dt>
	<dd>In AS-to-client responses
	using OAuth 2.0, the token_type parameter is required (per
	<xref target="RFC6749"/>). target="RFC6749" format="default"/>).  In this framework, this parameter
	is
	optional.  See <xref target="tokenResponse"/>.</t>

	<t>Access target="tokenResponse" format="default"/>.</dd>
        <dt>Access token retention -- in 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"/>.</t>
      </list>
   </t> target="tokenAuthInfoEndpoint" format="default"/>.</dd>
      </dl>
    </section>
    <!-- ***************************************************** -->
      <section anchor="app:options" title="Deployment Examples"> 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"/>, 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 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" title="Local numbered="true" toc="default">
        <name>Local Token Validation"> 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, (A), (B), (C), and F (F) of <xref target="fig:protocolFlow"/>.
  </t>
	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 server, and a temperature sensor acting as a resource server.  Message
	exchanges A and B are shown in <xref target="fig:RSOffline"/>.</t>

    <t><list style="hanging">
      <t>A: The 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 example, it is
	    assumed that both the client and AS have performed mutual authentication
	e.g. authentication,
	    e.g., via DTLS.  The request contains the public key of the client and
	    the Audience audience 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>

	<t>B: The
            </dd>
          <dt>B:</dt>
	  <dd>
	    <t>The AS responds with a 2.05 Content (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
	    security, this example uses DTLS RawPublicKey between the client and the
	    RS. The issued token will have a short validity time, i.e., "exp" close
	    to "iat", in order to mitigate attacks using stolen client credentials.
	    The token includes the claim claims, such as "scope" "scope", with the authorized access
	    that an owner of the temperature device can enjoy.  In this example, the
	    "scope" claim, claim issued by the AS, AS informs the RS that the owner of the
      token,
	    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 scope claim
	    are application specific.</t>
            <t>Note: In this example example, it is assumed that the client knows what resource
	    it wants to access, access and is therefore able to request specific
	    audience and scope claims for the access token.</t>
    </list></t>

    <t><figure align="center" anchor="fig:RSOffline"
               title="Token
	  </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.)
-->
        <figure anchor="fig_RSOffline">
          <name>Token Request and Response Using Client Credentials."> Credentials</name>
          <artwork align="left"><![CDATA[ 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>
        </figure>
        <t>The information contained in the Request-Payload and the
    Response-Payload is shown in <xref target="fig:RSOfflineReq"/> target="fig_RSOfflineReq" format="default"/>.
    Note that the parameter "rs_cnf" from
    <xref target="I-D.ietf-ace-oauth-params"/> target="RFC9201" format="default"/> is used to inform
    the client about the resource server's public key.

        </t>
        <figure align="center" anchor="fig:RSOfflineReq"
             title="Request anchor="fig_RSOfflineReq">
          <name>Request and Response Payload Details.">
      <artwork align="left"><![CDATA[ Details</name>
          <sourcecode name="" type="cbor-diag"><![CDATA[
Request-Payload :
{
  "audience" : "tempSensorInLivingRoom",
  "client_id" : "myclient",
  "req_cnf" : {
    "COSE_Key" : {
      "kid" : b64'1Bg8vub9tLe1gHMzV76e8',
      "kty" : "EC",
      "crv" : "P-256",
      "x" : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
      "y" : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
    }
  }
}

Response-Payload :
{
  "access_token" : b64'0INDoQEKoQVNKkXfb7xaWqMTf6 ...',
  "rs_cnf" : {
    "COSE_Key" : {
      "kid" : b64'c29tZSBwdWJsaWMga2V5IGlk',
      "kty" : "EC",
      "crv" : "P-256",
      "x"   : b64'MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4',
      "y"   : b64'4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM'
    }
  }
}
        ]]></artwork>
    </figure></t>
        ]]></sourcecode>
        </figure>
        <t>The content of the access token is shown
    in <xref target="fig:BothcborMappingValueAsymmetricCWT"/>.</t>

    <t><figure align="center"
               anchor="fig:BothcborMappingValueAsymmetricCWT"
               title="Access target="fig_BothcborMappingValueAsymmetricCWT" format="default"/>.</t>
        <figure anchor="fig_BothcborMappingValueAsymmetricCWT">
          <name>Access Token including Including Public Key of the client.">
        <artwork align="left"><![CDATA[ Client</name>
          <sourcecode name="" type="json"><![CDATA[
{
  "aud" : "tempSensorInLivingRoom",
  "iat" : "1563451500",
  "exp" : "1563453000",
  "scope" :  "temperature_g firmware_p",
  "cnf" : {
    "COSE_Key" : {
      "kid" : b64'1Bg8vub9tLe1gHMzV76e8',
      "kty" : "EC",
      "crv" : "P-256",
      "x" : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
      "y" : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
    }
  }
}
        ]]></artwork>
    </figure></t>
        ]]></sourcecode>
        </figure>
        <t>Messages C and F are shown in Figures
    <xref target="fig:RSOfflinePostAccessTokenAsymmetric"/> - target="fig_RSOfflinePostAccessTokenAsymmetric" format="counter"/> and
    <xref target="fig:RSOfflineDTLSRequestAndResponse"/>.

    <list style="hanging">
      <t>C: 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, that 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.</t>

    <t><figure align="center" anchor="fig:RSOfflinePostAccessTokenAsymmetric"
               title="Access token.</dd>
	</dl>
            <figure anchor="fig_RSOfflinePostAccessTokenAsymmetric">
              <name>Access Token provisioning Provisioning to RS"> the RS</name>
              <artwork align="left"><![CDATA[ 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>
            </figure>
          <t>The client and the RS runs the DTLS handshake using the raw
      public keys established in step 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, authorized based on
      previously established security context.</t>

      <t>F: The
	  <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, response
	  containing a resource representation as payload.</t>
    </list></t>

    <t><figure align="center" anchor="fig:RSOfflineDTLSRequestAndResponse"
               title="Resource payload.</dd>
        </dl>
        <figure anchor="fig_RSOfflineDTLSRequestAndResponse">
          <name>Resource Request and Response protected Protected by DTLS."> DTLS</name>
          <artwork align="left"><![CDATA[ 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></t>
        </figure>
      </section>
      <!-- ************************** -->

<section anchor="introspectionAidedTokenValidation" title="Introspection numbered="true" toc="default">
        <name>Introspection Aided Token Validation"> Validation</name>
        <t>In this deployment scenario 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 Thus, the RS can make use of
  token introspection.  This access procedure involves steps A-F (A)-(F) of
  <xref target="fig:protocolFlow"/>, target="fig_protocolFlow" format="default"/> but assumes steps A (A) and B (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 pre-provisioned preprovisioned access token has to be long-lived. long lived.  Since the client
  is constrained, the token will not be self contained (i.e. 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 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 B, which are shown in
    <xref target="fig:cOffline"/>. target="fig_cOffline" format="default"/>.
        </t>
        <t>Authorization consent from the resource owner can be pre-configured, 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, car that he buys a generic key that he for and
    wants to use with the car.  To authorize the key fob fob, he connects it
    to his computer that then provides the UI for the device.  After
    that
    that, OAuth 2.0 implicit flow can be used to authorize the key for
    his car at the car manufacturers AS.</t>
        <t>Note: In this example example, the client does not know the exact door it
    will be used to access since the token request is not send sent at the
    time of access. So the scope and audience 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>

    <t>
      <list style="hanging">
        <t>A: The
        <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 Audience audience parameter set to  "PACS1337"
	(PACS, Physical
	(Physical Access System), System (PACS)), a value the 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. (e.g., via DTLS)
	  using a pre-shared security context (psk, rpk (pre-shared key (PSK), RPK, or certificate).</t>

        <t>B: The
	  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.
        </t>
      </list>
    </t>
        </dd>
        </dl>
        <t>Note: In this example example, we are using a symmetric key for a multi-RS
	audience, which is not recommended normally (see <xref target="audience"/>).
    However target="audience"
	format="default"/>).
	However, in this case case, the risk is deemed to be acceptable, since
	all the doors are part of the same physical access control system,
    and therefore system;
	therefore, the risk of a malicious RS impersonating the client towards
	another RS is low.</t>

    <t><figure align="center" anchor="fig:cOffline"
               title="Token
        <figure anchor="fig_cOffline">
          <name>Token Request and Response using Using Client Credentials."> Credentials</name>
          <artwork align="left"><![CDATA[ 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>
        </figure>
        <t>The information contained in the Request-Payload and the
	Response-Payload is shown in <xref target="fig:cOfflineReq"/>. target="fig_cOfflineReq" format="default"/>.
        </t>
        <figure align="center" anchor="fig:cOfflineReq"
             title="Request anchor="fig_cOfflineReq">
          <name>Request and Response Payload for the C offline">
      <artwork align="left"><![CDATA[ Offline</name>
          <sourcecode name="" type="cbor-diag"><![CDATA[
Request-Payload:
{
  "client_id" : "keyfob",
  "audience" : "PACS1337"
}

Response-Payload:
{
  "access_token" : b64'VGVzdCB0b2tlbg==',
  "cnf" : {
    "COSE_Key" : {
      "kid" : b64'c29tZSBwdWJsaWMga2V5IGlk',
      "kty" : "oct",
      "alg" : "HS256",
      "k": b64'ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE'
    }
  }
}
      ]]></artwork>
    </figure></t>

    <t>The
      ]]></sourcecode>
        </figure>
        <t>In this case, the access token in this case is just an opaque byte string referencing
   the authorization information at the AS.</t>

    <t><list style="hanging">
        <t>C: Next,
        <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.</t>

        <t>D: The 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 example, the RS and
	  AS are assumed to have performed mutual authentication using a pre
	shared pre-shared security
	  context (psk, rpk (PSK, RPK, or certificate) with the RS acting as the DTLS client.
        </t>

        <t>E: The 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 (cnf) 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"/>
	target="fig_cOfflineIntroReq" format="default"/> assumes a pre-established preestablished key (e.g.
	(e.g., one
	used by the client and the RS for a previous token) that is now only
	referenced by its key-identifier 'kid'.
	</t> key identifier 'kid'.</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>

        <t><figure align="center" anchor="fig:cOfflineIntrospection"
            title="Token
	  </dd>
	</dl>
            <figure anchor="fig_cOfflineIntrospection">
              <name>Token Introspection for the C offline"> Offline</name>
              <artwork align="left"><![CDATA[ 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>
            </figure>
            <t>The information contained in the Request-Payload and the
        Response-Payload is shown in <xref target="fig:cOfflineIntroReq"/>. target="fig_cOfflineIntroReq" format="default"/>.

            </t>
            <figure align="center" anchor="fig:cOfflineIntroReq"
                title="Request anchor="fig_cOfflineIntroReq">
              <name>Request and Response Payload for Introspection">
          <artwork align="left"><![CDATA[ Introspection</name>
              <sourcecode name="" type="cbor-diag"><![CDATA[
Request-Payload:
{
  "token" : b64'VGVzdCB0b2tlbg==',
  "client_id" : "FrontDoor",
}

Response-Payload:
{
  "active" : true,
  "aud" : "lockOfDoor4711",
  "scope" : "open, close",
  "iat" : 1563454000,
  "cnf" : {
    "kid" : b64'c29tZSBwdWJsaWMga2V5IGlk'
  }
}
          ]]></artwork>
        </figure></t>
      </list>
  </t>

<t>
    <list style="hanging">
        <t>
            The
          ]]></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>
        <t>
	    locked.</t>
<!--[rfced] We are having trouble parsing the following sentence. Please
let us know how we may clarify.

Original:
      F: The RS responds with a appropriate over the secure DTLS
      channel.
        </t>
    </list>
</t>
        <t><figure align="center" anchor="fig:cOfflineDTLSRequestAndResponse"
            title="Resource request and

Perhaps:
      F: The RS responds with an appropriate response protected over the secure DTLS
      channel.
-->
	    <dl newline="false" spacing="normal" indent="4">
            <dt>F:</dt>
	    <dd>The RS responds with an appropriate over the secure DTLS channel.</dd>
        </dl>
        <figure anchor="fig_cOfflineDTLSRequestAndResponse">
          <name>Resource Request and Response Protected by OSCORE"> OSCORE</name>
          <artwork align="left"><![CDATA[ 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></t>
        </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"/>
      was 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

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

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

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

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

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