File: rfc9200.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (6876 lines) | stat: -rw-r--r-- 397,999 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9200: Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)</title>
<meta content="Ludwig Seitz" name="author">
<meta content="Göran Selander" name="author">
<meta content="Erik Wahlstroem" name="author">
<meta content="Samuel Erdtman" name="author">
<meta content="Hannes Tschofenig" name="author">
<meta content="
       This specification defines a framework for authentication and
      authorization in Internet of Things (IoT) environments called ACE‑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.
       
    " name="description">
<meta content="xml2rfc 3.14.2" name="generator">
<meta content="CoAP" name="keyword">
<meta content="OAuth 2.0" name="keyword">
<meta content="Access Control" name="keyword">
<meta content="Authorization" name="keyword">
<meta content="Internet of Things" name="keyword">
<meta content="9200" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.14.2
    Python 3.9.13
    appdirs 1.4.4
    ConfigArgParse 1.5.3
    google-i18n-address 2.5.1
    html5lib 1.1
    intervaltree 3.1.0
    Jinja2 3.1.2
    kitchen 1.2.6
    lxml 4.9.0
    MarkupSafe 2.1.1
    pycountry 22.3.5
    PyYAML 6.0
    requests 2.28.0
    setuptools 44.1.1
    six 1.16.0
    weasyprint 56.1
-->
<link href="rfc9200.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  display: table;
  border: none;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.ulBare, li.ulBare {
  margin-left: 0em !important;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  pre.breakable {
    break-inside: auto;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr {
  break-inside: avoid;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9200" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz-45" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9200</td>
<td class="center">ACE-OAuth</td>
<td class="right">August 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Seitz, et al.</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9200" class="eref">9200</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-08" class="published">August 2022</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">L. Seitz</div>
<div class="org">Combitech</div>
</div>
<div class="author">
      <div class="author-name">G. Selander</div>
<div class="org">Ericsson</div>
</div>
<div class="author">
      <div class="author-name">E. Wahlstroem</div>
</div>
<div class="author">
      <div class="author-name">S. Erdtman</div>
<div class="org">Spotify AB</div>
</div>
<div class="author">
      <div class="author-name">H. Tschofenig</div>
<div class="org">Arm Ltd.</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9200</h1>
<h1 id="title">Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This specification defines a framework for authentication and
      authorization in Internet of Things (IoT) environments called ACE‑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.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9200">https://www.rfc-editor.org/info/rfc9200</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-overview" class="xref">Overview</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-oauth-20" class="xref">OAuth 2.0</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-coap" class="xref">CoAP</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-protocol-interactions" class="xref">Protocol Interactions</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-framework" class="xref">Framework</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-discovering-authorization-s" class="xref">Discovering Authorization Servers</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-unauthorized-resource-reque" class="xref">Unauthorized Resource Request Message</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-as-request-creation-hints" class="xref">AS Request Creation Hints</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.3.2.1">
                    <p id="section-toc.1-1.5.2.3.2.1.1"><a href="#section-5.3.1" class="xref">5.3.1</a>.  <a href="#name-the-client-nonce-parameter" class="xref">The Client-Nonce Parameter</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-authorization-grants" class="xref">Authorization Grants</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-client-credentials" class="xref">Client Credentials</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.6">
                <p id="section-toc.1-1.5.2.6.1"><a href="#section-5.6" class="xref">5.6</a>.  <a href="#name-as-authentication" class="xref">AS Authentication</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.7">
                <p id="section-toc.1-1.5.2.7.1"><a href="#section-5.7" class="xref">5.7</a>.  <a href="#name-the-authorization-endpoint" class="xref">The Authorization Endpoint</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8">
                <p id="section-toc.1-1.5.2.8.1"><a href="#section-5.8" class="xref">5.8</a>.  <a href="#name-the-token-endpoint" class="xref">The Token Endpoint</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8.2.1">
                    <p id="section-toc.1-1.5.2.8.2.1.1"><a href="#section-5.8.1" class="xref">5.8.1</a>.  <a href="#name-client-to-as-request" class="xref">Client-to-AS Request</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8.2.2">
                    <p id="section-toc.1-1.5.2.8.2.2.1"><a href="#section-5.8.2" class="xref">5.8.2</a>.  <a href="#name-as-to-client-response" class="xref">AS-to-Client Response</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8.2.3">
                    <p id="section-toc.1-1.5.2.8.2.3.1"><a href="#section-5.8.3" class="xref">5.8.3</a>.  <a href="#name-error-response" class="xref">Error Response</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8.2.4">
                    <p id="section-toc.1-1.5.2.8.2.4.1"><a href="#section-5.8.4" class="xref">5.8.4</a>.  <a href="#name-request-and-response-parame" class="xref">Request and Response Parameters</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8.2.4.2.1">
                        <p id="section-toc.1-1.5.2.8.2.4.2.1.1"><a href="#section-5.8.4.1" class="xref">5.8.4.1</a>.  <a href="#name-grant-type" class="xref">Grant Type</a></p>
</li>
                      <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8.2.4.2.2">
                        <p id="section-toc.1-1.5.2.8.2.4.2.2.1"><a href="#section-5.8.4.2" class="xref">5.8.4.2</a>.  <a href="#name-token-type" class="xref">Token Type</a></p>
</li>
                      <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8.2.4.2.3">
                        <p id="section-toc.1-1.5.2.8.2.4.2.3.1"><a href="#section-5.8.4.3" class="xref">5.8.4.3</a>.  <a href="#name-profile" class="xref">Profile</a></p>
</li>
                      <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8.2.4.2.4">
                        <p id="section-toc.1-1.5.2.8.2.4.2.4.1"><a href="#section-5.8.4.4" class="xref">5.8.4.4</a>.  <a href="#name-client-nonce" class="xref">Client-Nonce</a></p>
</li>
                    </ul>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8.2.5">
                    <p id="section-toc.1-1.5.2.8.2.5.1"><a href="#section-5.8.5" class="xref">5.8.5</a>.  <a href="#name-mapping-parameters-to-cbor" class="xref">Mapping Parameters to CBOR</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.9">
                <p id="section-toc.1-1.5.2.9.1"><a href="#section-5.9" class="xref">5.9</a>.  <a href="#name-the-introspection-endpoint" class="xref">The Introspection Endpoint</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.9.2.1">
                    <p id="section-toc.1-1.5.2.9.2.1.1"><a href="#section-5.9.1" class="xref">5.9.1</a>.  <a href="#name-introspection-request" class="xref">Introspection Request</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.9.2.2">
                    <p id="section-toc.1-1.5.2.9.2.2.1"><a href="#section-5.9.2" class="xref">5.9.2</a>.  <a href="#name-introspection-response" class="xref">Introspection Response</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.9.2.3">
                    <p id="section-toc.1-1.5.2.9.2.3.1"><a href="#section-5.9.3" class="xref">5.9.3</a>.  <a href="#name-error-response-2" class="xref">Error Response</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.9.2.4">
                    <p id="section-toc.1-1.5.2.9.2.4.1"><a href="#section-5.9.4" class="xref">5.9.4</a>.  <a href="#name-mapping-introspection-param" class="xref">Mapping Introspection Parameters to CBOR</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.10">
                <p id="section-toc.1-1.5.2.10.1"><a href="#section-5.10" class="xref">5.10</a>. <a href="#name-the-access-token" class="xref">The Access Token</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.10.2.1">
                    <p id="section-toc.1-1.5.2.10.2.1.1"><a href="#section-5.10.1" class="xref">5.10.1</a>.  <a href="#name-the-authorization-informati" class="xref">The Authorization Information Endpoint</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.10.2.1.2.1">
                        <p id="section-toc.1-1.5.2.10.2.1.2.1.1"><a href="#section-5.10.1.1" class="xref">5.10.1.1</a>.  <a href="#name-verifying-an-access-token" class="xref">Verifying an Access Token</a></p>
</li>
                      <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.10.2.1.2.2">
                        <p id="section-toc.1-1.5.2.10.2.1.2.2.1"><a href="#section-5.10.1.2" class="xref">5.10.1.2</a>.  <a href="#name-protecting-the-authorizatio" class="xref">Protecting the Authorization Information Endpoint</a></p>
</li>
                    </ul>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.10.2.2">
                    <p id="section-toc.1-1.5.2.10.2.2.1"><a href="#section-5.10.2" class="xref">5.10.2</a>.  <a href="#name-client-requests-to-the-rs" class="xref">Client Requests to the RS</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.10.2.3">
                    <p id="section-toc.1-1.5.2.10.2.3.1"><a href="#section-5.10.3" class="xref">5.10.3</a>.  <a href="#name-token-expiration" class="xref">Token Expiration</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.10.2.4">
                    <p id="section-toc.1-1.5.2.10.2.4.1"><a href="#section-5.10.4" class="xref">5.10.4</a>.  <a href="#name-key-expiration" class="xref">Key Expiration</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-protecting-tokens" class="xref">Protecting Tokens</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-communication-security" class="xref">Communication Security</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-long-term-credentials" class="xref">Long-Term Credentials</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.4">
                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-unprotected-as-request-crea" class="xref">Unprotected AS Request Creation Hints</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.5">
                <p id="section-toc.1-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-minimal-security-requiremen" class="xref">Minimal Security Requirements for Communication</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.6">
                <p id="section-toc.1-1.6.2.6.1"><a href="#section-6.6" class="xref">6.6</a>.  <a href="#name-token-freshness-and-expirat" class="xref">Token Freshness and Expiration</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.7">
                <p id="section-toc.1-1.6.2.7.1"><a href="#section-6.7" class="xref">6.7</a>.  <a href="#name-combining-profiles" class="xref">Combining Profiles</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.8">
                <p id="section-toc.1-1.6.2.8.1"><a href="#section-6.8" class="xref">6.8</a>.  <a href="#name-unprotected-information" class="xref">Unprotected Information</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.9">
                <p id="section-toc.1-1.6.2.9.1"><a href="#section-6.9" class="xref">6.9</a>.  <a href="#name-identifying-audiences" class="xref">Identifying Audiences</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.10">
                <p id="section-toc.1-1.6.2.10.1"><a href="#section-6.10" class="xref">6.10</a>. <a href="#name-denial-of-service-against-o" class="xref">Denial of Service Against or with Introspection</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-privacy-considerations" class="xref">Privacy Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-ace-authorization-server-re" class="xref">ACE Authorization Server Request Creation Hints</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-core-resource-types" class="xref">CoRE Resource Types</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-oauth-extensions-errors" class="xref">OAuth Extensions Errors</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.4">
                <p id="section-toc.1-1.8.2.4.1"><a href="#section-8.4" class="xref">8.4</a>.  <a href="#name-oauth-error-code-cbor-mappi" class="xref">OAuth Error Code CBOR Mappings</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.5">
                <p id="section-toc.1-1.8.2.5.1"><a href="#section-8.5" class="xref">8.5</a>.  <a href="#name-oauth-grant-type-cbor-mappi" class="xref">OAuth Grant Type CBOR Mappings</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.6">
                <p id="section-toc.1-1.8.2.6.1"><a href="#section-8.6" class="xref">8.6</a>.  <a href="#name-oauth-access-token-types" class="xref">OAuth Access Token Types</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.7">
                <p id="section-toc.1-1.8.2.7.1"><a href="#section-8.7" class="xref">8.7</a>.  <a href="#name-oauth-access-token-type-cbo" class="xref">OAuth Access Token Type CBOR Mappings</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.7.2.1">
                    <p id="section-toc.1-1.8.2.7.2.1.1"><a href="#section-8.7.1" class="xref">8.7.1</a>.  <a href="#name-initial-registry-contents" class="xref">Initial Registry Contents</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.8">
                <p id="section-toc.1-1.8.2.8.1"><a href="#section-8.8" class="xref">8.8</a>.  <a href="#name-ace-profiles" class="xref">ACE Profiles</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.9">
                <p id="section-toc.1-1.8.2.9.1"><a href="#section-8.9" class="xref">8.9</a>.  <a href="#name-oauth-parameters" class="xref">OAuth Parameters</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.10">
                <p id="section-toc.1-1.8.2.10.1"><a href="#section-8.10" class="xref">8.10</a>. <a href="#name-oauth-parameters-cbor-mappi" class="xref">OAuth Parameters CBOR Mappings</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.11">
                <p id="section-toc.1-1.8.2.11.1"><a href="#section-8.11" class="xref">8.11</a>. <a href="#name-oauth-introspection-respons" class="xref">OAuth Introspection Response Parameters</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.12">
                <p id="section-toc.1-1.8.2.12.1"><a href="#section-8.12" class="xref">8.12</a>. <a href="#name-oauth-token-introspection-r" class="xref">OAuth Token Introspection Response CBOR Mappings</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.13">
                <p id="section-toc.1-1.8.2.13.1"><a href="#section-8.13" class="xref">8.13</a>. <a href="#name-json-web-token-claims" class="xref">JSON Web Token Claims</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.14">
                <p id="section-toc.1-1.8.2.14.1"><a href="#section-8.14" class="xref">8.14</a>. <a href="#name-cbor-web-token-claims" class="xref">CBOR Web Token Claims</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.15">
                <p id="section-toc.1-1.8.2.15.1"><a href="#section-8.15" class="xref">8.15</a>. <a href="#name-media-type-registration" class="xref">Media Type Registration</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.16">
                <p id="section-toc.1-1.8.2.16.1"><a href="#section-8.16" class="xref">8.16</a>. <a href="#name-coap-content-formats" class="xref">CoAP Content-Formats</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.17">
                <p id="section-toc.1-1.8.2.17.1"><a href="#section-8.17" class="xref">8.17</a>. <a href="#name-expert-review-instructions" class="xref">Expert Review Instructions</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-design-justification" class="xref">Design Justification</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-B" class="xref">Appendix B</a>.  <a href="#name-roles-and-responsibilities" class="xref">Roles and Responsibilities</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-C" class="xref">Appendix C</a>.  <a href="#name-requirements-on-profiles" class="xref">Requirements on Profiles</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#appendix-D" class="xref">Appendix D</a>.  <a href="#name-assumptions-on-as-knowledge" class="xref">Assumptions on AS Knowledge about the C and RS</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#appendix-E" class="xref">Appendix E</a>.  <a href="#name-differences-to-oauth-20" class="xref">Differences to OAuth 2.0</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#appendix-F" class="xref">Appendix F</a>.  <a href="#name-deployment-examples" class="xref">Deployment Examples</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15.2.1">
                <p id="section-toc.1-1.15.2.1.1"><a href="#appendix-F.1" class="xref">F.1</a>.  <a href="#name-local-token-validation" class="xref">Local Token Validation</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15.2.2">
                <p id="section-toc.1-1.15.2.2.1"><a href="#appendix-F.2" class="xref">F.2</a>.  <a href="#name-introspection-aided-token-v" class="xref">Introspection Aided Token Validation</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#appendix-G" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17">
            <p id="section-toc.1-1.17.1"><a href="#appendix-H" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">Authorization is the process for granting approval to an entity to
   access a generic resource <span>[<a href="#RFC4949" class="xref">RFC4949</a>]</span>. The authorization
   task itself can best be described as granting access to a requesting client for
   a resource hosted on a device, i.e., the resource server (RS).  This exchange is
   mediated by one or multiple authorization servers (ASes). Managing
   authorization for a large number of devices and users can be a complex task.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">While prior work on authorization solutions for the Web and for the mobile
   environment also applies to the Internet of Things (IoT) environment, many
   IoT devices are constrained, for example, in terms of processing
   capabilities, available memory, etc. For such devices, the Constrained
   Application Protocol (CoAP) <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> can alleviate some
   resource concerns when used instead of HTTP to implement the communication
   flows of this specification.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3"><a href="#constraints" class="xref">Appendix A</a> gives an overview of the constraints
   considered in this design, and a more detailed treatment of constraints can
   be found in <span>[<a href="#RFC7228" class="xref">RFC7228</a>]</span>.  This design aims to accommodate
   different IoT deployments as well as a continuous range of device and network
   capabilities.  Taking energy consumption as an example, at one end, there are
   energy-harvesting or  battery-powered devices that have a tight power
   budget; on the other end, there are mains-powered devices; and all levels exist in
   between.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">Hence, IoT devices may be very different in terms of available processing
   and message exchange capabilities, and there is a need to support many
     different authorization use cases <span>[<a href="#RFC7744" class="xref">RFC7744</a>]</span>.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">This specification describes a framework for Authentication and Authorization
   for Constrained Environments (ACE) built on reuse of OAuth 2.0
   <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>, thereby extending authorization to Internet of Things
   devices.  This specification contains the necessary building blocks
   for adjusting OAuth 2.0 to IoT environments.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">Profiles of this framework are available in separate specifications, such as
   <span>[<a href="#RFC9202" class="xref">RFC9202</a>]</span> or <span>[<a href="#RFC9203" class="xref">RFC9203</a>]</span>. 
    Such profiles may specify the use of the framework for a specific security protocol 
    and the underlying transports for use in a specific deployment environment to improve interoperability.
   Implementations may claim conformance with a specific profile, whereby
   implementations utilizing the same profile interoperate, while
   implementations of different profiles are not expected to be interoperable.
   More powerful devices, such as mobile phones and tablets, may implement multiple
   profiles and will therefore be able to interact with a wider range of constrained devices. 
    Requirements on profiles are described at contextually
   appropriate places throughout this specification and also summarized in
   <a href="#app_profileRequirements" class="xref">Appendix C</a>.<a href="#section-1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="terminology">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>", "<span class="bcp14">MAY</span>", and
"<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">Certain security-related terms, such as "authentication",
"authorization", "confidentiality", "(data) integrity", "message
authentication code", and "verify", are taken from <span>[<a href="#RFC4949" class="xref">RFC4949</a>]</span>.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">Since exchanges in this specification are described as RESTful protocol
    interactions, HTTP <span>[<a href="#RFC9110" class="xref">RFC9110</a>]</span> offers useful terminology.
    (Note that "RESTful" refers to the Representational State Transfer (REST) architecture.)<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4">Terminology for entities in the architecture is defined in OAuth
  2.0 <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>, such as client (C), resource server (RS),
  and authorization server (AS).<a href="#section-2-4" class="pilcrow">¶</a></p>
<p id="section-2-5">Note that the term "endpoint" is used here following its OAuth
definition, which is to denote resources, such as token and
introspection at the AS and authz-info at the RS (see <a href="#tokenAuthInfoEndpoint" class="xref">Section 5.10.1</a> for a definition of the authz-info endpoint).
The CoAP definition, which is "[a]n entity
participating in the CoAP protocol" <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>, is not used in this specification.<a href="#section-2-5" class="pilcrow">¶</a></p>
<p id="section-2-6">The specification in this document is called the "framework" or "ACE framework".
When referring to "profiles of this framework", it refers to additional specifications that
define the use of this specification with concrete transport and communication
security protocols (e.g., CoAP over DTLS).<a href="#section-2-6" class="pilcrow">¶</a></p>
<p id="section-2-7">The term "Access Information" is used for parameters, other than the access token, provided to the client by the AS to enable it to access the RS
(e.g., public key of the RS or profile supported by RS).<a href="#section-2-7" class="pilcrow">¶</a></p>
<p id="section-2-8">The term "authorization information" is used to denote all information,
      including the claims of relevant access tokens, that an RS uses to determine whether an access request should be granted.<a href="#section-2-8" class="pilcrow">¶</a></p>
<p id="section-2-9">Throughout this document, examples for CBOR data items are expressed in CBOR extended diagnostic notation as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc8949#section-8" class="relref">Section 8</a> of [<a href="#RFC8949" class="xref">RFC8949</a>]</span> and <span><a href="https://www.rfc-editor.org/rfc/rfc8610#appendix-G" class="relref">Appendix G</a> of [<a href="#RFC8610" class="xref">RFC8610</a>]</span> ("diagnostic notation"), unless noted otherwise. We often use diagnostic notation comments to provide a textual representation of the numeric parameter names and values.<a href="#section-2-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="overview">
<section id="section-3">
      <h2 id="name-overview">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-overview" class="section-name selfRef">Overview</a>
      </h2>
<p id="section-3-1">This specification defines the ACE framework for authorization in the Internet
      of Things environment. It consists of a set of building blocks.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
  The basic block is the OAuth 2.0 <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
  framework, which enjoys widespread deployment.  Many IoT devices can support
  OAuth 2.0 without any additional extensions, but for certain constrained
  settings, additional profiling is needed.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">Another building block is the lightweight web transfer protocol CoAP
  <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>, 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 <span>[<a href="#RFC9113" class="xref">RFC9113</a>]</span>,
  Message Queuing Telemetry Transport (MQTT) <span>[<a href="#MQTT5.0" class="xref">MQTT5.0</a>]</span>,
  Bluetooth Low Energy (BLE) <span>[<a href="#BLE" class="xref">BLE</a>]</span>, and QUIC <span>[<a href="#RFC9000" class="xref">RFC9000</a>]</span>.  Note that this document specifies
  protocol exchanges in terms of RESTful verbs, such as GET and POST.
  Future profiles using protocols that do not support these verbs <span class="bcp14">MUST</span>
  specify how the corresponding protocol messages are transmitted instead.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">A third building block is the Concise Binary Object Representation
  (CBOR) <span>[<a href="#RFC8949" class="xref">RFC8949</a>]</span>, for encodings where JSON
  <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span> 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 <span class="bcp14">RECOMMENDED</span>.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">A fourth building block is CBOR Object Signing and Encryption (COSE)
  <span>[<a href="#RFC8152" class="xref">RFC8152</a>]</span>, which enables object-level layer security as an
  alternative or complement to transport layer security (DTLS
    <span>[<a href="#RFC6347" class="xref">RFC6347</a>]</span> <span>[<a href="#RFC9147" class="xref">RFC9147</a>]</span> or TLS <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>). COSE is used to
    secure self-contained tokens, such as proof-of-possession (PoP) tokens,
    which are an extension to the OAuth bearer tokens. The default token format
    is defined in CBOR Web Token (CWT) <span>[<a href="#RFC8392" class="xref">RFC8392</a>]</span>.
    Application-layer security for CoAP using COSE can be provided with Object Security for
    Constrained RESTful Environments (OSCORE)
    <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span>.<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">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 <span>[<a href="#RFC7228" class="xref">RFC7228</a>]</span>, and a description
  of how the building blocks mentioned above relate to the various constraints
  can be found in <a href="#constraints" class="xref">Appendix A</a>.<a href="#section-3-6" class="pilcrow">¶</a></p>
<p id="section-3-7">Luckily, not every IoT device suffers from all constraints.  Nevertheless, the ACE
  framework takes all these aspects into account and allows
  several different deployment variants to coexist, rather than mandating a
  one-size-fits-all solution.  It is important to cover the wide
  range of possible interworking use cases and the different requirements from
  a security point of view.  Once IoT deployments mature, popular deployment
  variants will be documented in the form of ACE profiles.<a href="#section-3-7" class="pilcrow">¶</a></p>
<div id="oauth2Overview">
<section id="section-3.1">
        <h3 id="name-oauth-20">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-oauth-20" class="section-name selfRef">OAuth 2.0</a>
        </h3>
<p id="section-3.1-1">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.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">A number of OAuth 2.0 terms are used within this specification:<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-3.1-3">
          <dt id="section-3.1-3.1">Access Tokens:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-3.2">
            <p id="section-3.1-3.2.1">
        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.<a href="#section-3.1-3.2.1" class="pilcrow">¶</a></p>
<p id="section-3.1-3.2.2">
        Access tokens can have different formats and various methods
        of utilization (e.g., cryptographic properties) based on the security
        requirements of the given deployment.<a href="#section-3.1-3.2.2" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-3.3">Introspection:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-3.4">
 Introspection is a method for a resource server, or potentially a client,
 to query the authorization server for the active state and content of a
 received access token.  This is particularly useful in those cases where
 the authorization decisions are very dynamic and/or where the received
 access token itself is an opaque reference, rather than a self-contained
 token.  More information about introspection in OAuth 2.0 can be
 found in <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>.<a href="#section-3.1-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-3.5">Refresh Tokens:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-3.6">
            <p id="section-3.1-3.6.1">
 Refresh tokens are credentials used to obtain access tokens.
 Refresh tokens are issued to the client by the authorization
 server and are used to obtain a new access token when the current
 access token expires or to obtain additional access tokens with
 identical or narrower scope (such access tokens may have a shorter
 lifetime and fewer permissions than authorized by the resource owner).
 Issuing a refresh token is optional at the discretion of the
 authorization server.  If the authorization server issues a refresh
 token, it is included when issuing an access token (i.e., step (B) in
 <a href="#fig_protocolFlow" class="xref">Figure 1</a>).<a href="#section-3.1-3.6.1" class="pilcrow">¶</a></p>
<p id="section-3.1-3.6.2">
 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.<a href="#section-3.1-3.6.2" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-3.7">Proof-of-Possession Tokens:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-3.8">
            <p id="section-3.1-3.8.1">
        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).<a href="#section-3.1-3.8.1" class="pilcrow">¶</a></p>
<p id="section-3.1-3.8.2">
        The proof-of-possession security concept used here assumes that
 the AS acts as a trusted third party that binds keys to tokens.
 In the case of access tokens, these so-called PoP keys are then used by
 the client to demonstrate the possession of the secret to the RS when
 accessing the resource.  The RS, when receiving an access token, needs
 to verify that the key used by the client matches the one bound to the
 access token.  When this specification uses the term "access token", it
 is assumed to be a PoP access token unless specifically stated
 otherwise.<a href="#section-3.1-3.8.2" class="pilcrow">¶</a></p>
<p id="section-3.1-3.8.3">
        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.<a href="#section-3.1-3.8.3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-3.1-3.8.4">
              <dt id="section-3.1-3.8.4.1">Symmetric PoP key:</dt>
              <dd style="margin-left: 1.5em" id="section-3.1-3.8.4.2">
                <p id="section-3.1-3.8.4.2.1">
              The AS generates a random, symmetric PoP key.  The key is either
              stored to be returned on introspection calls or included in the
       token.  Either the whole token or only the key <span class="bcp14">MUST</span> be encrypted
       in the latter case.  The PoP key is also returned to
       client together with the token, protected by the secure channel.<a href="#section-3.1-3.8.4.2.1" class="pilcrow">¶</a></p>
</dd>
              <dd class="break"></dd>
<dt id="section-3.1-3.8.4.3">Asymmetric PoP key:</dt>
              <dd style="margin-left: 1.5em" id="section-3.1-3.8.4.4">
          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.<a href="#section-3.1-3.8.4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
<p id="section-3.1-3.8.5"> The token is either a simple reference
 or a structured information object (e.g., CWT <span>[<a href="#RFC8392" class="xref">RFC8392</a>]</span>)
 protected by a cryptographic wrapper (e.g., COSE <span>[<a href="#RFC8152" class="xref">RFC8152</a>]</span>).  The choice of PoP key does not necessarily imply
 a specific credential type for the integrity protection of the
 token.<a href="#section-3.1-3.8.5" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-3.9">Scopes and Permissions:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-3.10">
            <p id="section-3.1-3.10.1">
         In OAuth 2.0, the client specifies the type of permissions it is
         seeking to obtain (via the <code>scope</code> parameter) in the access token
  request.  In turn, the AS may use the <code>scope</code> 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 <a href="#oauthProfile" class="xref">Section 5</a>) for such requests and responses.<a href="#section-3.1-3.10.1" class="pilcrow">¶</a></p>
<p id="section-3.1-3.10.2">
         The values of the <code>scope</code> parameter in OAuth 2.0 are expressed as a list
  of space-delimited, case-sensitive strings with a semantic that is
  well known to the AS and the RS.
         More details about the concept of scopes are found under
         <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-3.3" class="relref">Section 3.3</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-3.1-3.10.2" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-3.11">Claims:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-3.12">
            <p id="section-3.1-3.12.1">
      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 <code>iss</code> claim) and
      what audience the access token is intended for (via the <code>aud</code> claim).
 The audience of an access token can be a specific resource, one resource, or
 many resource servers.  The resource owner policies influence what
 claims are put into the access token by the authorization server.<a href="#section-3.1-3.12.1" class="pilcrow">¶</a></p>
<p id="section-3.1-3.12.2">
        While the structure and encoding of the access token varies throughout
        deployments, a standardized format has been defined with the JSON Web
        Token (JWT) <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span>, where claims are encoded as a
 JSON object.  In <span>[<a href="#RFC8392" class="xref">RFC8392</a>]</span>, the CBOR Web Token (CWT)
 has been defined as an equivalent format using CBOR encoding.<a href="#section-3.1-3.12.2" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-3.13">Token and Introspection Endpoints:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-3.14">
            <p id="section-3.1-3.14.1">
      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).<a href="#section-3.1-3.14.1" class="pilcrow">¶</a></p>
<p id="section-3.1-3.14.2">
      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.)<a href="#section-3.1-3.14.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="coap">
<section id="section-3.2">
        <h3 id="name-coap">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-coap" class="section-name selfRef">CoAP</a>
        </h3>
<p id="section-3.2-1">
    CoAP is an application-layer protocol similar to HTTP but specifically
    designed for constrained environments.  CoAP typically uses
    datagram-oriented transport, such as UDP, where reordering and loss
    of packets can occur.  A security solution needs to take the latter aspects
    into account.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">While HTTP uses headers and query strings to convey additional
    information about a request, CoAP encodes such information into header
    parameters called 'options'.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2-3">CoAP supports application-layer fragmentation of the CoAP payloads
    through block-wise transfers <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span>.  However,
    block-wise transfer does not increase the size limits of CoAP options;
    therefore, data encoded in options has to be kept small.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4">Transport layer security for CoAP can be provided by DTLS or TLS
  <span>[<a href="#RFC6347" class="xref">RFC6347</a>]</span> <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>
          <span>[<a href="#RFC9147" class="xref">RFC9147</a>]</span>.
    CoAP defines a number of proxy operations that require transport layer
    security to be terminated at the proxy. One approach for protecting CoAP communication
    end-to-end through proxies, and also to support security for CoAP over
    a different transport in a uniform way, is to provide security at the application
    layer using an object-based security mechanism, such as COSE <span>[<a href="#RFC8152" class="xref">RFC8152</a>]</span>.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.2-5">
    One application of COSE is OSCORE
    <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span>, 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.<a href="#section-3.2-5" class="pilcrow">¶</a></p>
<p id="section-3.2-6">In this framework, the use of CoAP as replacement for HTTP is <span class="bcp14">RECOMMENDED</span>
  for use in constrained environments.  For communication security, this
  framework does not make an explicit protocol recommendation, since the choice
  depends on the requirements of the specific application.  DTLS
  <span>[<a href="#RFC6347" class="xref">RFC6347</a>]</span> <span>[<a href="#RFC9147" class="xref">RFC9147</a>]</span> and OSCORE
  <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span> are mentioned as examples; other protocols fulfilling
  the requirements from <a href="#minimalCommSecReq" class="xref">Section 6.5</a> are also
  applicable.<a href="#section-3.2-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="specs">
<section id="section-4">
      <h2 id="name-protocol-interactions">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-protocol-interactions" class="section-name selfRef">Protocol Interactions</a>
      </h2>
<p id="section-4-1">
    The ACE framework is based on the OAuth 2.0 protocol interactions using
    the token endpoint and optionally the introspection endpoint.
    A client obtains an access token, and optionally a refresh token, from an
    AS using the token endpoint and subsequently presents the access token to
    an RS to gain access to a protected resource. In most deployments, the RS can
    process the access token locally; however, in some cases, the RS may present
    it to the AS via the introspection endpoint to get fresh information.
    These interactions are shown in <a href="#fig_protocolFlow" class="xref">Figure 1</a>.  An
    overview of various OAuth concepts is provided in <a href="#oauth2Overview" class="xref">Section 3.1</a>.<a href="#section-4-1" class="pilcrow">¶</a></p>
<span id="name-basic-protocol-flow"></span><div id="fig_protocolFlow">
<figure id="figure-1">
        <div class="alignLeft art-text artwork" id="section-4-2.1">
<pre>
+--------+                               +---------------+
|        |---(A)-- Token Request -------&gt;|               |
|        |                               | Authorization |
|        |&lt;--(B)-- Access Token ---------|    Server     |
|        |    + Access Information       |               |
|        |    + Refresh Token (optional) +---------------+
|        |                                      ^ |
|        |            Introspection Request  (D)| |
| Client |                         Response     | |(E)
|        |            (optional exchange)       | |
|        |                                      | v
|        |                               +--------------+
|        |---(C)-- Token + Request -----&gt;|              |
|        |                               |   Resource   |
|        |&lt;--(F)-- Protected Resource ---|    Server    |
|        |                               |              |
+--------+                               +--------------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-basic-protocol-flow" class="selfRef">Basic Protocol Flow</a>
        </figcaption></figure>
</div>
<span class="break"></span><dl class="dlNewline" id="section-4-3">
        <dt id="section-4-3.1">Requesting an Access Token (A):</dt>
        <dd style="margin-left: 1.5em" id="section-4-3.2">
          <p id="section-4-3.2.1">
      The client makes an access token request to the token endpoint at the AS.
      This framework assumes the use of PoP access tokens (see <a href="#oauth2Overview" class="xref">Section 3.1</a> for a short description) wherein the AS binds a
      key to an access token.  The client may include permissions it seeks to
      obtain and information about the credentials it wants to use for
      proof of possession (e.g., symmetric/asymmetric cryptography or a
      reference to a specific key) of the access token.<a href="#section-4-3.2.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-4-3.3">Access Token Response (B):</dt>
        <dd style="margin-left: 1.5em" id="section-4-3.4">
          <p id="section-4-3.4.1">
      If the request from the client has been successfully verified, 
      authenticated, and authorized, the AS returns an access token and optionally a refresh
      token. Note that only certain grant types support refresh tokens.  The AS
      can also return additional parameters, referred to as "Access
      Information".  In addition to the response parameters defined by OAuth
      2.0 and the PoP access token extension, this framework defines parameters
      that can be used to inform the client about capabilities of the RS, e.g.,
      the profile the RS supports.  More information about these parameters
      can be found in <a href="#tokenParams" class="xref">Section 5.8.4</a>.<a href="#section-4-3.4.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-4-3.5">Resource Request (C):</dt>
        <dd style="margin-left: 1.5em" id="section-4-3.6">
          <p id="section-4-3.6.1">
      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
      <span>[<a href="#RFC9113" class="xref">RFC9113</a>]</span>, QUIC <span>[<a href="#RFC9000" class="xref">RFC9000</a>]</span>,
      MQTT <span>[<a href="#MQTT5.0" class="xref">MQTT5.0</a>]</span>, Bluetooth Low Energy <span>[<a href="#BLE" class="xref">BLE</a>]</span>,
      etc., are also viable candidates.<a href="#section-4-3.6.1" class="pilcrow">¶</a></p>
<p id="section-4-3.6.2">
      Depending on the device limitations and the selected protocol, this
      exchange may be split up into two parts:<a href="#section-4-3.6.2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-4-3.6.3">
            <dt>(1)</dt>
<dd id="section-4-3.6.3.1">the client sends the access token containing, or referencing, the
  authorization information to the RS that will be used for subsequent
  resource requests by the client, and<a href="#section-4-3.6.3.1" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt>(2)</dt>
<dd id="section-4-3.6.3.2">the client makes the resource access request using the communication
  security protocol and other Access Information obtained from the AS.<a href="#section-4-3.6.3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4-3.6.4">
      The client and the RS mutually authenticate using the security protocol
      specified in the profile (see step (B)) and the keys obtained in the access
      token or the Access Information.  The RS verifies that the token is
      integrity protected and originated by the AS. It then compares the claims
      contained in the access token with the resource request. If the RS is
      online, validation can be handed over to the AS using token introspection
      (see messages (D) and (E)) over HTTP or CoAP.<a href="#section-4-3.6.4" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-4-3.7">Token Introspection Request (D):</dt>
        <dd style="margin-left: 1.5em" id="section-4-3.8">
          <p id="section-4-3.8.1">
      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 <a href="#introspectionEndpoint" class="xref">Section 5.9</a> and for HTTP in
      <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>.<a href="#section-4-3.8.1" class="pilcrow">¶</a></p>
<p id="section-4-3.8.2">
      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.<a href="#section-4-3.8.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-4-3.9">Token Introspection Response (E):</dt>
        <dd style="margin-left: 1.5em" id="section-4-3.10">
          <p id="section-4-3.10.1">
      The AS validates the token and returns the most recent parameters, such
      as <code>scope</code>, <code>audience</code>, 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.<a href="#section-4-3.10.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-4-3.11">Protected Resource (F):</dt>
        <dd style="margin-left: 1.5em" id="section-4-3.12">
      If the request from the client is authorized, the RS fulfills the request
      and returns a response with the appropriate response code.  The RS uses
      the dynamically established keys to protect the response according to
      the communication security protocol used.<a href="#section-4-3.12" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-4-4">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 <span>[<a href="#RFC7521" class="xref">RFC7521</a>]</span> and <span>[<a href="#RFC8628" class="xref">RFC8628</a>]</span>).
      What grant type works best depends on the usage scenario; <span>[<a href="#RFC7744" class="xref">RFC7744</a>]</span> describes many different IoT use cases, but
      there are two grant types that cover a majority of these scenarios, namely the
      authorization code grant (described in <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>) and 
      the client credentials grant (described
      in <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-4.4" class="relref">Section 4.4</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>). The authorization
      code grant is a good fit for use with apps running on smartphones and tablets that request access to IoT devices, a common scenario in the smart home environment, where users need to go through an authentication and authorization phase (at least during the initial setup phase). The native apps guidelines described in <span>[<a href="#RFC8252" class="xref">RFC8252</a>]</span> are applicable to this use case. The client credentials grant is a good fit for use with IoT devices where the OAuth client itself is constrained. In such a case, the resource owner has prearranged access rights for the client with the authorization server, which is often accomplished using a commissioning tool.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">
    The consent of the resource owner, for giving a client access to a protected
    resource, can be provided dynamically as in the classical OAuth flows, or it
    could be preconfigured by the resource owner as authorization policies at
    the AS, which the AS evaluates when a token request arrives.  The resource
    owner and the requesting party (i.e., client owner) are not shown in <a href="#fig_protocolFlow" class="xref">Figure 1</a>.<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="section-4-6">
 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.<a href="#section-4-6" class="pilcrow">¶</a></p>
<p id="section-4-7">It is also assumed that the RS has been registered with the AS, potentially in a similar way as the client has been registered with the AS.
 Established keying material between the AS and the RS allows the AS to apply
 cryptographic protection to the access token to ensure that its content cannot
 be modified and, if needed, that the content is confidentiality protected. Confidentiality protection of the access token content would be provided on top of 
 confidentiality protection via a communication security protocol.<a href="#section-4-7" class="pilcrow">¶</a></p>
<p id="section-4-8">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.<a href="#section-4-8" class="pilcrow">¶</a></p>
<p id="section-4-9">
    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 <a href="#asDiscovery" class="xref">Section 5.1</a>; profiles <span class="bcp14">MAY</span> define other procedures for
    discovery.<a href="#section-4-9" class="pilcrow">¶</a></p>
<p id="section-4-10">In Bluetooth Low Energy, for example, advertisements are broadcast by
    a peripheral, including information about the primary services.  In CoAP,
    as a second example, a client can make a request to "/.well-known/core" to
    obtain information about available resources, which are returned in a
    standardized format, as described in <span>[<a href="#RFC6690" class="xref">RFC6690</a>]</span>.<a href="#section-4-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="oauthProfile">
<section id="section-5">
      <h2 id="name-framework">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-framework" class="section-name selfRef">Framework</a>
      </h2>
<p id="section-5-1">The following sections detail the profiling and extensions of OAuth 2.0
  for constrained environments, which constitutes the ACE framework.<a href="#section-5-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5-2">
        <dt id="section-5-2.1">Credential Provisioning</dt>
        <dd style="margin-left: 1.5em" id="section-5-2.2">
          <p id="section-5-2.2.1">
        In constrained environments, it cannot be assumed that the client and the RS
        are part of a common key infrastructure. Therefore, the AS provisions
 credentials and associated information to allow mutual authentication
 between the client and the RS. The resulting security association between the client
 and the RS may then also be used to bind these credentials to the
 access tokens the client uses.<a href="#section-5-2.2.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-5-2.3">Proof of Possession</dt>
        <dd style="margin-left: 1.5em" id="section-5-2.4">
          <p id="section-5-2.4.1">
        The ACE framework, by default, implements proof of possession for
 access tokens, i.e., that the token holder can prove being a holder of
 the key bound to the token.  The binding is provided by the <code>cnf</code> (confirmation)
 claim
 <span>[<a href="#RFC8747" class="xref">RFC8747</a>]</span>, indicating what key is used for
 proof of possession. If a client needs to submit a new access token,
 e.g., to obtain additional access rights, they can request
 that the AS binds this token to the same key as the previous one.<a href="#section-5-2.4.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-5-2.5">ACE Profiles</dt>
        <dd style="margin-left: 1.5em" id="section-5-2.6">
        The client or RS may be limited in the encodings or protocols it
        supports.  To support a variety of different deployment settings,
        specific interactions between the client and RS are defined in an ACE
        profile.  In the ACE framework, the AS is expected to manage the matching
 of compatible profile choices between a client and an RS.  The AS
 informs the client of the selected profile using the <code>ace_profile</code>
 parameter in the token response.<a href="#section-5-2.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-5-3">OAuth 2.0 requires the use of TLS to protect the communication 
  between the AS and client when requesting an access token between the client and RS
  when accessing a resource and between the AS and RS if introspection is used.
  In constrained settings, TLS is not always feasible or desirable.
  Nevertheless, it is <span class="bcp14">REQUIRED</span> that the communications named above are
  encrypted, integrity protected, and protected against message replay.  It is
  also <span class="bcp14">REQUIRED</span> that the communicating endpoints perform mutual authentication.
  Furthermore, it <span class="bcp14">MUST</span> be assured that responses are bound to the requests in
  the sense that the receiver of a response can be certain that the response
  actually belongs to a certain request.  Note that setting up such a secure
  communication may require some unprotected messages to be exchanged first
  (e.g., sending the token from the client to the RS).<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">Profiles <span class="bcp14">MUST</span> specify a communication security protocol between the
      client and RS that provides the features required above.  Profiles
      <span class="bcp14">MUST</span> specify a
      communication security protocol <span class="bcp14">RECOMMENDED</span> to be used between the
      client and AS that provides the features required above.  Profiles <span class="bcp14">MUST</span>
      specify, for  introspection, a communication security protocol
      <span class="bcp14">RECOMMENDED</span> 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.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">In OAuth 2.0, the communication with the Token and the Introspection
  endpoints at the AS is assumed to be via HTTP and may use Uri-query
  parameters.  When profiles of this framework use CoAP instead, it is 
  <span class="bcp14">REQUIRED</span> to use of the following alternative instead of Uri-query
  parameters: The sender (client or RS) encodes the parameters of its request
  as a CBOR map and submits that map as the payload of the POST request.
  The CBOR encoding for a number of  OAuth 2.0 parameters is specified in this
  document; if a profile needs to use other OAuth 2.0 parameters with CoAP, it
  <span class="bcp14">MUST</span> specify their CBOR encoding.<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">Profiles that use CBOR encoding of protocol message parameters at the
  outermost encoding layer <span class="bcp14">MUST</span> use the Content-Format "application/ace+cbor".
  If CoAP is used for communication, the Content-Format <span class="bcp14">MUST</span> be abbreviated
  with the ID: 19 (see <a href="#IANAcoapContentFormat" class="xref">Section 8.16</a>).<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7">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 <span class="bcp14">REQUIRED</span> to use
  CBOR <span>[<a href="#RFC8949" class="xref">RFC8949</a>]</span> instead of JSON.  Depending on the profile,
  the CBOR payload <span class="bcp14">MAY</span> be enclosed in a non-CBOR cryptographic wrapper.<a href="#section-5-7" class="pilcrow">¶</a></p>
<div id="asDiscovery">
<section id="section-5.1">
        <h3 id="name-discovering-authorization-s">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-discovering-authorization-s" class="section-name selfRef">Discovering Authorization Servers</a>
        </h3>
<p id="section-5.1-1">The C must discover the AS in charge of the RS to determine where to request the
access token. To do so, the C 1) must find out the AS URI to which the token
request message must be sent and 2) <span class="bcp14">MUST</span> validate that the AS with this
URI is authorized to provide access tokens for this RS.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2"> In order to determine the AS URI, the C <span class="bcp14">MAY</span> 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 <a href="#rreq" class="xref">Section 5.2</a>). How the C validates the
AS authorization is not in scope for this document. The C may, for example, ask
its owner if this AS is authorized for this RS. The C may also use a
mechanism that addresses both problems at once (e.g., by querying a dedicated secure service provided by the client owner) .<a href="#section-5.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="rreq">
<section id="section-5.2">
        <h3 id="name-unauthorized-resource-reque">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-unauthorized-resource-reque" class="section-name selfRef">Unauthorized Resource Request Message</a>
        </h3>
<p id="section-5.2-1">An Unauthorized Resource Request message is a request for any
 resource hosted by the RS for which the client does not have authorization granted.
 The RSs <span class="bcp14">MUST</span>
 treat any request for a protected resource as an Unauthorized Resource
 Request message when any of the following hold:<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.2-2.1">The request has been received on an unsecured channel.<a href="#section-5.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.2">The RS has no valid access token for the sender of the request
   regarding the requested action on that resource.<a href="#section-5.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.3">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.<a href="#section-5.2-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.2-3">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 <span class="bcp14">MUST NOT</span> be protected as specified above (cf.  <a href="#tokenAuthInfoEndpoint" class="xref">Section 5.10.1</a>).<a href="#section-5.2-3" class="pilcrow">¶</a></p>
<p id="section-5.2-4">Unauthorized Resource Request messages <span class="bcp14">MUST</span> be denied with an
 "unauthorized_client" error response. In this response, the resource server
 <span class="bcp14">SHOULD</span> provide proper
 AS Request Creation Hints to enable the client to request an access token
 from the RS's AS, as described in <a href="#asInfo" class="xref">Section 5.3</a>.<a href="#section-5.2-4" class="pilcrow">¶</a></p>
<p id="section-5.2-5">The handling of all client requests (including unauthorized ones)
    by the RS is described in <a href="#requestC2RS" class="xref">Section 5.10.2</a>.<a href="#section-5.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="asInfo">
<section id="section-5.3">
        <h3 id="name-as-request-creation-hints">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-as-request-creation-hints" class="section-name selfRef">AS Request Creation Hints</a>
        </h3>
<p id="section-5.3-1">The AS Request Creation Hints are sent by an RS as a response to
 an Unauthorized Resource Request message (see <a href="#rreq" class="xref">Section 5.2</a>) to help
 the sender of the Unauthorized Resource Request message acquire a valid
 access token. The AS Request Creation Hints are a CBOR or JSON map,
 with an <span class="bcp14">OPTIONAL</span> element <code>AS</code> specifying an absolute URI (see
 <span><a href="https://www.rfc-editor.org/rfc/rfc3986#section-4.3" class="relref">Section 4.3</a> of [<a href="#RFC3986" class="xref">RFC3986</a>]</span>) that identifies the
 appropriate AS for the RS.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">The message can also contain the following <span class="bcp14">OPTIONAL</span>
 parameters:<a href="#section-5.3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.3-3.1">An <code>audience</code> 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 
      <a href="#audience" class="xref">Section 6.9</a> for a discussion of this parameter.<a href="#section-5.3-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.3-3.2">A <code>kid</code> (key identifier) element contains the key identifier of a key used in
   an existing security association between the client and the RS.
   The RS expects the client to request an access token bound to this
   key in order to avoid having to reestablish the security
   association.<a href="#section-5.3-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.3-3.3">A <code>cnonce</code> element contains a client-nonce. See <a href="#cnonceParam" class="xref">Section 5.3.1</a>.<a href="#section-5.3-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.3-3.4">A <code>scope</code> element contains the suggested scope that the client
   should request towards the AS.<a href="#section-5.3-3.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.3-4"><a href="#table_asinfo" class="xref">Table 1</a> summarizes the parameters that may
 be part of the AS Request Creation Hints.<a href="#section-5.3-4" class="pilcrow">¶</a></p>
<span id="name-as-request-creation-hints-2"></span><div id="table_asinfo">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-as-request-creation-hints-2" class="selfRef">AS Request Creation Hints</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Name</th>
              <th class="text-left" rowspan="1" colspan="1">CBOR Key</th>
              <th class="text-left" rowspan="1" colspan="1">Value Type</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">AS</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">text string</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">kid</td>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">byte string</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">audience</td>
              <td class="text-left" rowspan="1" colspan="1">5</td>
              <td class="text-left" rowspan="1" colspan="1">text string</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">scope</td>
              <td class="text-left" rowspan="1" colspan="1">9</td>
              <td class="text-left" rowspan="1" colspan="1">text or byte string</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">cnonce</td>
              <td class="text-left" rowspan="1" colspan="1">39</td>
              <td class="text-left" rowspan="1" colspan="1">byte string</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-5.3-6">Note that the schema part of the AS parameter may need to be
    adapted to the security protocol that is used between the client
    and the AS. Thus, the example AS value "coap://as.example.com/token"
    might need to be transformed to "coaps://as.example.com/token".
    It is assumed that the client can determine the correct schema part on
    its own depending on the way it communicates with the AS.<a href="#section-5.3-6" class="pilcrow">¶</a></p>
<p id="section-5.3-7"><a href="#fig_as-info-payload" class="xref">Figure 2</a> shows an example for an AS
    Request Creation Hints payload using
    diagnostic notation.<a href="#section-5.3-7" class="pilcrow">¶</a></p>
<span id="name-as-request-creation-hints-p"></span><div id="fig_as-info-payload">
<figure id="figure-2">
          <div id="section-5.3-8.1">
<pre class="lang-cbor-diag sourcecode">
    4.01 Unauthorized
    Content-Format: application/ace+cbor
    Payload :
    {
     / AS / 1 : "coaps://as.example.com/token",
     / audience / 5 : "coaps://rs.example.com",
     / scope / 9 : "rTempC",
     / cnonce / 39 : h'e0a156bb3f'
    }
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-as-request-creation-hints-p" class="selfRef">AS Request Creation Hints Payload Example</a>
          </figcaption></figure>
</div>
<p id="section-5.3-9">In the example above, the response parameter <code>AS</code> points the receiver of
    this message to the URI "coaps://as.example.com/token" to request access
    tokens.  The RS sending this response uses an internal clock
    that is not synchronized with the clock of the AS.  Therefore, it
    cannot reliably verify the expiration time of access tokens it receives.
    Nevertheless, to ensure a certain level of access token freshness, the RS has
    included a <code>cnonce</code> parameter (see <a href="#cnonceParam" class="xref">Section 5.3.1</a>) in the response. (The hex sequence of the <code>cnonce</code> parameter 
    is encoded in CBOR-based notation in this example.)<a href="#section-5.3-9" class="pilcrow">¶</a></p>
<p id="section-5.3-10"><a href="#fig_as-info-cbor" class="xref">Figure 3</a> illustrates the mandatory use
 of binary encoding of the message payload shown in
 <a href="#fig_as-info-payload" class="xref">Figure 2</a>.<a href="#section-5.3-10" class="pilcrow">¶</a></p>
<span id="name-as-request-creation-hints-e"></span><div id="fig_as-info-cbor">
<figure id="figure-3">
          <div id="section-5.3-11.1">
<pre class="lang-cbor-pretty sourcecode">
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                     #
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-as-request-creation-hints-e" class="selfRef">AS Request Creation Hints Example Encoded in CBOR</a>
          </figcaption></figure>
</div>
<div id="cnonceParam">
<section id="section-5.3.1">
          <h4 id="name-the-client-nonce-parameter">
<a href="#section-5.3.1" class="section-number selfRef">5.3.1. </a><a href="#name-the-client-nonce-parameter" class="section-name selfRef">The Client-Nonce Parameter</a>
          </h4>
<p id="section-5.3.1-1">If the RS does not synchronize its clock with the AS, it could be
      tricked into accepting old access tokens that are either expired or have
      been compromised.  In order to ensure some level of token freshness
      in that case, the RS can use the <code>cnonce</code> (client-nonce) parameter.
      The processing requirements for this parameter are as follows:<a href="#section-5.3.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.3.1-2.1">An RS sending a <code>cnonce</code> parameter in an AS Request Creation
     Hints message <span class="bcp14">MUST</span> store information to validate that a given
     cnonce is fresh.  How this is implemented internally is out of scope
     for this specification.  Expiration of client-nonces should be based
     roughly on the time it would take a client to obtain an access token
     after receiving the AS Request Creation Hints, with some
     allowance for unexpected delays.<a href="#section-5.3.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.3.1-2.2">A client receiving a <code>cnonce</code> parameter in an AS Request Creation
     Hints message <span class="bcp14">MUST</span> include this in the parameters when
     requesting an access token at the AS, using the <code>cnonce</code> parameter from
     <a href="#cnonceParamToken" class="xref">Section 5.8.4.4</a>.<a href="#section-5.3.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.3.1-2.3">If an AS grants an access token request containing a <code>cnonce</code>
     parameter, it <span class="bcp14">MUST</span> include this value in the access token, using
     the <code>cnonce</code> claim specified in <a href="#accessToken" class="xref">Section 5.10</a>.<a href="#section-5.3.1-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.3.1-2.4">An RS that is using the client-nonce mechanism and that receives an
     access token <span class="bcp14">MUST</span> verify that this token contains a <code>cnonce</code>
     claim, with
     a client-nonce value that is fresh according to the information stored
     at the first step above.  If the <code>cnonce</code> claim is not present or if the
     <code>cnonce</code> claim value is not fresh, the RS <span class="bcp14">MUST</span> discard the access
     token. If this was an interaction with the authz-info endpoint, the RS
     <span class="bcp14">MUST</span> also
     respond with an error message using a response code equivalent to the
     CoAP code 4.01 (Unauthorized).<a href="#section-5.3.1-2.4" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
</section>
</div>
<div id="authorizationGrants">
<section id="section-5.4">
        <h3 id="name-authorization-grants">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-authorization-grants" class="section-name selfRef">Authorization Grants</a>
        </h3>
<p id="section-5.4-1">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.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<p id="section-5.4-2">The OAuth framework <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span> defines four grant types. The grant types can
  be split up into two groups: those granted on behalf of the resource
  owner (password, authorization code, implicit) and those for the client
  (client credentials). Further grant types have been added later, such as an assertion-based authorization grant defined in <span>[<a href="#RFC7521" class="xref">RFC7521</a>]</span>.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
<p id="section-5.4-3">The grant type is selected depending on the use case.  In cases where
  the client acts on behalf of the resource owner, the authorization code
  grant is recommended.  If the client acts on behalf of the resource owner
  but does not have any display or has very limited interaction possibilities, it is
  recommended to use the device code grant defined in
  <span>[<a href="#RFC8628" class="xref">RFC8628</a>]</span>.  In cases where the client
  acts autonomously, the client credentials grant is recommended.<a href="#section-5.4-3" class="pilcrow">¶</a></p>
<p id="section-5.4-4">For details on the different grant types, see <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-1.3" class="relref">Section 1.3</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>. The OAuth 2.0 framework provides an extension
  mechanism for defining additional grant types, so profiles of this framework
  <span class="bcp14">MAY</span> define additional grant types, if needed.<a href="#section-5.4-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="clientCredentials">
<section id="section-5.5">
        <h3 id="name-client-credentials">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-client-credentials" class="section-name selfRef">Client Credentials</a>
        </h3>
<p id="section-5.5-1">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.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
<p id="section-5.5-2">Client registration and provisioning of client credentials to the client
  is out of scope for this specification.<a href="#section-5.5-2" class="pilcrow">¶</a></p>
<p id="section-5.5-3">The OAuth framework defines one client credential type in
  <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-2.3.1" class="relref">Section 2.3.1</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span> that comprises the client_id and client_secret values. <span>[<a href="#I-D.erdtman-oauth-rpcc" class="xref">OAUTH-RPCC</a>]</span> adds raw public key and pre-shared key to the
  client credentials type.  Profiles of this framework <span class="bcp14">MAY</span> extend it with
  an additional client credentials type using client certificates.<a href="#section-5.5-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ASAuthentication">
<section id="section-5.6">
        <h3 id="name-as-authentication">
<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-as-authentication" class="section-name selfRef">AS Authentication</a>
        </h3>
<p id="section-5.6-1">The client credentials grant does not, by default, authenticate the AS that the client
  connects to. In classic OAuth, the AS is authenticated with a TLS server
  certificate.<a href="#section-5.6-1" class="pilcrow">¶</a></p>
<p id="section-5.6-2">Profiles of this framework <span class="bcp14">MUST</span> 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.<a href="#section-5.6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authorizeEndpoint">
<section id="section-5.7">
        <h3 id="name-the-authorization-endpoint">
<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-the-authorization-endpoint" class="section-name selfRef">The Authorization Endpoint</a>
        </h3>
<p id="section-5.7-1">The OAuth 2.0 authorization endpoint is used to interact with the resource owner
  and obtain an authorization grant in certain grant flows.  The primary use
  case for the ACE-OAuth framework is for machine-to-machine interactions that do not involve
  the resource owner in the authorization flow; therefore, this endpoint is
  out of scope here.  Future profiles may define constrained adaptation
  mechanisms for this endpoint as well.  Nonconstrained clients interacting
  with constrained resource servers can use the specification in
  <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-3.1" class="relref">Section 3.1</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span> and the attack countermeasures suggested in
  <span><a href="https://www.rfc-editor.org/rfc/rfc6819#section-4.2" class="relref">Section 4.2</a> of [<a href="#RFC6819" class="xref">RFC6819</a>]</span>.<a href="#section-5.7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tokenEndpoint">
<section id="section-5.8">
        <h3 id="name-the-token-endpoint">
<a href="#section-5.8" class="section-number selfRef">5.8. </a><a href="#name-the-token-endpoint" class="section-name selfRef">The Token Endpoint</a>
        </h3>
<p id="section-5.8-1">In standard OAuth 2.0, the AS provides the token endpoint for submitting
  access token requests.  This framework extends the functionality of the
  token endpoint, giving the AS the possibility to help the client and RS
  establish shared keys or exchange their public keys.  Furthermore,
  this framework defines encodings using CBOR as a substitute for JSON.<a href="#section-5.8-1" class="pilcrow">¶</a></p>
<p id="section-5.8-2">The endpoint may also be exposed over HTTPS, as in classical OAuth or
  even other transports.  A profile <span class="bcp14">MUST</span> define the details of the mapping
  between the fields described below and these transports.
  If HTTPS with JSON is used,
  the semantics of Sections <a href="https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3" class="relref">4.1.3</a> and <a href="https://www.rfc-editor.org/rfc/rfc6749#section-4.1.4" class="relref">4.1.4</a> of the OAuth 2.0 specification <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span> <span class="bcp14">MUST</span>
  be followed (with additions as described below).  If CBOR is used as the payload format, the semantics described in this
section <span class="bcp14">MUST</span> be followed.<a href="#section-5.8-2" class="pilcrow">¶</a></p>
<p id="section-5.8-3">For the AS to be able to issue a token, the client <span class="bcp14">MUST</span> be authenticated
  and present a valid grant for the scopes requested.  Profiles of this
  framework <span class="bcp14">MUST</span> specify how the AS authenticates the client and how the
  communication between the client and AS is protected, fulfilling the
  requirements specified in <a href="#oauthProfile" class="xref">Section 5</a>.<a href="#section-5.8-3" class="pilcrow">¶</a></p>
<p id="section-5.8-4">The default name of this endpoint in a url-path <span class="bcp14">SHOULD</span> be '/token'.
  However, implementations are not required to use this name and can define
  their own instead.<a href="#section-5.8-4" class="pilcrow">¶</a></p>
<div id="tokenRequest">
<section id="section-5.8.1">
          <h4 id="name-client-to-as-request">
<a href="#section-5.8.1" class="section-number selfRef">5.8.1. </a><a href="#name-client-to-as-request" class="section-name selfRef">Client-to-AS Request</a>
          </h4>
<p id="section-5.8.1-1">The client sends a POST request to the token endpoint
    at the AS. The profile <span class="bcp14">MUST</span> specify how the communication is protected.
    The content of the request consists of the parameters specified
    in the relevant subsection of Section <a href="https://www.rfc-editor.org/rfc/rfc6749#section-4" class="relref">4</a> of the OAuth 2.0 specification
    <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>, depending on the grant type, with the following
    exceptions and additions:<a href="#section-5.8.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.8.1-2.1">The <code>grant_type</code> parameter is <span class="bcp14">OPTIONAL</span> in the context
     of this framework (as opposed to <span class="bcp14">REQUIRED</span> in <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>).  If that parameter is
     missing, the default value "client_credentials" is implied.<a href="#section-5.8.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.8.1-2.2">The <code>audience</code> parameter from <span>[<a href="#RFC8693" class="xref">RFC8693</a>]</span> is <span class="bcp14">OPTIONAL</span> to
     request an access token bound to a specific audience.<a href="#section-5.8.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.8.1-2.3">The <code>cnonce</code> parameter defined in <a href="#cnonceParamToken" class="xref">Section 5.8.4.4</a> is
     <span class="bcp14">REQUIRED</span> if the RS provided a client-nonce in the AS
     Request Creation Hints message (<a href="#asInfo" class="xref">Section 5.3</a>).<a href="#section-5.8.1-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.8.1-2.4">The <code>scope</code> parameter <span class="bcp14">MAY</span> be encoded as a byte string
     instead of the string encoding specified in <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-3.3" class="relref">Section 3.3</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span> 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.<a href="#section-5.8.1-2.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.8.1-2.5">The client can send an empty (null value) <code>ace_profile</code> parameter to
     indicate that it wants the AS to include the <code>ace_profile</code> parameter in
      the response.  See <a href="#paramProfile" class="xref">Section 5.8.4.3</a>.<a href="#section-5.8.1-2.5" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.8.1-2.6">A client <span class="bcp14">MUST</span> be able to use the parameters from <span>[<a href="#RFC9201" class="xref">RFC9201</a>]</span> in an access token request to the
      token endpoint, and the AS <span class="bcp14">MUST</span> be able to process these additional
      parameters.<a href="#section-5.8.1-2.6" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-5.8.1-3">The default behavior is that the AS generates a symmetric
    proof-of-possession key for the client. In order to use an asymmetric key
    pair or to reuse a key previously established with the RS, the client is
    supposed to use the <code>req_cnf</code> parameter from <span>[<a href="#RFC9201" class="xref">RFC9201</a>]</span>.<a href="#section-5.8.1-3" class="pilcrow">¶</a></p>
<p id="section-5.8.1-4">If CoAP is used, then these parameters <span class="bcp14">MUST</span> be provided in a CBOR map
    (see <a href="#table_cborTokenParameters" class="xref">Table 5</a>).<a href="#section-5.8.1-4" class="pilcrow">¶</a></p>
<p id="section-5.8.1-5">When HTTP is used as a transport, then the client makes a 
    request to the token endpoint; the parameters <span class="bcp14">MUST</span> be encoded as defined 
    in <span><a href="https://www.rfc-editor.org/rfc/rfc6749#appendix-B" class="relref">Appendix B</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-5.8.1-5" class="pilcrow">¶</a></p>
<p id="section-5.8.1-6">The following examples illustrate different types of requests
    for proof-of-possession tokens.<a href="#section-5.8.1-6" class="pilcrow">¶</a></p>
<p id="section-5.8.1-7"><a href="#fig_symmATreq" class="xref">Figure 4</a> shows a request for a token
    with a symmetric proof-of-possession key, using diagnostic notation.<a href="#section-5.8.1-7" class="pilcrow">¶</a></p>
<span id="name-example-request-for-an-acce"></span><div id="fig_symmATreq">
<figure id="figure-4">
            <div id="section-5.8.1-8.1">
<pre class="lang-cbor-diag sourcecode">
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: application/ace+cbor
Payload:
{
  / client_id / 24 : "myclient",
  / audience /  5  : "tempSensor4711"
}
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-example-request-for-an-acce" class="selfRef">Example Request for an Access Token Bound to a Symmetric Key</a>
            </figcaption></figure>
</div>
<p id="section-5.8.1-9"><a href="#fig_asymmATreq" class="xref">Figure 5</a> shows a request for a token
   with an
   asymmetric proof-of-possession key.  Note that, in this example, OSCORE
   <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span> is used
   to provide object-security; therefore, the Content-Format is
   "application/oscore" wrapping the "application/ace+cbor" type content.
   The OSCORE option has a decoded interpretation appended in parentheses
   for the reader's convenience.  Also note that, in this example, the audience
   is implicitly known by both the client and AS. Furthermore, note that this
   example uses the <code>req_cnf</code> parameter from <span>[<a href="#RFC9201" class="xref">RFC9201</a>]</span>.<a href="#section-5.8.1-9" class="pilcrow">¶</a></p>
<span id="name-example-token-request-bound"></span><div id="fig_asymmATreq">
<figure id="figure-5">
            <div id="section-5.8.1-10.1">
<pre class="lang-cbor-diag sourcecode">
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
OSCORE: 0x09, 0x05, 0x44, 0x6C
  (h=0, k=1, n=001, partialIV= 0x05, kid=[0x44, 0x6C])
Content-Format: application/oscore
Payload:
  0x44025d1/ ... (full payload omitted for brevity) ... /68b3825e

Decrypted payload:
{
  / client_id / 24 : "myclient",
  / req_cnf / 4 : {
    / COSE_Key / 1 : {
      / kty /  1 : 2 / EC2 /,
      / kid /  2 : h'11',
      / crv / -1 : 1 / P-256 /,
      / x /   -2 : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
      / y /   -3 : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'
    }
  }
}
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-example-token-request-bound" class="selfRef">Example Token Request Bound to an Asymmetric Key</a>
            </figcaption></figure>
</div>
<p id="section-5.8.1-11"><a href="#fig_kidATreq" class="xref">Figure 6</a> shows a request for a token
    where a previously communicated proof-of-possession key is only
    referenced using the <code>req_cnf</code> parameter from
    <span>[<a href="#RFC9201" class="xref">RFC9201</a>]</span>.<a href="#section-5.8.1-11" class="pilcrow">¶</a></p>
<span id="name-example-request-for-an-acces"></span><div id="fig_kidATreq">
<figure id="figure-6">
            <div id="section-5.8.1-12.1">
<pre class="lang-cbor-diag sourcecode">
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: application/ace+cbor
Payload:
{
  / client_id / 24 : "myclient",
  / audience /   5 : "valve424",
  / scope /      9 : "read",
  / req_cnf /    4 : {
     / kid /        3 : b64'6kg0dXJM13U'
  }
}
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-example-request-for-an-acces" class="selfRef">Example Request for an Access Token Bound to a Key Reference</a>
            </figcaption></figure>
</div>
<p id="section-5.8.1-13">Refresh tokens are typically not stored as securely as
   proof-of-possession keys in requesting clients.  Proof-of-possession-based
   refresh token requests <span class="bcp14">MUST NOT</span> request different
   proof-of-possession keys
   or different audiences in token requests.  Refresh token requests can only be
   used to request access tokens bound to the same proof-of-possession key and
   the same audience as access tokens issued in the initial token request.<a href="#section-5.8.1-13" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tokenResponse">
<section id="section-5.8.2">
          <h4 id="name-as-to-client-response">
<a href="#section-5.8.2" class="section-number selfRef">5.8.2. </a><a href="#name-as-to-client-response" class="section-name selfRef">AS-to-Client Response</a>
          </h4>
<p id="section-5.8.2-1">If the access token request has been successfully verified by the
    AS and the client is authorized to obtain an access token corresponding
    to its access token request, the AS sends a response with the response
    code equivalent to the CoAP response code 2.01 (Created).  If the client
    request was invalid, or not authorized, the AS returns an error response, as
    described in <a href="#errorsToken" class="xref">Section 5.8.3</a>.<a href="#section-5.8.2-1" class="pilcrow">¶</a></p>
<p id="section-5.8.2-2">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 <a href="#app_registration" class="xref">Appendix D</a>).  This prior knowledge may,
   for example, be set
   by the use of a dynamic client registration protocol exchange
   <span>[<a href="#RFC7591" class="xref">RFC7591</a>]</span>.  If the client has requested a
   specific
   proof-of-possession key using the <code>req_cnf</code> parameter from
   <span>[<a href="#RFC9201" class="xref">RFC9201</a>]</span>, this may also influence which
   profile the AS selects, as it needs to support the use of the key type
   requested by the client.<a href="#section-5.8.2-2" class="pilcrow">¶</a></p>
<p id="section-5.8.2-3">The content of the successful reply is the Access Information. 
   When using CoAP, the payload <span class="bcp14">MUST</span> be encoded as a CBOR map;
   when using
   HTTP, the encoding is a JSON map, as specified in <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-5.1" class="relref">Section 5.1</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>.  In both cases, the parameters specified
   in <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-5.1" class="relref">Section 5.1</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span> are used, with
   the following additions and changes:<a href="#section-5.8.2-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.8.2-4">
            <dt id="section-5.8.2-4.1">ace_profile:</dt>
            <dd style="margin-left: 3.0em" id="section-5.8.2-4.2">This parameter is <span class="bcp14">OPTIONAL</span> unless the request included an
     empty <code>ace_profile</code> parameter,
     in which case it is MANDATORY.  This indicates the profile that the
     client <span class="bcp14">MUST</span> use towards the RS. See <a href="#paramProfile" class="xref">Section 5.8.4.3</a> 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.<a href="#section-5.8.2-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-5.8.2-4.3">
<code>token_type</code>:</dt>
            <dd style="margin-left: 3.0em" id="section-5.8.2-4.4">This parameter is <span class="bcp14">OPTIONAL</span>, as opposed to
     <span class="bcp14">REQUIRED</span> in
     <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>. By default, implementations of
     this framework
     <span class="bcp14">SHOULD</span> assume that the <code>token_type</code> is "PoP".  If a specific
     use case
     requires another <code>token_type</code> (e.g., "Bearer") to be used, then this
     parameter is <span class="bcp14">REQUIRED</span>.<a href="#section-5.8.2-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-5.8.2-5">Furthermore, <span>[<a href="#RFC9201" class="xref">RFC9201</a>]</span> defines
   additional parameters that the AS <span class="bcp14">MUST</span> be able to use when
   responding to a request to the token endpoint.<a href="#section-5.8.2-5" class="pilcrow">¶</a></p>
<p id="section-5.8.2-6"><a href="#table_rsinfo" class="xref">Table 2</a> summarizes the parameters that
   can currently be part of the Access Information. Future extensions
   may define additional parameters.<a href="#section-5.8.2-6" class="pilcrow">¶</a></p>
<span id="name-access-information-paramete"></span><div id="table_rsinfo">
<table class="center" id="table-2">
            <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-access-information-paramete" class="selfRef">Access Information Parameters</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Parameter name</th>
                <th class="text-left" rowspan="1" colspan="1">Specified in</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>access_token</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>token_type</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>expires_in</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>refresh_token</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>scope</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>state</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>error</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>error_description</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>error_uri</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>ace_profile</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9200</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>cnf</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC9201" class="xref">RFC9201</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>rs_cnf</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC9201" class="xref">RFC9201</a>]</span>
</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-5.8.2-8"><a href="#fig_symmATres" class="xref">Figure 7</a> shows a response containing a token
    and a <code>cnf</code> parameter with a symmetric proof-of-possession key, which
    is defined in <span>[<a href="#RFC9201" class="xref">RFC9201</a>]</span>.  Note that
    the key identifier <code>kid</code> 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.<a href="#section-5.8.2-8" class="pilcrow">¶</a></p>
<span id="name-example-as-response-with-an"></span><div id="fig_symmATres">
<figure id="figure-7">
            <div id="section-5.8.2-9.1">
<pre class="lang-cbor-diag sourcecode">
Header: Created (Code=2.01)
Content-Format: application/ace+cbor
Payload:
{
  / access_token / 1 : b64'SlAV32hk'/ ...
   (remainder of CWT omitted for brevity;
   CWT contains COSE_Key in the cnf claim)/,
  / ace_profile / 38 : "coap_dtls",
  / expires_in /   2 : 3600,
  / cnf / 8 : {
    / COSE_Key / 1 : {
      / kty / 1 : 4 / Symmetric /,
      / kid / 2 : b64'39Gqlw',
      / k /  -1 : b64'hJtXhkV8FJG+Onbc6mxC'
    }
  }
}
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-example-as-response-with-an" class="selfRef">Example AS Response with an Access Token Bound to a Symmetric Key</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="errorsToken">
<section id="section-5.8.3">
          <h4 id="name-error-response">
<a href="#section-5.8.3" class="section-number selfRef">5.8.3. </a><a href="#name-error-response" class="section-name selfRef">Error Response</a>
          </h4>
<p id="section-5.8.3-1">The error responses for interactions with the AS are generally
    equivalent to the ones defined in <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>,
    with the following exceptions:<a href="#section-5.8.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.8.3-2.1">When using CoAP, the payload <span class="bcp14">MUST</span> be encoded as a CBOR
     map, with
     the Content-Format "application/ace+cbor".  When using HTTP, the
            payload is encoded in JSON, as specified in <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-5.8.3-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.8.3-2.2">A response code equivalent to the CoAP code 4.00 (Bad Request)
     <span class="bcp14">MUST</span>
     be used for all error responses, except for invalid_client, where a
     response code equivalent to the CoAP code 4.01 (Unauthorized)
     <span class="bcp14">MAY</span> be
     used under the same conditions as specified in 
     <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-5.8.3-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.8.3-2.3">The parameters <code>error</code>, <code>error_description</code>, and <code>error_uri</code> <span class="bcp14">MUST</span>
 be abbreviated using the codes specified in <a href="#table_cborTokenParameters" class="xref">Table 5</a>, when a CBOR encoding is used.<a href="#section-5.8.3-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.8.3-2.4">The error code (i.e., value of the <code>error</code> parameter) <span class="bcp14">MUST</span> be
 abbreviated, as specified in <a href="#table_cborErrorCodes" class="xref">Table 3</a>, when a CBOR encoding is used.<a href="#section-5.8.3-2.4" class="pilcrow">¶</a>
</li>
          </ul>
<span id="name-cbor-abbreviations-for-comm"></span><div id="table_cborErrorCodes">
<table class="center" id="table-3">
            <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-cbor-abbreviations-for-comm" class="selfRef">CBOR Abbreviations for Common Error Codes</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Name</th>
                <th class="text-left" rowspan="1" colspan="1">CBOR Values</th>
                <th class="text-left" rowspan="1" colspan="1">Original Specification</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>invalid_request</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">1</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>invalid_client</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">2</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>invalid_grant</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">3</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>unauthorized_client</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">4</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>unsupported_grant_type</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">5</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>invalid_scope</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">6</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>unsupported_pop_key</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">7</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9200</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>incompatible_ace_profiles</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">8</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9200</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-5.8.3-4">In addition to the error responses defined in OAuth 2.0, the following
   behavior <span class="bcp14">MUST</span> be implemented by the AS:<a href="#section-5.8.3-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.8.3-5.1">If the client submits an asymmetric key in the token request that the
     RS cannot process, the AS <span class="bcp14">MUST</span> reject that request with a
     response code equivalent to the CoAP code 4.00 (Bad Request), including the
     error code "unsupported_pop_key" specified in
     <a href="#table_cborErrorCodes" class="xref">Table 3</a>.<a href="#section-5.8.3-5.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.8.3-5.2">If the client and the RS it has requested an access token for do
     not share a common profile, the AS <span class="bcp14">MUST</span> reject that request with
     a response code equivalent to the CoAP code 4.00 (Bad Request), including
     the error code "incompatible_ace_profiles" specified in
     <a href="#table_cborErrorCodes" class="xref">Table 3</a>.<a href="#section-5.8.3-5.2" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="tokenParams">
<section id="section-5.8.4">
          <h4 id="name-request-and-response-parame">
<a href="#section-5.8.4" class="section-number selfRef">5.8.4. </a><a href="#name-request-and-response-parame" class="section-name selfRef">Request and Response Parameters</a>
          </h4>
<p id="section-5.8.4-1">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.<a href="#section-5.8.4-1" class="pilcrow">¶</a></p>
<div id="paramGrantType">
<section id="section-5.8.4.1">
            <h5 id="name-grant-type">
<a href="#section-5.8.4.1" class="section-number selfRef">5.8.4.1. </a><a href="#name-grant-type" class="section-name selfRef">Grant Type</a>
            </h5>
<p id="section-5.8.4.1-1">The abbreviations specified in the registry defined in
      <a href="#IANAGrantTypeMappings" class="xref">Section 8.5</a> <span class="bcp14">MUST</span> be
      used in CBOR encodings instead of the string values defined
      in <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span> if CBOR payloads are used.<a href="#section-5.8.4.1-1" class="pilcrow">¶</a></p>
<span id="name-cbor-abbreviations-for-commo"></span><div id="table_grant_types">
<table class="center" id="table-4">
              <caption>
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-cbor-abbreviations-for-commo" class="selfRef">CBOR Abbreviations for Common Grant Types</a>
              </caption>
<thead>
                <tr>
                  <th class="text-left" rowspan="1" colspan="1">Name</th>
                  <th class="text-left" rowspan="1" colspan="1">CBOR Value</th>
                  <th class="text-left" rowspan="1" colspan="1">Original Specification</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">
                    <code>password</code>
</td>
                  <td class="text-left" rowspan="1" colspan="1">0</td>
                  <td class="text-left" rowspan="1" colspan="1">
                    <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-4.3.2" class="relref">Section 4.3.2</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">
                    <code>authorization_code</code>
</td>
                  <td class="text-left" rowspan="1" colspan="1">1</td>
                  <td class="text-left" rowspan="1" colspan="1">
                    <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3" class="relref">Section 4.1.3</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">
                    <code>client_credentials</code>
</td>
                  <td class="text-left" rowspan="1" colspan="1">2</td>
                  <td class="text-left" rowspan="1" colspan="1">
                    <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-4.4.2" class="relref">Section 4.4.2</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
                </tr>
                <tr>
                  <td class="text-left" rowspan="1" colspan="1">
                    <code>refresh_token</code>
</td>
                  <td class="text-left" rowspan="1" colspan="1">3</td>
                  <td class="text-left" rowspan="1" colspan="1">
                    <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-6" class="relref">Section 6</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
                </tr>
              </tbody>
            </table>
</div>
</section>
</div>
<div id="paramTokenType">
<section id="section-5.8.4.2">
            <h5 id="name-token-type">
<a href="#section-5.8.4.2" class="section-number selfRef">5.8.4.2. </a><a href="#name-token-type" class="section-name selfRef">Token Type</a>
            </h5>
<p id="section-5.8.4.2-1">The <code>token_type</code> parameter, defined in <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-5.1" class="relref">Section 5.1</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>, allows the AS to indicate to the
     client which type of
     access token it is receiving (e.g., a bearer token).<a href="#section-5.8.4.2-1" class="pilcrow">¶</a></p>
<p id="section-5.8.4.2-2">This document registers the new value "PoP" for the "OAuth Access
            Token Types" registry,  specifying a proof-of-possession token.  How the
     proof of possession by the client to the RS is performed
     <span class="bcp14">MUST</span> be specified by the profiles.<a href="#section-5.8.4.2-2" class="pilcrow">¶</a></p>
<p id="section-5.8.4.2-3">The values in the <code>token_type</code> parameter <span class="bcp14">MUST</span> use the
     CBOR abbreviations defined in the registry specified by
     <a href="#IANATokenTypeMappings" class="xref">Section 8.7</a> if a CBOR
     encoding is used.<a href="#section-5.8.4.2-3" class="pilcrow">¶</a></p>
<p id="section-5.8.4.2-4">In this framework, the "pop" value for the <code>token_type</code> parameter is
     the default. The AS may, however, provide a different value from those
     registered in <span>[<a href="#IANA.OAuthAccessTokenTypes" class="xref">IANA.OAuthAccessTokenTypes</a>]</span>.<a href="#section-5.8.4.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="paramProfile">
<section id="section-5.8.4.3">
            <h5 id="name-profile">
<a href="#section-5.8.4.3" class="section-number selfRef">5.8.4.3. </a><a href="#name-profile" class="section-name selfRef">Profile</a>
            </h5>
<p id="section-5.8.4.3-1">Profiles of this framework <span class="bcp14">MUST</span> define the communication
     protocol and the communication security protocol between the client
     and the RS.  The security protocol <span class="bcp14">MUST</span> provide encryption,
     integrity, and
     replay protection. It <span class="bcp14">MUST</span> also provide a binding between
     requests and
     responses.  Furthermore, profiles <span class="bcp14">MUST</span> define a list of
     allowed proof-of-possession methods if they support proof-of-possession
     tokens.<a href="#section-5.8.4.3-1" class="pilcrow">¶</a></p>
<p id="section-5.8.4.3-2">A profile <span class="bcp14">MUST</span> specify an identifier that <span class="bcp14">MUST</span> be used to uniquely
      identify itself in the <code>ace_profile</code> parameter. The textual
      representation of the profile identifier is intended for human
      readability and for JSON-based interactions; it <span class="bcp14">MUST NOT</span> be used for
      CBOR-based interactions.  Profiles <span class="bcp14">MUST</span> register their identifier in the
      registry defined in <a href="#IANAProfile" class="xref">Section 8.8</a>.<a href="#section-5.8.4.3-2" class="pilcrow">¶</a></p>
<p id="section-5.8.4.3-3">Profiles <span class="bcp14">MAY</span> define additional parameters for both the token request
      and the Access Information in the access token response in order to
      support negotiation or signaling of profile-specific parameters.<a href="#section-5.8.4.3-3" class="pilcrow">¶</a></p>
<p id="section-5.8.4.3-4">Clients that want the AS to provide them with the <code>ace_profile</code>
     parameter in the access token response can indicate that by sending an
     <code>ace_profile</code> parameter with a null value for CBOR-based interactions, 
     or an empty string if CBOR is not used, in the access token
     request.<a href="#section-5.8.4.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cnonceParamToken">
<section id="section-5.8.4.4">
            <h5 id="name-client-nonce">
<a href="#section-5.8.4.4" class="section-number selfRef">5.8.4.4. </a><a href="#name-client-nonce" class="section-name selfRef">Client-Nonce</a>
            </h5>
<p id="section-5.8.4.4-1">This parameter <span class="bcp14">MUST</span> be sent from the client to the AS
     if it previously received a <code>cnonce</code> parameter in the AS Request
     Creation Hints (<a href="#asInfo" class="xref">Section 5.3</a>).  The parameter
     is encoded as a byte string for CBOR-based interactions and as a
     string (base64url without padding encoded binary <span>[<a href="#RFC4648" class="xref">RFC4648</a>]</span>) if CBOR is not used.
     It <span class="bcp14">MUST</span> copy the value from the <code>cnonce</code> parameter in the AS
     Request Creation Hints.<a href="#section-5.8.4.4-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="tokenCborParams">
<section id="section-5.8.5">
          <h4 id="name-mapping-parameters-to-cbor">
<a href="#section-5.8.5" class="section-number selfRef">5.8.5. </a><a href="#name-mapping-parameters-to-cbor" class="section-name selfRef">Mapping Parameters to CBOR</a>
          </h4>
<p id="section-5.8.5-1">If CBOR encoding is used, all OAuth parameters in access token requests
    and responses <span class="bcp14">MUST</span> be mapped to CBOR types, as specified in the registry
    defined by <a href="#IANAOAuthParameterMappingsRegistry" class="xref">Section 8.10</a>, using the
    given integer abbreviation for the map keys.<a href="#section-5.8.5-1" class="pilcrow">¶</a></p>
<p id="section-5.8.5-2">Note that we have aligned the abbreviations corresponding to claims
    with the abbreviations defined in <span>[<a href="#RFC8392" class="xref">RFC8392</a>]</span>.<a href="#section-5.8.5-2" class="pilcrow">¶</a></p>
<p id="section-5.8.5-3">Note also that abbreviations from -24 to 23 have a 1-byte encoding
    size in CBOR. We have thus chosen to assign abbreviations in that
    range to parameters we expect to be used most frequently in constrained
    scenarios.<a href="#section-5.8.5-3" class="pilcrow">¶</a></p>
<span id="name-cbor-mappings-used-in-token"></span><div id="table_cborTokenParameters">
<table class="center" id="table-5">
            <caption>
<a href="#table-5" class="selfRef">Table 5</a>:
<a href="#name-cbor-mappings-used-in-token" class="selfRef">CBOR Mappings Used in Token Requests and Responses</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Name</th>
                <th class="text-left" rowspan="1" colspan="1">CBOR Key</th>
                <th class="text-left" rowspan="1" colspan="1">Value Type</th>
                <th class="text-left" rowspan="1" colspan="1">Original Specification</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>access_token</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">1</td>
                <td class="text-left" rowspan="1" colspan="1">byte string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>expires_in</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">2</td>
                <td class="text-left" rowspan="1" colspan="1">unsigned integer</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>audience</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">5</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC8693" class="xref">RFC8693</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>scope</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">9</td>
                <td class="text-left" rowspan="1" colspan="1">text or byte string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>client_id</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">24</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>client_secret</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">25</td>
                <td class="text-left" rowspan="1" colspan="1">byte string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>response_type</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">26</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>redirect_uri</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">27</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>state</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">28</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>code</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">29</td>
                <td class="text-left" rowspan="1" colspan="1">byte string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>error</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">30</td>
                <td class="text-left" rowspan="1" colspan="1">integer</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>error_description</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">31</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>error_uri</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">32</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>grant_type</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">33</td>
                <td class="text-left" rowspan="1" colspan="1">unsigned integer</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>token_type</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">34</td>
                <td class="text-left" rowspan="1" colspan="1">integer</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>username</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">35</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>password</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">36</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>refresh_token</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">37</td>
                <td class="text-left" rowspan="1" colspan="1">byte string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>ace_profile</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">38</td>
                <td class="text-left" rowspan="1" colspan="1">integer</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9200</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>cnonce</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">39</td>
                <td class="text-left" rowspan="1" colspan="1">byte string</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9200</td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</div>
</section>
</div>
<div id="introspectionEndpoint">
<section id="section-5.9">
        <h3 id="name-the-introspection-endpoint">
<a href="#section-5.9" class="section-number selfRef">5.9. </a><a href="#name-the-introspection-endpoint" class="section-name selfRef">The Introspection Endpoint</a>
        </h3>
<p id="section-5.9-1">Token introspection <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span> <span class="bcp14">MAY</span>
 be implemented by the AS and the RS. When implemented, it <span class="bcp14">MAY</span> 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 <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span> for HTTP and JSON,
 this section defines adaptations to more constrained  environments using CBOR and
 leaving the choice of the application protocol to the profile.  The client <span class="bcp14">MAY</span> also implement and use introspection analogously to the RS to obtain information about a given token.<a href="#section-5.9-1" class="pilcrow">¶</a></p>
<p id="section-5.9-2">Communication between the requesting entity and the introspection endpoint
  at the AS <span class="bcp14">MUST</span> be integrity protected and encrypted.  The communication
  security protocol <span class="bcp14">MUST</span> also provide a binding between requests and
  responses.  Furthermore, the two interacting parties <span class="bcp14">MUST</span> perform mutual
  authentication.  Finally, the AS <span class="bcp14">SHOULD</span> verify that the requesting entity has
  the right to access introspection information about the provided token.
  Profiles of this framework that support introspection <span class="bcp14">MUST</span> specify how
  authentication and communication security between the requesting
  entity and the AS is implemented.<a href="#section-5.9-2" class="pilcrow">¶</a></p>
<p id="section-5.9-3"> The default name of this endpoint in a url-path <span class="bcp14">SHOULD</span> be '/introspect'.
  However, implementations are not required to use this name and can define
  their own instead.<a href="#section-5.9-3" class="pilcrow">¶</a></p>
<div id="introReq">
<section id="section-5.9.1">
          <h4 id="name-introspection-request">
<a href="#section-5.9.1" class="section-number selfRef">5.9.1. </a><a href="#name-introspection-request" class="section-name selfRef">Introspection Request</a>
          </h4>
<p id="section-5.9.1-1">The requesting entity sends a POST request to the introspection endpoint
    at the AS.  The profile <span class="bcp14">MUST</span> specify how the communication is protected.
    If CoAP is used, the payload <span class="bcp14">MUST</span> be encoded as a CBOR map with a <code>token</code>
    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 <span class="bcp14">MAY</span> be included.<a href="#section-5.9.1-1" class="pilcrow">¶</a></p>
<p id="section-5.9.1-2">For CoAP-based interaction, all messages <span class="bcp14">MUST</span> use the content
   type "application/ace+cbor". For HTTP, the encoding defined in 
   <span><a href="https://www.rfc-editor.org/rfc/rfc7662#section-2.1" class="relref">Section 2.1</a> of [<a href="#RFC7662" class="xref">RFC7662</a>]</span> is used.<a href="#section-5.9.1-2" class="pilcrow">¶</a></p>
<p id="section-5.9.1-3">The same parameters are required and optional as in 
   <span><a href="https://www.rfc-editor.org/rfc/rfc7662#section-2.1" class="relref">Section 2.1</a> of [<a href="#RFC7662" class="xref">RFC7662</a>]</span>.<a href="#section-5.9.1-3" class="pilcrow">¶</a></p>
<p id="section-5.9.1-4">For example, <a href="#fig_introReq" class="xref">Figure 8</a> 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
   <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span> is assumed in this example;
   therefore, the Content-Format is "application/oscore". <a href="#fig_introReq-payl" class="xref">Figure 9</a> shows the decoded payload.<a href="#section-5.9.1-4" class="pilcrow">¶</a></p>
<span id="name-example-introspection-reque"></span><div id="fig_introReq">
<figure id="figure-8">
            <div id="section-5.9.1-5.1">
<pre class="sourcecode">
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "introspect"
OSCORE: 0x09, 0x05, 0x25
Content-Format: application/oscore
Payload:
... COSE content ...
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-example-introspection-reque" class="selfRef">Example Introspection Request</a>
            </figcaption></figure>
</div>
<span id="name-decoded-payload"></span><div id="fig_introReq-payl">
<figure id="figure-9">
            <div id="section-5.9.1-6.1">
<pre class="lang-cbor-diag sourcecode">
{
  / token / 11  : b64'7gj0dXJQ43U',
  / token_type_hint / 33 : 2 / PoP /
}
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-decoded-payload" class="selfRef">Decoded Payload</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="introRes">
<section id="section-5.9.2">
          <h4 id="name-introspection-response">
<a href="#section-5.9.2" class="section-number selfRef">5.9.2. </a><a href="#name-introspection-response" class="section-name selfRef">Introspection Response</a>
          </h4>
<p id="section-5.9.2-1">If the introspection request is authorized and successfully processed,
   the AS sends a response with the response code equivalent to the CoAP code
   2.01 (Created).  If the introspection request was invalid, not authorized,
   or couldn't be processed, the AS returns an error response, as described in
   <a href="#errorsIntro" class="xref">Section 5.9.3</a>.<a href="#section-5.9.2-1" class="pilcrow">¶</a></p>
<p id="section-5.9.2-2">In a successful response, the AS encodes the response parameters in
   a map.  If CoAP is used, this <span class="bcp14">MUST</span> be encoded as a CBOR map; if
   HTTP is used, the JSON encoding specified in <span><a href="https://www.rfc-editor.org/rfc/rfc7662#section-2.2" class="relref">Section 2.2</a> of [<a href="#RFC7662" class="xref">RFC7662</a>]</span>
   is used.  The map containing the response payload  includes the same
   required and optional parameters as in
   <span><a href="https://www.rfc-editor.org/rfc/rfc7662#section-2.2" class="relref">Section 2.2</a> of [<a href="#RFC7662" class="xref">RFC7662</a>]</span>, with the following
   additions:<a href="#section-5.9.2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.9.2-3">
            <dt id="section-5.9.2-3.1"><code>ace_profile</code></dt>
            <dd style="margin-left: 1.5em" id="section-5.9.2-3.2">This parameter is <span class="bcp14">OPTIONAL</span>.  This indicates the profile that
     the RS <span class="bcp14">MUST</span> use with the
     client.  See <a href="#paramProfile" class="xref">Section 5.8.4.3</a> 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.<a href="#section-5.9.2-3.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-5.9.2-3.3"><code>cnonce</code></dt>
            <dd style="margin-left: 1.5em" id="section-5.9.2-3.4">This parameter is <span class="bcp14">OPTIONAL</span>.  This is a
     client-nonce provided to the AS by the client.
     The RS <span class="bcp14">MUST</span> verify that this corresponds to the
     client-nonce
     previously provided to the client in the AS Request Creation
     Hints. See Sections <a href="#asInfo" class="xref">5.3</a> and
     <a href="#cnonceParamToken" class="xref">5.8.4.4</a>. 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 <span>[<a href="#RFC4648" class="xref">RFC4648</a>]</span>.<a href="#section-5.9.2-3.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-5.9.2-3.5"><code>cti</code></dt>
            <dd style="margin-left: 1.5em" id="section-5.9.2-3.6">This parameter is <span class="bcp14">OPTIONAL</span>.  This is the <code>cti</code> claim 
 associated to this access token.
     This parameter has the same meaning and processing rules as the
     <code>jti</code> parameter defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7662#section-3.1.2" class="relref">Section 3.1.2</a> of [<a href="#RFC7662" class="xref">RFC7662</a>]</span> 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 <span>[<a href="#RFC4648" class="xref">RFC4648</a>]</span>.<a href="#section-5.9.2-3.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-5.9.2-3.7"><code>exi</code></dt>
            <dd style="margin-left: 1.5em" id="section-5.9.2-3.8">This parameter is <span class="bcp14">OPTIONAL</span>. This is the
     <code>expires_in</code> claim associated to this access token.
     See <a href="#tokenExpiration" class="xref">Section 5.10.3</a>.<a href="#section-5.9.2-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-5.9.2-4">Furthermore, <span>[<a href="#RFC9201" class="xref">RFC9201</a>]</span> defines
    more parameters that the AS <span class="bcp14">MUST</span> be able to use when responding to a
    request to the introspection endpoint.<a href="#section-5.9.2-4" class="pilcrow">¶</a></p>
<p id="section-5.9.2-5">For example, <a href="#fig_introRes" class="xref">Figure 10</a> shows an AS
    response to the introspection request in <a href="#fig_introReq" class="xref">Figure 8</a>.
    Note that this example contains the <code>cnf</code> parameter defined in
    <span>[<a href="#RFC9201" class="xref">RFC9201</a>]</span>.<a href="#section-5.9.2-5" class="pilcrow">¶</a></p>
<span id="name-example-introspection-respo"></span><div id="fig_introRes">
<figure id="figure-10">
            <div id="section-5.9.2-6.1">
<pre class="lang-cbor-diag sourcecode">
Header: Created (Code=2.01)
Content-Format: application/ace+cbor
Payload:
{
  / active /      10 : true,
  / scope /        9 : "read",
  / ace_profile / 38 : 1 / coap_dtls /,
  / cnf /          8 : {
    / COSE_Key / 1 : {
      / kty / 1 : 4 / Symmetric /,
      / kid / 2 : b64'39Gqlw',
      / k /  -1 : b64'hJtXhkV8FJG+Onbc6mxC'
    }
  }
}
</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-example-introspection-respo" class="selfRef">Example Introspection Response</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="errorsIntro">
<section id="section-5.9.3">
          <h4 id="name-error-response-2">
<a href="#section-5.9.3" class="section-number selfRef">5.9.3. </a><a href="#name-error-response-2" class="section-name selfRef">Error Response</a>
          </h4>
<p id="section-5.9.3-1">The error responses for CoAP-based interactions with the AS
   are equivalent to the ones for HTTP-based interactions, as defined in
   <span><a href="https://www.rfc-editor.org/rfc/rfc7662#section-2.3" class="relref">Section 2.3</a> of [<a href="#RFC7662" class="xref">RFC7662</a>]</span>, with the
   following differences:<a href="#section-5.9.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.9.3-2.1">If content is sent and CoAP is used, the payload <span class="bcp14">MUST</span> be
     encoded as a
     CBOR map and the Content-Format "application/ace+cbor" <span class="bcp14">MUST</span>
     be used.
     For HTTP, the encoding defined in <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-2.3" class="relref">Section 2.3</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span> is used.<a href="#section-5.9.3-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.9.3-2.2">If the credentials used by the requesting entity (usually the RS)
     are invalid, the AS <span class="bcp14">MUST</span> respond with the response code
     equivalent to the
     CoAP code 4.01 (Unauthorized) and use the required and optional
     parameters from <span><a href="https://www.rfc-editor.org/rfc/rfc7662#section-2.3" class="relref">Section 2.3</a> of [<a href="#RFC7662" class="xref">RFC7662</a>]</span>.<a href="#section-5.9.3-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.9.3-2.3">If the requesting entity does not have the right to perform this
      introspection request, the AS <span class="bcp14">MUST</span> respond with a response code
      equivalent to the CoAP code 4.03 (Forbidden).  In this case, no payload is
      returned.<a href="#section-5.9.3-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.9.3-2.4">The parameters <code>error</code>, <code>error_description</code>, and <code>error_uri</code> <span class="bcp14">MUST</span>
      be abbreviated using the codes specified in <a href="#table_cborTokenParameters" class="xref">Table 5</a>.<a href="#section-5.9.3-2.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.9.3-2.5">The error codes <span class="bcp14">MUST</span> be abbreviated using the codes specified in
      the registry defined by <a href="#IANAErrorCBORMappings" class="xref">Section 8.4</a>.<a href="#section-5.9.3-2.5" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-5.9.3-3">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 <span class="bcp14">MUST</span> instead
    respond with an introspection response with the <code>active</code> field set to
    "false".<a href="#section-5.9.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="introParamsCbor">
<section id="section-5.9.4">
          <h4 id="name-mapping-introspection-param">
<a href="#section-5.9.4" class="section-number selfRef">5.9.4. </a><a href="#name-mapping-introspection-param" class="section-name selfRef">Mapping Introspection Parameters to CBOR</a>
          </h4>
<p id="section-5.9.4-1">If CBOR is used, the introspection request and response parameters <span class="bcp14">MUST</span>
    be mapped to CBOR types, as specified in the registry defined by <a href="#IANAIntrospectionEndpointCBORMappingsRegistry" class="xref">Section 8.12</a>, using the given
    integer abbreviation for the map key.<a href="#section-5.9.4-1" class="pilcrow">¶</a></p>
<p id="section-5.9.4-2">Note that we have aligned abbreviations that correspond to a
    claim with the abbreviations defined in <span>[<a href="#RFC8392" class="xref">RFC8392</a>]</span>
    and the abbreviations of parameters with the same name from
    <a href="#tokenCborParams" class="xref">Section 5.8.5</a>.<a href="#section-5.9.4-2" class="pilcrow">¶</a></p>
<span id="name-cbor-mappings-for-token-int"></span><div id="table_cborIntrospectionParameters">
<table class="center" id="table-6">
            <caption>
<a href="#table-6" class="selfRef">Table 6</a>:
<a href="#name-cbor-mappings-for-token-int" class="selfRef">CBOR Mappings for Token Introspection Parameters</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Parameter name</th>
                <th class="text-left" rowspan="1" colspan="1">CBOR Key</th>
                <th class="text-left" rowspan="1" colspan="1">Value Type</th>
                <th class="text-left" rowspan="1" colspan="1">Original Specification</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>iss</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">1</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>sub</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">2</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>aud</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">3</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>exp</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">4</td>
                <td class="text-left" rowspan="1" colspan="1">integer or floating-point number</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>nbf</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">5</td>
                <td class="text-left" rowspan="1" colspan="1">integer or floating-point number</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>iat</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">6</td>
                <td class="text-left" rowspan="1" colspan="1">integer or floating-point number</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>cti</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">7</td>
                <td class="text-left" rowspan="1" colspan="1">byte string</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9200</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>scope</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">9</td>
                <td class="text-left" rowspan="1" colspan="1">text or byte string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>active</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">10</td>
                <td class="text-left" rowspan="1" colspan="1">True or False</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>token</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">11</td>
                <td class="text-left" rowspan="1" colspan="1">byte string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>client_id</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">24</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>error</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">30</td>
                <td class="text-left" rowspan="1" colspan="1">integer</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>error_description</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">31</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>error_uri</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">32</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>token_type_hint</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">33</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>token_type</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">34</td>
                <td class="text-left" rowspan="1" colspan="1">integer</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>username</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">35</td>
                <td class="text-left" rowspan="1" colspan="1">text string</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>ace_profile</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">38</td>
                <td class="text-left" rowspan="1" colspan="1">integer</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9200</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>cnonce</code>
</td>
                <td class="text-left" rowspan="1" colspan="1">39</td>
                <td class="text-left" rowspan="1" colspan="1">byte string</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9200</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">exi</td>
                <td class="text-left" rowspan="1" colspan="1">40</td>
                <td class="text-left" rowspan="1" colspan="1">unsigned integer</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9200</td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</div>
</section>
</div>
<div id="accessToken">
<section id="section-5.10">
        <h3 id="name-the-access-token">
<a href="#section-5.10" class="section-number selfRef">5.10. </a><a href="#name-the-access-token" class="section-name selfRef">The Access Token</a>
        </h3>
<p id="section-5.10-1">In this framework, the use of CBOR Web Token (CWT) as
    specified in <span>[<a href="#RFC8392" class="xref">RFC8392</a>]</span> is <span class="bcp14">RECOMMENDED</span>.<a href="#section-5.10-1" class="pilcrow">¶</a></p>
<p id="section-5.10-2">In order to facilitate offline processing of access tokens,
  this document uses the <code>cnf</code> claim from <span>[<a href="#RFC8747" class="xref">RFC8747</a>]</span>
  and the <code>scope</code> claim from <span>[<a href="#RFC8693" class="xref">RFC8693</a>]</span> for
  JWT- and CWT-encoded tokens.  In addition to string encoding specified for
  the <code>scope</code> claim, a binary encoding <span class="bcp14">MAY</span> 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.<a href="#section-5.10-2" class="pilcrow">¶</a></p>
<p id="section-5.10-3">If the AS needs to convey a hint to the RS about which profile it
  should use to communicate with the client, the AS <span class="bcp14">MAY</span> include an
  <code>ace_profile</code> claim in the access token, with the same syntax and semantics
  as defined in <a href="#paramProfile" class="xref">Section 5.8.4.3</a>.<a href="#section-5.10-3" class="pilcrow">¶</a></p>
<p id="section-5.10-4">If the client submitted a <code>cnonce</code> parameter in the access token
 request (<a href="#cnonceParamToken" class="xref">Section 5.8.4.4</a>), the AS
 <span class="bcp14">MUST</span> include the value of
 this parameter in the <code>cnonce</code> claim specified here.  The <code>cnonce</code> claim
 uses binary encoding.<a href="#section-5.10-4" class="pilcrow">¶</a></p>
<div id="tokenAuthInfoEndpoint">
<section id="section-5.10.1">
          <h4 id="name-the-authorization-informati">
<a href="#section-5.10.1" class="section-number selfRef">5.10.1. </a><a href="#name-the-authorization-informati" class="section-name selfRef">The Authorization Information Endpoint</a>
          </h4>
<p id="section-5.10.1-1">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.<a href="#section-5.10.1-1" class="pilcrow">¶</a></p>
<p id="section-5.10.1-2">This section defines a method for transporting the access token to the RS
  using a RESTful protocol, such as CoAP. Profiles of this framework <span class="bcp14">MAY</span> define
  other methods for token transport.<a href="#section-5.10.1-2" class="pilcrow">¶</a></p>
<p id="section-5.10.1-3">The method consists of an authz-info endpoint, implemented by the
  RS.  A client using this method <span class="bcp14">MUST</span> 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 <span class="bcp14">MUST</span> reflect the format of the token,
  e.g., "application/cwt", for CBOR Web Tokens; if no Content-Format or media
  type is defined for the token format, "application/octet-stream" <span class="bcp14">MUST</span> be
  used.<a href="#section-5.10.1-3" class="pilcrow">¶</a></p>
<p id="section-5.10.1-4">The RS receiving the token <span class="bcp14">MUST</span> verify the validity of the
   token.  If the
   token is valid, the RS <span class="bcp14">MUST</span> respond to the POST request with a
   response code equivalent to CoAP code 2.01 (Created).
  <a href="#verifyToken" class="xref">Section 5.10.1.1</a> outlines how an RS <span class="bcp14">MUST</span> proceed to verify the
  validity of an access token.<a href="#section-5.10.1-4" class="pilcrow">¶</a></p>
<p id="section-5.10.1-5">The RS <span class="bcp14">MUST</span> be prepared to store at least one access token for future
  use. This is a difference as to how access tokens are handled in OAuth 2.0,
  where the access token is typically sent along with each request and
  therefore not stored at the RS.<a href="#section-5.10.1-5" class="pilcrow">¶</a></p>
<p id="section-5.10.1-6">When using this framework, it is <span class="bcp14">RECOMMENDED</span> that an RS stores
   only one token per proof-of-possession key.  This means that an additional token
   linked to the same key will supersede any existing token at the RS by replacing
   the corresponding authorization information.  The reason is that
   this greatly simplifies (constrained) implementations, with respect to
   required storage and resolving a request to the applicable token.  The use of
   multiple access tokens for a single client increases the strain on the
   resource server, as it must consider every access token and calculate the
   actual permissions of the client.  Also, tokens may contradict each other,
   which may lead the server to enforce wrong permissions.  If one of the access
   tokens expires earlier than others, the resulting permissions may offer
   insufficient protection.<a href="#section-5.10.1-6" class="pilcrow">¶</a></p>
<p id="section-5.10.1-7">If the payload sent to the authz-info endpoint does not parse
  to a token, the RS <span class="bcp14">MUST</span> respond with a response code equivalent to the CoAP
  code 4.00 (Bad Request).<a href="#section-5.10.1-7" class="pilcrow">¶</a></p>
<p id="section-5.10.1-8">The RS <span class="bcp14">MAY</span> make an introspection request to validate the token before
  responding to the POST request to the authz-info endpoint, e.g., if the
  token is an opaque reference.  Some transport protocols may provide a way to
  indicate that the RS is busy and the client should retry after an interval;
  this type of status update would be appropriate while the RS is waiting for
  an introspection response.<a href="#section-5.10.1-8" class="pilcrow">¶</a></p>
<p id="section-5.10.1-9">Profiles <span class="bcp14">MUST</span> specify whether the authz-info endpoint is protected,
  including whether error responses from this endpoint are protected.  Note that
  since the token contains information that allows the client and the RS to
  establish a security context in the first place, mutual authentication may
  not be possible at this point.<a href="#section-5.10.1-9" class="pilcrow">¶</a></p>
<p id="section-5.10.1-10">The default name of this endpoint in a url-path is '/authz-info';
   however, implementations are not required to use this name and can define
   their own instead.<a href="#section-5.10.1-10" class="pilcrow">¶</a></p>
<div id="verifyToken">
<section id="section-5.10.1.1">
            <h5 id="name-verifying-an-access-token">
<a href="#section-5.10.1.1" class="section-number selfRef">5.10.1.1. </a><a href="#name-verifying-an-access-token" class="section-name selfRef">Verifying an Access Token</a>
            </h5>
<p id="section-5.10.1.1-1">When an RS receives an access token, it <span class="bcp14">MUST</span> verify it before storing
    it. The details of token verification depends on various aspects, including 
    the token encoding, the type of token, the security protection applied to
    the token, and the claims.  The token encoding matters since the security
    protection differs between the token encodings. For example, a CWT token
    uses COSE, while a JWT token uses JSON Object Signing and Encryption (JOSE).  
    The type of token also has an
    influence on the verification procedure since tokens may be self-contained,
    whereby token verification may happen locally at the RS, while a 
    reference token requires further interaction with the authorization
    server, for example, using token introspection, to obtain the claims
    associated with the token reference.  Self-contained tokens <span class="bcp14">MUST</span> at 
    least be integrity protected, but they <span class="bcp14">MAY</span> also be encrypted.<a href="#section-5.10.1.1-1" class="pilcrow">¶</a></p>
<p id="section-5.10.1.1-2">For self-contained tokens, the RS <span class="bcp14">MUST</span> process the security
     protection of the token first, as specified by the respective token format.
     For CWT, the description can be found in <span>[<a href="#RFC8392" class="xref">RFC8392</a>]</span>; for
     JWT, the relevant specification is <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span>. 
     This <span class="bcp14">MUST</span>
     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.<a href="#section-5.10.1.1-2" class="pilcrow">¶</a></p>
<p id="section-5.10.1.1-3">In case the token is communicated by reference, the RS needs to obtain
    the claims first. When the RS uses token introspection, the relevant
    specification is <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span> with CoAP transport specified in
    <a href="#introspectionEndpoint" class="xref">Section 5.9</a>.<a href="#section-5.10.1.1-3" class="pilcrow">¶</a></p>
<p id="section-5.10.1.1-4">Errors may happen during this initial processing stage:<a href="#section-5.10.1.1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.10.1.1-5.1">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 <span class="bcp14">MUST</span> 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).<a href="#section-5.10.1.1-5.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-5.10.1.1-5.2">If the claims cannot be obtained, the RS <span class="bcp14">MUST</span> 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).<a href="#section-5.10.1.1-5.2" class="pilcrow">¶</a>
</li>
            </ul>
<p id="section-5.10.1.1-6">Next, the RS <span class="bcp14">MUST</span> verify claims, if present, contained in the
     access
     token. Errors are returned when claim checks fail, in the order of
     priority of this list:<a href="#section-5.10.1.1-6" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.10.1.1-7">
              <dt id="section-5.10.1.1-7.1"><code>iss</code></dt>
              <dd style="margin-left: 1.5em" id="section-5.10.1.1-7.2">The <code>iss</code> claim (if present) must identify the AS that
       has produced the security protection for the access token.  If that is
       not the case, the RS <span class="bcp14">MUST</span> discard the token.  If this was an
       interaction with authz-info, the RS <span class="bcp14">MUST</span> also respond with a
       response code equivalent
       to the CoAP code 4.01 (Unauthorized).<a href="#section-5.10.1.1-7.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.10.1.1-7.3"><code>exp</code></dt>
              <dd style="margin-left: 1.5em" id="section-5.10.1.1-7.4">The expiration date must be in the future.  
       If that is not the case, the RS <span class="bcp14">MUST</span> discard the token.  If
       this was an
       interaction with authz-info, the RS <span class="bcp14">MUST</span> 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.<a href="#section-5.10.1.1-7.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.10.1.1-7.5"><code>aud</code></dt>
              <dd style="margin-left: 1.5em" id="section-5.10.1.1-7.6">The <code>aud</code> claim must refer to an audience that
       the RS identifies with. If that is not the case, the RS <span class="bcp14">MUST</span>
       discard the
       token.  If this was an interaction with authz-info, the RS
       <span class="bcp14">MUST</span> also
       respond with a response code equivalent to the CoAP code 4.03
       (Forbidden).<a href="#section-5.10.1.1-7.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.10.1.1-7.7"><code>scope</code></dt>
              <dd style="margin-left: 1.5em" id="section-5.10.1.1-7.8">The RS must recognize value of the <code>scope</code> claim.
       If that is not the case, the RS <span class="bcp14">MUST</span> discard the token.  If
       this was an
       interaction with authz-info, the RS <span class="bcp14">MUST</span> also respond with a
       response code
       equivalent to the CoAP code 4.00 (Bad Request).  The RS <span class="bcp14">MAY</span>
       provide
       additional information in the error response to clarify what
       went wrong.<a href="#section-5.10.1.1-7.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
<p id="section-5.10.1.1-8">Additional processing may be needed for other claims in a way
    specific to a profile or the underlying application.<a href="#section-5.10.1.1-8" class="pilcrow">¶</a></p>
<p id="section-5.10.1.1-9">Note that the <code>sub</code> (Subject) claim cannot always be verified when
    the token is submitted to the RS since the client may not have
    authenticated yet. Also note that a counter for the <code>exi</code> (expires in) claim
    <span class="bcp14">MUST</span> be initialized when the RS first verifies this token.<a href="#section-5.10.1.1-9" class="pilcrow">¶</a></p>
<p id="section-5.10.1.1-10">Also note that profiles of this framework may define access token
    transport mechanisms that do not allow for error responses.  Therefore, the
    error messages specified here only apply if the token was sent to the
    authz-info endpoint.<a href="#section-5.10.1.1-10" class="pilcrow">¶</a></p>
<p id="section-5.10.1.1-11">When sending error responses, the RS <span class="bcp14">MAY</span> use the error
     codes from <span><a href="https://www.rfc-editor.org/rfc/rfc6750#section-3.1" class="relref">Section 3.1</a> of [<a href="#RFC6750" class="xref">RFC6750</a>]</span> to
     provide additional details to the client.<a href="#section-5.10.1.1-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="protAuthzInfo">
<section id="section-5.10.1.2">
            <h5 id="name-protecting-the-authorizatio">
<a href="#section-5.10.1.2" class="section-number selfRef">5.10.1.2. </a><a href="#name-protecting-the-authorizatio" class="section-name selfRef">Protecting the Authorization Information Endpoint</a>
            </h5>
<p id="section-5.10.1.2-1">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.<a href="#section-5.10.1.2-1" class="pilcrow">¶</a></p>
<p id="section-5.10.1.2-2">Specifically, it <span class="bcp14">SHOULD NOT</span> be possible to perform GET,
     DELETE, or PUT on the authz-info endpoint.<a href="#section-5.10.1.2-2" class="pilcrow">¶</a></p>
<p id="section-5.10.1.2-3">The RS <span class="bcp14">SHOULD</span> implement rate-limiting measures to mitigate
     attacks aiming
     to overload the processing capacity of the RS by repeatedly submitting
     tokens. For CoAP-based communication, the RS could use the mechanisms from
     <span>[<a href="#RFC8516" class="xref">RFC8516</a>]</span> to indicate that it is overloaded.<a href="#section-5.10.1.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="requestC2RS">
<section id="section-5.10.2">
          <h4 id="name-client-requests-to-the-rs">
<a href="#section-5.10.2" class="section-number selfRef">5.10.2. </a><a href="#name-client-requests-to-the-rs" class="section-name selfRef">Client Requests to the RS</a>
          </h4>
<p id="section-5.10.2-1">Before sending a request to an RS, the client <span class="bcp14">MUST</span> verify that the keys
  used to protect this communication are still valid. See <a href="#keyExpiration" class="xref">Section 5.10.4</a> for details on how the client determines the
  validity of the keys used.<a href="#section-5.10.2-1" class="pilcrow">¶</a></p>
<p id="section-5.10.2-2">If an RS receives a request from a client and the target resource
  requires authorization, the RS <span class="bcp14">MUST</span> first verify that it has an access token
  that authorizes this request and that the client has performed the
  proof-of-possession binding for that token to the request.<a href="#section-5.10.2-2" class="pilcrow">¶</a></p>
<p id="section-5.10.2-3">The response code <span class="bcp14">MUST</span> be 4.01 (Unauthorized) in case the client has
  not performed the proof of possession or if the RS has no valid access token for
  the client. If the RS has an access token for the client but the token does not
  authorize access for the resource that was requested, the RS <span class="bcp14">MUST</span> 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 <span class="bcp14">MUST</span>
  reject the request with a 4.05 (Method Not Allowed).<a href="#section-5.10.2-3" class="pilcrow">¶</a></p>
<p id="section-5.10.2-4">Note: The use of the response codes 4.03 and 4.05 is intended to prevent
  infinite loops where a client optimistically tries to access a
  requested resource with any access token received from AS. As malicious
  clients could pretend to be the C to determine the C's privileges, these detailed
  response codes must be used only when a certain level of security is
  already available, which can be achieved only when the client is
  authenticated.<a href="#section-5.10.2-4" class="pilcrow">¶</a></p>
<p id="section-5.10.2-5">Note: The RS <span class="bcp14">MAY</span> use introspection for timely validation of an
  access token at the time when a request is presented.<a href="#section-5.10.2-5" class="pilcrow">¶</a></p>
<p id="section-5.10.2-6">Note: Matching the claims of the access token (e.g., <code>scope</code>) to a specific
  request is application specific.<a href="#section-5.10.2-6" class="pilcrow">¶</a></p>
<p id="section-5.10.2-7">If the request matches a valid token and the client has performed the
  proof of possession for that token, the RS continues to process the request
  as specified by the underlying application.<a href="#section-5.10.2-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tokenExpiration">
<section id="section-5.10.3">
          <h4 id="name-token-expiration">
<a href="#section-5.10.3" class="section-number selfRef">5.10.3. </a><a href="#name-token-expiration" class="section-name selfRef">Token Expiration</a>
          </h4>
<p id="section-5.10.3-1">Depending on the capabilities of the RS, there are various ways in
   which it can verify the expiration of a received access token.  The following is
   a list of the possibilities including what functionality they require of the
   RS.<a href="#section-5.10.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.10.3-2.1">The token is a CWT and includes an <code>exp</code> claim and possibly the
     <code>nbf</code> claim.  The RS verifies these by comparing them to values from
     its internal clock, as defined in <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span>.  In
     this case, the RS's internal clock must reflect the current date and time or
     at least be synchronized with the AS's clock.  How this clock
     synchronization would be performed is out of scope for this
     specification.<a href="#section-5.10.3-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.10.3-2.2">The RS verifies the validity of the token by performing an
     introspection request, as specified in <a href="#introspectionEndpoint" class="xref">Section 5.9</a>.  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).<a href="#section-5.10.3-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.10.3-2.3">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 <code>exi</code> (expires in) can be used to provide
     the RS with the lifetime of the token in seconds from the time the RS first
     receives the token.  This mechanism only works for self-contained tokens,
     i.e., CWTs and JWTs. For CWTs, this parameter is encoded as an unsigned integer,
     while JWTs encode this as JSON number.<a href="#section-5.10.3-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.10.3-2.4">
              <p id="section-5.10.3-2.4.1"> Processing this claim requires that the RS does the following:<a href="#section-5.10.3-2.4.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.10.3-2.4.2.1">For each token the RS receives that contains an <code>exi</code> claim,
 keep track of the time it received that token and revisit that list
 regularly to expunge expired tokens.<a href="#section-5.10.3-2.4.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-5.10.3-2.4.2.2">
                  <p id="section-5.10.3-2.4.2.2.1">Keep track of the identifiers of tokens containing the <code>exi</code>
      claim that have expired (in order to avoid accepting them again).
      In order to avoid an unbounded memory usage growth, this <span class="bcp14">MUST</span> be
      implemented in the following way when the <code>exi</code> claim is used:<a href="#section-5.10.3-2.4.2.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.10.3-2.4.2.2.2.1">When creating the token, the AS <span class="bcp14">MUST</span> add a <code>cti</code> claim (or <code>jti</code> for JWTs) to the access token.  The value of this claim
 <span class="bcp14">MUST</span> be created as the binary representation of the concatenation
 of the identifier of the RS with a sequence number counting the
 tokens containing an <code>exi</code> claim, issued by this AS for the
 RS.<a href="#section-5.10.3-2.4.2.2.2.1" class="pilcrow">¶</a>
</li>
                    <li class="normal" id="section-5.10.3-2.4.2.2.2.2">The RS <span class="bcp14">MUST</span> store the highest sequence number of an expired
 token containing the <code>exi</code> claim that it has seen and treat
 tokens with lower sequence numbers as expired.  Note that
        this could lead to discarding valid tokens with lower sequence numbers
        if the AS where to issue tokens of different validity time for the same
 RS.  The assumption is that typically tokens in such a scenario would
 all have the same validity time.<a href="#section-5.10.3-2.4.2.2.2.2" class="pilcrow">¶</a>
</li>
                  </ul>
</li>
              </ul>
</li>
          </ul>
<p id="section-5.10.3-3">If a token that authorizes a long-running request, such as a CoAP
  Observe <span>[<a href="#RFC7641" class="xref">RFC7641</a>]</span>, expires, the RS <span class="bcp14">MUST</span> send an error
  response with the response code equivalent to the CoAP code 4.01
  (Unauthorized) to the client and then terminate processing the long-running
  request.<a href="#section-5.10.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="keyExpiration">
<section id="section-5.10.4">
          <h4 id="name-key-expiration">
<a href="#section-5.10.4" class="section-number selfRef">5.10.4. </a><a href="#name-key-expiration" class="section-name selfRef">Key Expiration</a>
          </h4>
<p id="section-5.10.4-1">The AS provides the client with key material that the RS uses. This can
  either be a common symmetric PoP key or an asymmetric key used by the RS to
  authenticate towards the client.  Since there is currently no expiration
  metadata associated to those keys, the client has no way of knowing if these
  keys are still valid.  This may lead to situations where the client sends
  requests containing sensitive information to the RS using a key that is
  expired and possibly in the hands of an attacker or where the client accepts responses from
  the RS that are not properly protected and could possibly have been forged by
  an attacker.<a href="#section-5.10.4-1" class="pilcrow">¶</a></p>
<p id="section-5.10.4-2">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 <span class="bcp14">MUST</span> be used to
  inform the client about the validity of an access token:<a href="#section-5.10.4-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.10.4-3.1">The client knows a default validity time for all tokens it is
    using (i.e., how long a token is valid after being issued).  This
    information could be provisioned to the client when it is registered at the
    AS or published by the AS in a way that the client can query.<a href="#section-5.10.4-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.10.4-3.2">The AS informs the client about the token validity using the
    <code>expires_in</code> parameter in the Access Information.<a href="#section-5.10.4-3.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-5.10.4-4">A client that is not able to obtain information about the expiration of a
  token <span class="bcp14">MUST NOT</span> use this token.<a href="#section-5.10.4-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="security">
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">Security considerations applicable to authentication and authorization
  in RESTful environments provided in OAuth 2.0 <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span> apply
  to this work.  Furthermore, <span>[<a href="#RFC6819" class="xref">RFC6819</a>]</span>
  provides additional security considerations for OAuth, which apply to IoT
  deployments as well.  If the introspection endpoint is used,
  the security considerations from <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span> also apply.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">The following subsections address issues specific to this document and
      its use in constrained environments.<a href="#section-6-2" class="pilcrow">¶</a></p>
<div id="tokenProtection">
<section id="section-6.1">
        <h3 id="name-protecting-tokens">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-protecting-tokens" class="section-name selfRef">Protecting Tokens</a>
        </h3>
<p id="section-6.1-1">A large range of threats can be mitigated by protecting the contents
 of the access token by using a digital signature or a keyed message
 digest, e.g., a Message Authentication Code (MAC) or an Authenticated 
 Encryption with Associated Data (AEAD)
 algorithm.  Consequently, the token integrity protection <span class="bcp14">MUST</span> be
 applied to prevent the token from being modified, particularly since it contains
 a reference to the symmetric key or the asymmetric key used for
 proof of possession.  If the access token contains the symmetric key,
 this symmetric key <span class="bcp14">MUST</span> 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.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">If the token is intended for multiple recipients (i.e., an audience
      that is a group), integrity protection of the token with a symmetric key,
      shared between the AS and the recipients, is not sufficient, since any of
      the recipients could modify the token undetected by the other recipients.
      Therefore, a token with a multirecipient audience <span class="bcp14">MUST</span> be protected
      with an asymmetric signature.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<p id="section-6.1-3">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 <span class="bcp14">MUST NOT</span> be used as a proof-of-possession key with
      multiple resource servers, since the benefit from using the proof-of-possession
      concept is then significantly reduced.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<p id="section-6.1-4">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).<a href="#section-6.1-4" class="pilcrow">¶</a></p>
<p id="section-6.1-5">When authorization servers bind symmetric keys to access tokens,
      they <span class="bcp14">SHOULD</span> scope these access tokens to a specific permission.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
<p id="section-6.1-6">In certain situations, it may be necessary to revoke an access
 token that is still valid.  Client-initiated revocation is specified
 in <span>[<a href="#RFC7009" class="xref">RFC7009</a>]</span> for OAuth 2.0.  Other revocation
 mechanisms
 are currently not specified, as the underlying assumption in OAuth
 is that access tokens are issued with a relatively short lifetime.
 This may not hold true for disconnected constrained devices needing
 access tokens with relatively long lifetimes and would therefore
 necessitate further standardization work that is out of scope for
 this document.<a href="#section-6.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="commSec">
<section id="section-6.2">
        <h3 id="name-communication-security">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-communication-security" class="section-name selfRef">Communication Security</a>
        </h3>
<p id="section-6.2-1">Communication with the authorization server <span class="bcp14">MUST</span> use confidentiality
      protection.  This step is extremely important since the client or the
      RS may obtain the proof-of-possession key from the authorization server
      for use with a specific access token.  Not using confidentiality
      protection exposes this secret (and the access token) to an eavesdropper,
      thereby completely negating proof-of-possession security.
      The requirements for communication security of profiles are specified
      in <a href="#oauthProfile" class="xref">Section 5</a>.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">Additional protection for the access token can be applied by
 encrypting it, for example, encryption of CWTs is specified in
 <span><a href="https://www.rfc-editor.org/rfc/rfc8392#section-7.1" class="relref">Section 7.1</a> of [<a href="#RFC8392" class="xref">RFC8392</a>]</span>.  Such additional
 protection can be necessary
 if the token is later transferred over an insecure connection
 (e.g., when it is sent to the authz-info endpoint).<a href="#section-6.2-2" class="pilcrow">¶</a></p>
<p id="section-6.2-3">Care must be taken by developers to prevent leakage of the PoP 
      credentials (i.e., the private key or the symmetric key).  An
      adversary in possession of the PoP credentials bound to the access
      token will be able to impersonate the client.  Be aware that this is a
      real risk with many constrained environments, since adversaries may
      get physical access to the devices and can therefore use physical
      extraction techniques to gain access to memory contents.  This risk can 
      be mitigated to some extent by making sure that keys are refreshed
      frequently, by using software isolation techniques, and by using hardware
 security.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="keys">
<section id="section-6.3">
        <h3 id="name-long-term-credentials">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-long-term-credentials" class="section-name selfRef">Long-Term Credentials</a>
        </h3>
<p id="section-6.3-1">Both the clients and RSs have long-term credentials that are used to
      secure communications and authenticate to the AS.  These credentials
      need to be protected against unauthorized access.  In constrained
      devices deployed in publicly accessible places, such protection can
      be difficult to achieve without specialized hardware (e.g., secure
      key storage memory).<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">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 <span class="bcp14">MUST NOT</span> lead to a
      compromise of other credentials not linked to that device; therefore,
      secret keys used for authentication <span class="bcp14">MUST NOT</span> be shared between more than
      two parties.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
<p id="section-6.3-3">Operators of the clients or RSs <span class="bcp14">SHOULD</span> have procedures in place to
      replace credentials that are suspected to have been compromised or that
      have been lost.<a href="#section-6.3-3" class="pilcrow">¶</a></p>
<p id="section-6.3-4">Operators also <span class="bcp14">SHOULD</span> have procedures for decommissioning devices
      that include securely erasing credentials and other security-critical
      material in the devices being decommissioned.<a href="#section-6.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="unprotected-as-information">
<section id="section-6.4">
        <h3 id="name-unprotected-as-request-crea">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-unprotected-as-request-crea" class="section-name selfRef">Unprotected AS Request Creation Hints</a>
        </h3>
<p id="section-6.4-1">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 <a href="#asInfo" class="xref">Section 5.3</a>) are
 authentic. Therefore, the C
 <span class="bcp14">MUST</span> 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.<a href="#section-6.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="minimalCommSecReq">
<section id="section-6.5">
        <h3 id="name-minimal-security-requiremen">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-minimal-security-requiremen" class="section-name selfRef">Minimal Security Requirements for Communication</a>
        </h3>
<p id="section-6.5-1">This section summarizes the minimal requirements for the
 communication security of the different protocol interactions.<a href="#section-6.5-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-6.5-2">
          <dt id="section-6.5-2.1">C-AS</dt>
          <dd style="margin-left: 1.5em" id="section-6.5-2.2">All communication between the client and the
   authorization server <span class="bcp14">MUST</span> be encrypted and integrity and
   replay
   protected. Furthermore, responses from the AS to the client <span class="bcp14">MUST</span> be
   bound to the client's request to avoid attacks where the attacker
   swaps the intended response for an older one valid for a previous
   request.  This requires that the client and the authorization server
   have previously exchanged either a shared secret or their public
   keys in order to negotiate a secure communication. Furthermore, the
   client <span class="bcp14">MUST</span> be able to determine whether an AS has the authority
   to issue access tokens for a certain RS.  This can, for example, be
   done through preconfigured lists or through an online lookup
   mechanism that in turn also must be secured.<a href="#section-6.5-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-6.5-2.3">RS-AS</dt>
          <dd style="margin-left: 1.5em" id="section-6.5-2.4">The communication between the resource
   server and the authorization server via the introspection endpoint
   <span class="bcp14">MUST</span> be encrypted and integrity and replay protected. Furthermore,
   responses from the AS to the RS <span class="bcp14">MUST</span> be bound to the RS's request.
   This requires that the RS and the authorization server
   have previously exchanged either a shared secret or their public
   keys in order to negotiate a secure communication. Furthermore, the
   RS <span class="bcp14">MUST</span> be able to determine whether an AS has the authority
   to issue access tokens itself.  This is usually configured out of
   band but could also be performed through an online lookup mechanism,
   provided that it is also secured in the same way.<a href="#section-6.5-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-6.5-2.5">C-RS</dt>
          <dd style="margin-left: 1.5em" id="section-6.5-2.6">The initial communication between the client
   and the resource server cannot be secured in general, since
   the RS is not in possession of on access token for that client,
   which would carry the necessary parameters.  If both parties
   support DTLS without client authentication, it is <span class="bcp14">RECOMMENDED</span> 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 <span class="bcp14">MUST</span> be established between the
   client and RS for the actual resource request.  This protocol <span class="bcp14">MUST</span>
   provide confidentiality, integrity, and replay protection, as well as a
   binding between requests and responses.  This requires that the
   client learned either the RS's public key or received a symmetric
   proof-of-possession key bound to the access token from the AS.
   The RS must have learned either the client's public key, a shared
   symmetric key from the claims in the token, or an introspection
   request.  Since ACE does not provide profile negotiation between the
   C and RS, the client <span class="bcp14">MUST</span> have learned what profile the RS
   supports (e.g., from the AS or preconfigured) and initiated the
   communication accordingly.<a href="#section-6.5-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="nonce">
<section id="section-6.6">
        <h3 id="name-token-freshness-and-expirat">
<a href="#section-6.6" class="section-number selfRef">6.6. </a><a href="#name-token-freshness-and-expirat" class="section-name selfRef">Token Freshness and Expiration</a>
        </h3>
<p id="section-6.6-1">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 (<code>cnonce</code>) defined in <a href="#asInfo" class="xref">Section 5.3</a> to ensure
 freshness of an Access Token subsequently presented to this RS.<a href="#section-6.6-1" class="pilcrow">¶</a></p>
<p id="section-6.6-2">Another problem with clock drift is that evaluating the
 standard token expiration claim <code>exp</code> can give unpredictable results.<a href="#section-6.6-2" class="pilcrow">¶</a></p>
<p id="section-6.6-3">Acceptable ranges of clock drift are highly dependent on the
 concrete application.  Important factors are how long access tokens
 are valid and how critical timely expiration of the access token is.<a href="#section-6.6-3" class="pilcrow">¶</a></p>
<p id="section-6.6-4">The expiration mechanism implemented by the <code>exi</code> claim, based on
 the first time the RS sees the token, was defined to provide a more
 predictable alternative.  The <code>exi</code> approach has some drawbacks that
 need to be considered:<a href="#section-6.6-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.6-5.1">A malicious client may hold back tokens with the <code>exi</code> claim in
   order to prolong their lifespan.<a href="#section-6.6-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.6-5.2">
   If an RS loses state (e.g., due to an unscheduled reboot), it
   may lose the current values of counters tracking the <code>exi</code> claims of
   tokens it is storing.<a href="#section-6.6-5.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.6-6">
 The first drawback is inherent to the deployment scenario and the <code>exi</code>
 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 <code>exi</code> counters to persistent memory.<a href="#section-6.6-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="mixnmatch">
<section id="section-6.7">
        <h3 id="name-combining-profiles">
<a href="#section-6.7" class="section-number selfRef">6.7. </a><a href="#name-combining-profiles" class="section-name selfRef">Combining Profiles</a>
        </h3>
<p id="section-6.7-1">There may be use cases where different transport and security
      protocols are allowed for the different interactions, and, if that is
      not explicitly covered by an existing profile, it corresponds to
      combining profiles into a new one.  For example, a new profile could
      specify that a previously defined MQTT-TLS profile is used between
      the client and the RS in combination with a previously defined
      CoAP-DTLS profile for interactions between the client and the AS. The
      new profile that combines existing profiles <span class="bcp14">MUST</span> specify how the
      existing profiles' security requirements remain satisfied. Therefore, any profile
      <span class="bcp14">MUST</span> clearly specify its security requirements and <span class="bcp14">MUST</span>
      document if its security depends on the combination of various
      protocol interactions.<a href="#section-6.7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="infoLeak">
<section id="section-6.8">
        <h3 id="name-unprotected-information">
<a href="#section-6.8" class="section-number selfRef">6.8. </a><a href="#name-unprotected-information" class="section-name selfRef">Unprotected Information</a>
        </h3>
<p id="section-6.8-1">Communication with the authz-info endpoint, as well as the
 various error responses defined in this framework, potentially
 includes sending information over an unprotected channel.
 These messages may leak information to an adversary or may be
 manipulated by active attackers to induce incorrect behavior.  For
 example, error responses for requests to the authorization information
 endpoint can reveal information about an otherwise opaque access token
 to an adversary who has intercepted this token.<a href="#section-6.8-1" class="pilcrow">¶</a></p>
<p id="section-6.8-2">As far as error messages are concerned, this framework is written
 under the assumption that, in general, the benefits of detailed error
 messages outweigh the risk due to information leakage. For particular
 use cases where this assessment does not apply, detailed error
 messages can be replaced by more generic ones.<a href="#section-6.8-2" class="pilcrow">¶</a></p>
<p id="section-6.8-3">In some scenarios, it may be possible to protect the
 communication with the authz-info endpoint (e.g., through
 DTLS with only server-side authentication). In cases where
 this is not possible, it is <span class="bcp14">RECOMMENDED</span> to use encrypted
 CWTs or tokens that are opaque references and need to be subjected to
 introspection by the RS.<a href="#section-6.8-3" class="pilcrow">¶</a></p>
<p id="section-6.8-4">If the initial Unauthorized Resource Request message (see <a href="#rreq" class="xref">Section 5.2</a>) is used, the client <span class="bcp14">MUST</span> 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.<a href="#section-6.8-4" class="pilcrow">¶</a></p>
<p id="section-6.8-5">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 <code>ace_profile</code>
 claim requesting the use of said obsolete profile.  Resource owners
 should update the configuration of their RSs to prevent them from
 using such obsolete profiles.<a href="#section-6.8-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="audience">
<section id="section-6.9">
        <h3 id="name-identifying-audiences">
<a href="#section-6.9" class="section-number selfRef">6.9. </a><a href="#name-identifying-audiences" class="section-name selfRef">Identifying Audiences</a>
        </h3>
<p id="section-6.9-1">The <code>aud</code> claim, as defined in <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span>,
 and the equivalent <code>audience</code> parameter from
 <span>[<a href="#RFC8693" class="xref">RFC8693</a>]</span> are intentionally vague
 on how to match the audience value to a specific RS.  This is intended
 to allow application-specific semantics to be used.  This section
 attempts to give some general guidance for the use of audiences in
 constrained environments.<a href="#section-6.9-1" class="pilcrow">¶</a></p>
<p id="section-6.9-2">URLs are not a good way of identifying mobile devices that can
 switch networks and thus be associated with new URLs.  If the
 audience represents a single RS and asymmetric keys are used,
 the RS can be uniquely identified by a hash of its public key.
 If this approach is used, it is <span class="bcp14">RECOMMENDED</span> to apply the
 procedure from <span><a href="https://www.rfc-editor.org/rfc/rfc6920#section-3" class="relref">Section 3</a> of [<a href="#RFC6920" class="xref">RFC6920</a>]</span>.<a href="#section-6.9-2" class="pilcrow">¶</a></p>
<p id="section-6.9-3">If the audience addresses a group of resource servers, the mapping
 of a group identifier to an individual RS has to be provisioned to each RS
 before the group-audience is usable.  Managing dynamic groups could be
 an issue if any RS is not always reachable when the groups' memberships
 change. Furthermore, issuing access tokens bound to symmetric
 proof-of-possession keys that apply to a group-audience is problematic,
 as an RS that is in possession of the access token can impersonate the
 client towards the other RSs that are part of the group.  It is
 therefore <span class="bcp14">NOT RECOMMENDED</span> to issue access tokens bound
 to a group-audience and symmetric proof-of possession keys.<a href="#section-6.9-3" class="pilcrow">¶</a></p>
<p id="section-6.9-4">Even the client must be able to determine the correct values to put
 into the <code>audience</code> 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 <code>audience</code> can either be provisioned to the client as part of its
 configuration or dynamically looked up by the client in some
 directory. In the latter case, the integrity and correctness of the
 directory data must be assured.  Note that the <code>audience</code> hint
 provided by the RS as part of the AS Request Creation Hints (<a href="#asInfo" class="xref">Section 5.3</a>) is not typically source authenticated and
 integrity protected and should therefore not be treated a trusted value.<a href="#section-6.9-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="introDos">
<section id="section-6.10">
        <h3 id="name-denial-of-service-against-o">
<a href="#section-6.10" class="section-number selfRef">6.10. </a><a href="#name-denial-of-service-against-o" class="section-name selfRef">Denial of Service Against or with Introspection</a>
        </h3>
<p id="section-6.10-1">
 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.<a href="#section-6.10-1" class="pilcrow">¶</a></p>
<p id="section-6.10-2">First, an attacker could perform a denial-of-service attack against
 the introspection endpoint at the AS in order to prevent validation of
 access tokens.  To maintain the security of the system, an RS that is
 configured to use introspection <span class="bcp14">MUST NOT</span> allow access based on a token
 for which it couldn't reach the introspection endpoint.<a href="#section-6.10-2" class="pilcrow">¶</a></p>
<p id="section-6.10-3">Second, an attacker could use the fact that an RS performs
 introspection to perform a denial-of-service attack against that RS by
 repeatedly sending tokens to its authz-info endpoint that require an
 introspection call. The RS can mitigate such attacks by implementing rate
 limits on how many introspection requests they perform in a given time
 interval for a certain client IP address submitting tokens to
 /authz-info.  When that limit has been reached, incoming requests from
 that address are rejected for a certain amount of time.  A general rate
 limit on the introspection requests should also be considered in order to
 mitigate distributed attacks.<a href="#section-6.10-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="privacy">
<section id="section-7">
      <h2 id="name-privacy-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
      </h2>
<p id="section-7-1">Implementers and users should be aware of the privacy implications
      of the different possible deployments of this framework.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">The AS is in a very central position and can potentially learn sensitive
      information about the clients requesting access tokens.  If the client
      credentials grant is used, the AS can track what kind of access
      the client intends to perform.  With other grants, this can be prevented
      by the resource owner.  To do so, the resource owner needs to bind the
      grants it issues to anonymous, ephemeral credentials that do not allow
      the AS to link different grants and thus different access token requests
      by the same client.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">The claims contained in a token can reveal privacy-sensitive
      information about the client and the RS to any party having access to
      them (whether by processing the content of a self-contained token or by
      introspection).  The AS <span class="bcp14">SHOULD</span> be configured to minimize the information
      about clients and RSs disclosed in the tokens it issues.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">If tokens are only integrity protected and not encrypted, they
      may reveal information to attackers listening on the wire or be able to
      acquire the access tokens in some other way.  In the case of CWTs,
      the token may, e.g., reveal the audience, the scope, and the confirmation
      method used by the client.  The latter may reveal the identity of the
      device or application running the client.  This may be linkable to
      the identity of the person using the client (if there is a person and
      not a machine-to-machine interaction).<a href="#section-7-4" class="pilcrow">¶</a></p>
<p id="section-7-5">Clients using asymmetric keys for proof of possession should be aware
      of the consequences of using the same key pair for proof of possession
      towards different RSs.  A set of colluding RSs or an attacker able to
      obtain the access tokens will be able to link the requests or even
      to determine the client's identity.<a href="#section-7-5" class="pilcrow">¶</a></p>
<p id="section-7-6">An unprotected response to an unauthorized request (see 
      <a href="#asInfo" class="xref">Section 5.3</a>) 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.<a href="#section-7-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-8-1">This document creates several registries with a registration policy of
  Expert Review; guidelines to the experts are given in
  <a href="#IANAinstructions" class="xref">Section 8.17</a>.<a href="#section-8-1" class="pilcrow">¶</a></p>
<div id="IANAASInformation">
<section id="section-8.1">
        <h3 id="name-ace-authorization-server-re">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-ace-authorization-server-re" class="section-name selfRef">ACE Authorization Server Request Creation Hints</a>
        </h3>
<p id="section-8.1-1">This specification establishes the IANA "ACE Authorization Server
    Request Creation Hints" registry.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<p id="section-8.1-2">The columns of the registry are:<a href="#section-8.1-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.1-3">
          <dt id="section-8.1-3.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-3.2">The name of the parameter.<a href="#section-8.1-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-3.3">CBOR Key:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-3.4">CBOR map key for the parameter.  Different ranges
      of values use different registration policies <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>. 
      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.<a href="#section-8.1-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-3.5">Value Type:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-3.6">The CBOR data types allowable for the values of
      this parameter.<a href="#section-8.1-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-3.7">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-3.8">This contains a pointer to the public
      specification of the Request Creation Hint abbreviation, if one
      exists.<a href="#section-8.1-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-8.1-4">This registry has been initially populated by the values in <a href="#table_asinfo" class="xref">Table 1</a>. The Reference column for all of these entries is this document.<a href="#section-8.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANAcoreRT">
<section id="section-8.2">
        <h3 id="name-core-resource-types">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-core-resource-types" class="section-name selfRef">CoRE Resource Types</a>
        </h3>
<p id="section-8.2-1">IANA has registered a new Resource Type (rt=) Link Target
    Attribute in the "Resource Type (rt=) Link Target Attribute Values"
    subregistry under the "Constrained RESTful Environments (CoRE)
    Parameters" <span>[<a href="#IANA.CoreParameters" class="xref">IANA.CoreParameters</a>]</span> registry:<a href="#section-8.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.2-2">
          <dt id="section-8.2-2.1">Value:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.2">
            <code>ace.ai</code><a href="#section-8.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.3">Description:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.4">ACE-OAuth authz-info endpoint resource.<a href="#section-8.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.5">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.6">RFC 9200<a href="#section-8.2-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-8.2-3">Specific ACE-OAuth profiles can use this common resource type for
   defining their profile-specific discovery processes.<a href="#section-8.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANAOAuthErrorCodes">
<section id="section-8.3">
        <h3 id="name-oauth-extensions-errors">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-oauth-extensions-errors" class="section-name selfRef">OAuth Extensions Errors</a>
        </h3>
<p id="section-8.3-1">This specification registers the following error values in the
 "OAuth Extensions Error Registry"
    <span>[<a href="#IANA.OAuthExtensionsErrorRegistry" class="xref">IANA.OAuthExtensionsErrorRegistry</a>]</span>.<a href="#section-8.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.3-2">
          <dt id="section-8.3-2.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.3-2.2">
            <code>unsupported_pop_key</code><a href="#section-8.3-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.3-2.3">Usage Location:</dt>
          <dd style="margin-left: 1.5em" id="section-8.3-2.4">token error response<a href="#section-8.3-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.3-2.5">Protocol Extension:</dt>
          <dd style="margin-left: 1.5em" id="section-8.3-2.6">RFC 9200<a href="#section-8.3-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.3-2.7">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.3-2.8">IETF<a href="#section-8.3-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.3-2.9">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.3-2.10">
            <a href="#errorsToken" class="xref">Section 5.8.3</a> of RFC 9200<a href="#section-8.3-2.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.3-3">
          <dt id="section-8.3-3.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.3-3.2">
            <code>incompatible_ace_profiles</code><a href="#section-8.3-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.3-3.3">Usage Location:</dt>
          <dd style="margin-left: 1.5em" id="section-8.3-3.4">token error response<a href="#section-8.3-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.3-3.5">Protocol Extension:</dt>
          <dd style="margin-left: 1.5em" id="section-8.3-3.6">RFC 9200<a href="#section-8.3-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.3-3.7">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.3-3.8">IETF<a href="#section-8.3-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.3-3.9">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.3-3.10">
            <a href="#errorsToken" class="xref">Section 5.8.3</a> of RFC 9200<a href="#section-8.3-3.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="IANAErrorCBORMappings">
<section id="section-8.4">
        <h3 id="name-oauth-error-code-cbor-mappi">
<a href="#section-8.4" class="section-number selfRef">8.4. </a><a href="#name-oauth-error-code-cbor-mappi" class="section-name selfRef">OAuth Error Code CBOR Mappings</a>
        </h3>
<p id="section-8.4-1">This specification establishes the IANA "OAuth Error Code
    CBOR Mappings" registry.<a href="#section-8.4-1" class="pilcrow">¶</a></p>
<p id="section-8.4-2">The columns of the registry are:<a href="#section-8.4-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.4-3">
          <dt id="section-8.4-3.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.4-3.2">The OAuth Error Code name, refers to the name in
   <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>, e.g.,
   "invalid_request".<a href="#section-8.4-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.4-3.3">CBOR Value:</dt>
          <dd style="margin-left: 1.5em" id="section-8.4-3.4">CBOR abbreviation for this error code.   
Integer values less than -65536 are marked as Private Use; all other values use          
the registration policy Expert Review <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-8.4-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.4-3.5">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.4-3.6">This contains a pointer to the public
   specification of the error code abbreviation, if one exists.<a href="#section-8.4-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.4-3.7">Original Specification:</dt>
          <dd style="margin-left: 1.5em" id="section-8.4-3.8">This contains a pointer to the public
         specification of the error code, if one exists.<a href="#section-8.4-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-8.4-4">This registry has been initially populated by the values in <a href="#table_cborErrorCodes" class="xref">Table 3</a>. The Reference column for all of these entries is this document.<a href="#section-8.4-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANAGrantTypeMappings">
<section id="section-8.5">
        <h3 id="name-oauth-grant-type-cbor-mappi">
<a href="#section-8.5" class="section-number selfRef">8.5. </a><a href="#name-oauth-grant-type-cbor-mappi" class="section-name selfRef">OAuth Grant Type CBOR Mappings</a>
        </h3>
<p id="section-8.5-1">This specification establishes the IANA "OAuth Grant Type CBOR Mappings"
    registry.<a href="#section-8.5-1" class="pilcrow">¶</a></p>
<p id="section-8.5-2">The columns of this registry are:<a href="#section-8.5-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.5-3">
          <dt id="section-8.5-3.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.5-3.2">The name of the grant type, as specified in
      <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-1.3" class="relref">Section 1.3</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-8.5-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.5-3.3">CBOR Value:</dt>
          <dd style="margin-left: 1.5em" id="section-8.5-3.4">CBOR abbreviation for this grant type. Integer
      values less than -65536 are marked as Private Use; all other values use
      the registration policy Expert Review <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-8.5-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.5-3.5">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.5-3.6">This contains a pointer to the public
      specification of the grant type abbreviation, if one exists.<a href="#section-8.5-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.5-3.7">Original Specification:</dt>
          <dd style="margin-left: 1.5em" id="section-8.5-3.8">This contains a pointer to
      the public specification of the grant type, if one exists.<a href="#section-8.5-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-8.5-4">This registry has been initially populated by the values in <a href="#table_grant_types" class="xref">Table 4</a>. The Reference column for all of these entries is this document.<a href="#section-8.5-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANAOAuthTokenType">
<section id="section-8.6">
        <h3 id="name-oauth-access-token-types">
<a href="#section-8.6" class="section-number selfRef">8.6. </a><a href="#name-oauth-access-token-types" class="section-name selfRef">OAuth Access Token Types</a>
        </h3>
<p id="section-8.6-1">This section registers the following new token type in the
    "OAuth Access Token Types" registry <span>[<a href="#IANA.OAuthAccessTokenTypes" class="xref">IANA.OAuthAccessTokenTypes</a>]</span>.<a href="#section-8.6-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.6-2">
          <dt id="section-8.6-2.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.2">
            <code>PoP</code><a href="#section-8.6-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.6-2.3">Additional Token Endpoint Response Parameters:</dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.4">
            <code>cnf</code>, <code>rs_cnf</code> (see <span><a href="https://www.rfc-editor.org/rfc/rfc8747#section-3.1" class="relref">Section 3.1</a> of [<a href="#RFC8747" class="xref">RFC8747</a>]</span> and <span><a href="https://www.rfc-editor.org/rfc/rfc9201#section-3.2" class="relref">Section 3.2</a> of [<a href="#RFC9201" class="xref">RFC9201</a>]</span>).<a href="#section-8.6-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.6-2.5">HTTP Authentication Scheme(s):</dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.6">N/A<a href="#section-8.6-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.6-2.7">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.8">IETF<a href="#section-8.6-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.6-2.9">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.10">RFC 9200<a href="#section-8.6-2.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="IANATokenTypeMappings">
<section id="section-8.7">
        <h3 id="name-oauth-access-token-type-cbo">
<a href="#section-8.7" class="section-number selfRef">8.7. </a><a href="#name-oauth-access-token-type-cbo" class="section-name selfRef">OAuth Access Token Type CBOR Mappings</a>
        </h3>
<p id="section-8.7-1">This specification establishes the IANA "OAuth Access Token Type CBOR
     Mappings" registry.<a href="#section-8.7-1" class="pilcrow">¶</a></p>
<p id="section-8.7-2">The columns of this registry are:<a href="#section-8.7-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.7-3">
          <dt id="section-8.7-3.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.7-3.2">The name of the token type, as registered in the
      "OAuth Access Token Types" registry, e.g., "Bearer".<a href="#section-8.7-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.7-3.3">CBOR Value:</dt>
          <dd style="margin-left: 1.5em" id="section-8.7-3.4">CBOR abbreviation for this token type. Integer
      values less than -65536 are marked as Private Use; all other values use
      the registration policy Expert Review <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-8.7-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.7-3.5">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.7-3.6">This contains a pointer to the public
      specification of the OAuth token type abbreviation, if one exists.<a href="#section-8.7-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.7-3.7">Original Specification:</dt>
          <dd style="margin-left: 1.5em" id="section-8.7-3.8">This contains a pointer to
      the public specification of the OAuth token type, if one exists.<a href="#section-8.7-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<div id="IANATokenTypeMappingsInitial">
<section id="section-8.7.1">
          <h4 id="name-initial-registry-contents">
<a href="#section-8.7.1" class="section-number selfRef">8.7.1. </a><a href="#name-initial-registry-contents" class="section-name selfRef">Initial Registry Contents</a>
          </h4>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.7.1-1">
            <dt id="section-8.7.1-1.1">Name:</dt>
            <dd style="margin-left: 1.5em" id="section-8.7.1-1.2">
              <code>Bearer</code><a href="#section-8.7.1-1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.7.1-1.3">CBOR Value:</dt>
            <dd style="margin-left: 1.5em" id="section-8.7.1-1.4">1<a href="#section-8.7.1-1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.7.1-1.5">Reference:</dt>
            <dd style="margin-left: 1.5em" id="section-8.7.1-1.6">RFC 9200<a href="#section-8.7.1-1.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.7.1-1.7">Original Specification:</dt>
            <dd style="margin-left: 1.5em" id="section-8.7.1-1.8">
              <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span><a href="#section-8.7.1-1.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.7.1-2">
            <dt id="section-8.7.1-2.1">Name:</dt>
            <dd style="margin-left: 1.5em" id="section-8.7.1-2.2">
              <code>PoP</code><a href="#section-8.7.1-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.7.1-2.3">CBOR Value:</dt>
            <dd style="margin-left: 1.5em" id="section-8.7.1-2.4">2<a href="#section-8.7.1-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.7.1-2.5">Reference:</dt>
            <dd style="margin-left: 1.5em" id="section-8.7.1-2.6">RFC 9200<a href="#section-8.7.1-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.7.1-2.7">Original Specification:</dt>
            <dd style="margin-left: 1.5em" id="section-8.7.1-2.8">RFC 9200<a href="#section-8.7.1-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="IANAProfile">
<section id="section-8.8">
        <h3 id="name-ace-profiles">
<a href="#section-8.8" class="section-number selfRef">8.8. </a><a href="#name-ace-profiles" class="section-name selfRef">ACE Profiles</a>
        </h3>
<p id="section-8.8-1">This specification establishes the IANA "ACE Profile" registry.<a href="#section-8.8-1" class="pilcrow">¶</a></p>
<p id="section-8.8-2">The columns of this registry are:<a href="#section-8.8-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.8-3">
          <dt id="section-8.8-3.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.8-3.2"> The name of the profile to be used as the value of
   the profile attribute.<a href="#section-8.8-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.8-3.3">Description:</dt>
          <dd style="margin-left: 1.5em" id="section-8.8-3.4"> Text giving an overview of the profile and
   the context it is developed for.<a href="#section-8.8-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.8-3.5">CBOR Value:</dt>
          <dd style="margin-left: 1.5em" id="section-8.8-3.6">CBOR abbreviation for this profile name. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.  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.<a href="#section-8.8-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.8-3.7">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.8-3.8">This contains a pointer to the public
      specification of the profile abbreviation, if one exists.<a href="#section-8.8-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="IANAOAuthParameter">
<section id="section-8.9">
        <h3 id="name-oauth-parameters">
<a href="#section-8.9" class="section-number selfRef">8.9. </a><a href="#name-oauth-parameters" class="section-name selfRef">OAuth Parameters</a>
        </h3>
<p id="section-8.9-1">This specification registers the following parameter in the "OAuth
    Parameters" registry <span>[<a href="#IANA.OAuthParameters" class="xref">IANA.OAuthParameters</a>]</span>:<a href="#section-8.9-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.9-2">
          <dt id="section-8.9-2.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.9-2.2">
            <code>ace_profile</code><a href="#section-8.9-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.9-2.3">Parameter Usage Location:</dt>
          <dd style="margin-left: 1.5em" id="section-8.9-2.4">token response<a href="#section-8.9-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.9-2.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.9-2.6">IETF<a href="#section-8.9-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.9-2.7">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.9-2.8">Sections <a href="#tokenResponse" class="xref">5.8.2</a> and
   <a href="#paramProfile" class="xref">5.8.4.3</a> of RFC 9200<a href="#section-8.9-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="IANAOAuthParameterMappingsRegistry">
<section id="section-8.10">
        <h3 id="name-oauth-parameters-cbor-mappi">
<a href="#section-8.10" class="section-number selfRef">8.10. </a><a href="#name-oauth-parameters-cbor-mappi" class="section-name selfRef">OAuth Parameters CBOR Mappings</a>
        </h3>
<p id="section-8.10-1">This specification establishes the IANA "OAuth Parameters CBOR Mappings"
    registry.<a href="#section-8.10-1" class="pilcrow">¶</a></p>
<p id="section-8.10-2">The columns of this registry are:<a href="#section-8.10-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.10-3">
          <dt id="section-8.10-3.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.10-3.2">The OAuth Parameter name, refers to the name in
      the OAuth parameter registry, e.g., <code>client_id</code>.<a href="#section-8.10-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.10-3.3">CBOR Key:</dt>
          <dd style="margin-left: 1.5em" id="section-8.10-3.4">CBOR map key for this parameter.  Integer
      values less than -65536 are marked as Private Use; all other values use
      the registration policy Expert Review <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-8.10-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.10-3.5">Value Type:</dt>
          <dd style="margin-left: 1.5em" id="section-8.10-3.6">The allowable CBOR data types for values
      of this parameter.<a href="#section-8.10-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.10-3.7">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.10-3.8">This contains a pointer to the public
   specification of the OAuth parameter abbreviation, if one exists.<a href="#section-8.10-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.10-3.9">Original Specification</dt>
          <dd style="margin-left: 1.5em" id="section-8.10-3.10">This contains a pointer to the public
         specification of the OAuth parameter, if one exists.<a href="#section-8.10-3.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-8.10-4">This registry has been initially populated by the values in <a href="#table_cborTokenParameters" class="xref">Table 5</a>. The Reference column for all of these entries is this document.<a href="#section-8.10-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANAOAuthIntrospectionResponseParameterRegistration">
<section id="section-8.11">
        <h3 id="name-oauth-introspection-respons">
<a href="#section-8.11" class="section-number selfRef">8.11. </a><a href="#name-oauth-introspection-respons" class="section-name selfRef">OAuth Introspection Response Parameters</a>
        </h3>
<p id="section-8.11-1">This specification registers the following parameters in the "OAuth
    Token Introspection Response" registry <span>[<a href="#IANA.TokenIntrospectionResponse" class="xref">IANA.TokenIntrospectionResponse</a>]</span>.<a href="#section-8.11-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.11-2">
          <dt id="section-8.11-2.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-2.2">
            <code>ace_profile</code><a href="#section-8.11-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.11-2.3">Description:</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-2.4">The ACE profile used between the client and RS.<a href="#section-8.11-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.11-2.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-2.6">IETF<a href="#section-8.11-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.11-2.7">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-2.8">
            <a href="#introRes" class="xref">Section 5.9.2</a> of RFC 9200<a href="#section-8.11-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.11-3">
          <dt id="section-8.11-3.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-3.2">
            <code>cnonce</code><a href="#section-8.11-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.11-3.3">Description:</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-3.4">"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.<a href="#section-8.11-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.11-3.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-3.6">IETF<a href="#section-8.11-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.11-3.7">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-3.8">
            <a href="#introRes" class="xref">Section 5.9.2</a> of RFC 9200<a href="#section-8.11-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.11-4">
          <dt id="section-8.11-4.1">Name</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-4.2">
            <code>cti</code><a href="#section-8.11-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.11-4.3">Description</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-4.4">"CWT ID".  The identifier of a CWT as defined in
   <span>[<a href="#RFC8392" class="xref">RFC8392</a>]</span>.<a href="#section-8.11-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.11-4.5">Change Controller</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-4.6">IETF<a href="#section-8.11-4.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.11-4.7">Reference</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-4.8">
            <a href="#introRes" class="xref">Section 5.9.2</a> of RFC 9200<a href="#section-8.11-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.11-5">
          <dt id="section-8.11-5.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-5.2">
            <code>exi</code><a href="#section-8.11-5.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.11-5.3">Description:</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-5.4">"Expires in". Lifetime of the token in seconds
 from the time the RS first sees it.  Used to implement a weaker form of
 token expiration for devices that cannot synchronize their internal
 clocks.<a href="#section-8.11-5.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.11-5.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-5.6">IETF<a href="#section-8.11-5.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.11-5.7">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.11-5.8">
            <a href="#introRes" class="xref">Section 5.9.2</a> of RFC 9200<a href="#section-8.11-5.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="IANAIntrospectionEndpointCBORMappingsRegistry">
<section id="section-8.12">
        <h3 id="name-oauth-token-introspection-r">
<a href="#section-8.12" class="section-number selfRef">8.12. </a><a href="#name-oauth-token-introspection-r" class="section-name selfRef">OAuth Token Introspection Response CBOR Mappings</a>
        </h3>
<p id="section-8.12-1">This specification establishes the IANA "OAuth Token Introspection
    Response CBOR Mappings" registry.<a href="#section-8.12-1" class="pilcrow">¶</a></p>
<p id="section-8.12-2">The columns of this registry are:<a href="#section-8.12-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.12-3">
          <dt id="section-8.12-3.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.12-3.2">The OAuth Parameter name, refers to the name in
      the OAuth parameter registry, e.g., <code>client_id</code>.<a href="#section-8.12-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.12-3.3">CBOR Key:</dt>
          <dd style="margin-left: 1.5em" id="section-8.12-3.4">CBOR map key for this parameter.  Integer
      values less than -65536 are marked as Private Use; all other values use
      the registration policy Expert Review <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-8.12-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.12-3.5">Value Type:</dt>
          <dd style="margin-left: 1.5em" id="section-8.12-3.6">The allowable CBOR data types for values
      of this parameter.<a href="#section-8.12-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.12-3.7">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.12-3.8">This contains a pointer to the public
   specification of the introspection response parameter abbreviation, if
   one exists.<a href="#section-8.12-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.12-3.9">Original Specification</dt>
          <dd style="margin-left: 1.5em" id="section-8.12-3.10">This contains a pointer to the public
   specification of the OAuth Token Introspection parameter, if one
         exists.<a href="#section-8.12-3.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-8.12-4">
   This registry has been initially populated by the values in <a href="#table_cborIntrospectionParameters" class="xref">Table 6</a>. The Reference column for all of these entries is this document.<a href="#section-8.12-4" class="pilcrow">¶</a></p>
<p id="section-8.12-5">Note that the mappings of parameters corresponding to claim names
    intentionally coincide with the CWT claim name mappings from <span>[<a href="#RFC8392" class="xref">RFC8392</a>]</span>.<a href="#section-8.12-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANAJWTClaims">
<section id="section-8.13">
        <h3 id="name-json-web-token-claims">
<a href="#section-8.13" class="section-number selfRef">8.13. </a><a href="#name-json-web-token-claims" class="section-name selfRef">JSON Web Token Claims</a>
        </h3>
<p id="section-8.13-1">This specification registers the following new claims in the "JSON
 Web Token Claims" subregistry under the "JSON
   Web Token (JWT)" registry <span>[<a href="#IANA.JsonWebTokenClaims" class="xref">IANA.JsonWebTokenClaims</a>]</span>:<a href="#section-8.13-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.13-2">
          <dt id="section-8.13-2.1">Claim Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.13-2.2">
            <code>ace_profile</code><a href="#section-8.13-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.13-2.3">Claim Description:</dt>
          <dd style="margin-left: 1.5em" id="section-8.13-2.4">The ACE profile a token is supposed to be used with.<a href="#section-8.13-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.13-2.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.13-2.6">IETF<a href="#section-8.13-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.13-2.7">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.13-2.8">
            <a href="#accessToken" class="xref">Section 5.10</a> of RFC 9200<a href="#section-8.13-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.13-3">
          <dt id="section-8.13-3.1">Claim Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.13-3.2">
            <code>cnonce</code><a href="#section-8.13-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.13-3.3">Claim Description:</dt>
          <dd style="margin-left: 1.5em" id="section-8.13-3.4">"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.<a href="#section-8.13-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.13-3.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.13-3.6">IETF<a href="#section-8.13-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.13-3.7">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.13-3.8">
            <a href="#accessToken" class="xref">Section 5.10</a> of RFC 9200<a href="#section-8.13-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.13-4">
          <dt id="section-8.13-4.1">Claim Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.13-4.2">
            <code>exi</code><a href="#section-8.13-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.13-4.3">Claim Description:</dt>
          <dd style="margin-left: 1.5em" id="section-8.13-4.4">"Expires in". Lifetime of the token in seconds
      from the time the RS first sees it.  Used to implement a weaker form of
      token expiration for devices that cannot synchronize their internal
      clocks.<a href="#section-8.13-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.13-4.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.13-4.6">IETF<a href="#section-8.13-4.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.13-4.7">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.13-4.8">
            <a href="#tokenExpiration" class="xref">Section 5.10.3</a> of RFC 9200<a href="#section-8.13-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="IANACWTClaims">
<section id="section-8.14">
        <h3 id="name-cbor-web-token-claims">
<a href="#section-8.14" class="section-number selfRef">8.14. </a><a href="#name-cbor-web-token-claims" class="section-name selfRef">CBOR Web Token Claims</a>
        </h3>
<p id="section-8.14-1">This specification registers the following new claims in the "CBOR
    Web Token (CWT) Claims" registry <span>[<a href="#IANA.CborWebTokenClaims" class="xref">IANA.CborWebTokenClaims</a>]</span>.<a href="#section-8.14-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.14-2">
          <dt id="section-8.14-2.1">Claim Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-2.2">
            <code>ace_profile</code><a href="#section-8.14-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-2.3">Claim Description:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-2.4">The ACE profile a token is supposed to be used with.<a href="#section-8.14-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-2.5">JWT Claim Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-2.6">
            <code>ace_profile</code><a href="#section-8.14-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-2.7">Claim Key:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-2.8">38<a href="#section-8.14-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-2.9">Claim Value Type:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-2.10">integer<a href="#section-8.14-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-2.11">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-2.12">IETF<a href="#section-8.14-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-2.13">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-2.14">
            <a href="#accessToken" class="xref">Section 5.10</a> of RFC 9200<a href="#section-8.14-2.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.14-3">
          <dt id="section-8.14-3.1">Claim Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-3.2">
            <code>cnonce</code><a href="#section-8.14-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-3.3">Claim Description:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-3.4">The client-nonce sent to the AS by the RS via the client.<a href="#section-8.14-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-3.5">JWT Claim Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-3.6">
            <code>cnonce</code><a href="#section-8.14-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-3.7">Claim Key:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-3.8">39<a href="#section-8.14-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-3.9">Claim Value Type:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-3.10">byte string<a href="#section-8.14-3.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-3.11">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-3.12">IETF<a href="#section-8.14-3.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-3.13">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-3.14">
            <a href="#accessToken" class="xref">Section 5.10</a> of RFC 9200<a href="#section-8.14-3.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.14-4">
          <dt id="section-8.14-4.1">Claim Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-4.2">
            <code>exi</code><a href="#section-8.14-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-4.3">Claim Description:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-4.4">The expiration time of a token measured from when it was received at the RS
   in seconds.<a href="#section-8.14-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-4.5">JWT Claim Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-4.6">
            <code>exi</code><a href="#section-8.14-4.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-4.7">Claim Key:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-4.8">40<a href="#section-8.14-4.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-4.9">Claim Value Type:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-4.10">unsigned integer<a href="#section-8.14-4.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-4.11">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-4.12">IETF<a href="#section-8.14-4.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-4.13">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-4.14">
            <a href="#tokenExpiration" class="xref">Section 5.10.3</a> of RFC 9200<a href="#section-8.14-4.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.14-5">
          <dt id="section-8.14-5.1">Claim Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-5.2">
            <code>scope</code><a href="#section-8.14-5.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-5.3">Claim Description:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-5.4">The scope of an access token, as defined in <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-8.14-5.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-5.5">JWT Claim Name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-5.6">
            <code>scope</code><a href="#section-8.14-5.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-5.7">Claim Key:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-5.8">9<a href="#section-8.14-5.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-5.9">Claim Value Type:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-5.10">byte string or text string<a href="#section-8.14-5.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-5.11">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-5.12">IETF<a href="#section-8.14-5.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.14-5.13">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.14-5.14">
            <span><a href="https://www.rfc-editor.org/rfc/rfc8693#section-4.2" class="relref">Section 4.2</a> of [<a href="#RFC8693" class="xref">RFC8693</a>]</span><a href="#section-8.14-5.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="IANAmediaType">
<section id="section-8.15">
        <h3 id="name-media-type-registration">
<a href="#section-8.15" class="section-number selfRef">8.15. </a><a href="#name-media-type-registration" class="section-name selfRef">Media Type Registration</a>
        </h3>
<p id="section-8.15-1">This specification registers the "application/ace+cbor" media type for
    messages of the protocols defined in this document carrying parameters
    encoded in CBOR.  This registration follows the procedures specified in
    <span>[<a href="#RFC6838" class="xref">RFC6838</a>]</span>.<a href="#section-8.15-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.15-2">
          <dt id="section-8.15-2.1">Type name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.2">application<a href="#section-8.15-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.3">Subtype name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.4">ace+cbor<a href="#section-8.15-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.5">Required parameters:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.6">N/A<a href="#section-8.15-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.7">Optional parameters:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.8">N/A<a href="#section-8.15-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.9">Encoding considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.10">Must be encoded as a CBOR map containing
 the protocol parameters defined in RFC 9200.<a href="#section-8.15-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.11">Security considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.12">See <a href="#security" class="xref">Section 6</a> of RFC 9200<a href="#section-8.15-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.13">Interoperability considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.14">N/A<a href="#section-8.15-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.15">Published specification:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.16">RFC 9200<a href="#section-8.15-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.17">Applications that use this media type:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.18">The type is used by
 authorization servers, clients, and resource servers that support the ACE
 framework with CBOR encoding, as specified in RFC 9200.<a href="#section-8.15-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.19">Fragment identifier considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.20">N/A<a href="#section-8.15-2.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.21">Additional information:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.22">N/A<a href="#section-8.15-2.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.23">Person &amp; email address to contact for further information:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.24">
            <br>IESG &lt;iesg@ietf.org&gt;<a href="#section-8.15-2.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.25">Intended usage:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.26">COMMON<a href="#section-8.15-2.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.27">Restrictions on usage:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.28">none<a href="#section-8.15-2.28" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.29">Author:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.30">Ludwig Seitz &lt;ludwig.seitz@combitech.se&gt;<a href="#section-8.15-2.30" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.15-2.31">Change controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.15-2.32">IETF<a href="#section-8.15-2.32" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="IANAcoapContentFormat">
<section id="section-8.16">
        <h3 id="name-coap-content-formats">
<a href="#section-8.16" class="section-number selfRef">8.16. </a><a href="#name-coap-content-formats" class="section-name selfRef">CoAP Content-Formats</a>
        </h3>
<p id="section-8.16-1">The following entry has been registered in the "CoAP
    Content-Formats" registry:<a href="#section-8.16-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-8.16-2">
          <dt id="section-8.16-2.1">Media Type:</dt>
          <dd style="margin-left: 1.5em" id="section-8.16-2.2">application/ace+cbor<a href="#section-8.16-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.16-2.3">Encoding:</dt>
          <dd style="margin-left: 1.5em" id="section-8.16-2.4">-<a href="#section-8.16-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.16-2.5">ID:</dt>
          <dd style="margin-left: 1.5em" id="section-8.16-2.6">19<a href="#section-8.16-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.16-2.7">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.16-2.8">RFC 9200<a href="#section-8.16-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="IANAinstructions">
<section id="section-8.17">
        <h3 id="name-expert-review-instructions">
<a href="#section-8.17" class="section-number selfRef">8.17. </a><a href="#name-expert-review-instructions" class="section-name selfRef">Expert Review Instructions</a>
        </h3>
<p id="section-8.17-1">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.<a href="#section-8.17-1" class="pilcrow">¶</a></p>
<p id="section-8.17-2">Expert Reviewers should take into consideration the following points:<a href="#section-8.17-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.17-3.1">Point squatting should be discouraged.  Reviewers are encouraged
      to get sufficient information for registration requests to ensure
      that the usage is not going to duplicate one that is already
      registered and that the point is likely to be used in deployments.  The
      zones tagged as Private Use are intended for testing purposes and closed
      environments; code points in other ranges should not be assigned for
      testing.<a href="#section-8.17-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.17-3.2">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.<a href="#section-8.17-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.17-3.3">Experts should take into account the expected usage of fields when
      approving point assignment.  The fact that there is a range for
      Standards Track documents does not mean that a Standards Track
      document cannot have points assigned outside of that range.  The
      length of the encoded value should be weighed against how many
      code points of that length are left, i.e., the size of device it will be
      used on.<a href="#section-8.17-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.17-3.4">Since a high degree of overlap is expected between these registries
      and the contents of the OAuth parameters <span>[<a href="#IANA.OAuthParameters" class="xref">IANA.OAuthParameters</a>]</span> registries, experts should require new
      registrations to maintain alignment with parameters from OAuth that have
      comparable functionality.  Deviation from this alignment should only
      be allowed if there are functional differences that are motivated by
      the use case and that cannot be easily or efficiently addressed by
      comparable OAuth parameters.<a href="#section-8.17-3.4" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="IANA.CborWebTokenClaims">[IANA.CborWebTokenClaims]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"CBOR Web Token (CWT) Claims"</span>, <span>&lt;<a href="https://www.iana.org/assignments/cwt">https://www.iana.org/assignments/cwt</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA.CoreParameters">[IANA.CoreParameters]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Constrained RESTful Environments (CoRE) Parameters"</span>, <span>&lt;<a href="https://www.iana.org/assignments/core-parameters">https://www.iana.org/assignments/core-parameters</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA.JsonWebTokenClaims">[IANA.JsonWebTokenClaims]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"JSON Web Token Claims"</span>, <span>&lt;<a href="https://www.iana.org/assignments/jwt">https://www.iana.org/assignments/jwt</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA.OAuthAccessTokenTypes">[IANA.OAuthAccessTokenTypes]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"OAuth Access Token Types"</span>, <span>&lt;<a href="https://www.iana.org/assignments/oauth-parameters">https://www.iana.org/assignments/oauth-parameters</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA.OAuthExtensionsErrorRegistry">[IANA.OAuthExtensionsErrorRegistry]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"OAuth Extensions Error Registry"</span>, <span>&lt;<a href="https://www.iana.org/assignments/oauth-parameters">https://www.iana.org/assignments/oauth-parameters</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA.OAuthParameters">[IANA.OAuthParameters]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"OAuth Parameters"</span>, <span>&lt;<a href="https://www.iana.org/assignments/oauth-parameters">https://www.iana.org/assignments/oauth-parameters</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA.TokenIntrospectionResponse">[IANA.TokenIntrospectionResponse]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"OAuth Token Introspection Response"</span>, <span>&lt;<a href="https://www.iana.org/assignments/oauth-parameters">https://www.iana.org/assignments/oauth-parameters</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3986">[RFC3986]</dt>
        <dd>
<span class="refAuthor">Berners-Lee, T.</span>, <span class="refAuthor">Fielding, R.</span>, and <span class="refAuthor">L. Masinter</span>, <span class="refTitle">"Uniform Resource Identifier (URI): Generic Syntax"</span>, <span class="seriesInfo">STD 66</span>, <span class="seriesInfo">RFC 3986</span>, <span class="seriesInfo">DOI 10.17487/RFC3986</span>, <time datetime="2005-01" class="refDate">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3986">https://www.rfc-editor.org/info/rfc3986</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4648">[RFC4648]</dt>
        <dd>
<span class="refAuthor">Josefsson, S.</span>, <span class="refTitle">"The Base16, Base32, and Base64 Data Encodings"</span>, <span class="seriesInfo">RFC 4648</span>, <span class="seriesInfo">DOI 10.17487/RFC4648</span>, <time datetime="2006-10" class="refDate">October 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4648">https://www.rfc-editor.org/info/rfc4648</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6347">[RFC6347]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span> and <span class="refAuthor">N. Modadugu</span>, <span class="refTitle">"Datagram Transport Layer Security Version 1.2"</span>, <span class="seriesInfo">RFC 6347</span>, <span class="seriesInfo">DOI 10.17487/RFC6347</span>, <time datetime="2012-01" class="refDate">January 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6347">https://www.rfc-editor.org/info/rfc6347</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6749">[RFC6749]</dt>
        <dd>
<span class="refAuthor">Hardt, D., Ed.</span>, <span class="refTitle">"The OAuth 2.0 Authorization Framework"</span>, <span class="seriesInfo">RFC 6749</span>, <span class="seriesInfo">DOI 10.17487/RFC6749</span>, <time datetime="2012-10" class="refDate">October 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6749">https://www.rfc-editor.org/info/rfc6749</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6750">[RFC6750]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span> and <span class="refAuthor">D. Hardt</span>, <span class="refTitle">"The OAuth 2.0 Authorization Framework: Bearer Token Usage"</span>, <span class="seriesInfo">RFC 6750</span>, <span class="seriesInfo">DOI 10.17487/RFC6750</span>, <time datetime="2012-10" class="refDate">October 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6750">https://www.rfc-editor.org/info/rfc6750</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6838">[RFC6838]</dt>
        <dd>
<span class="refAuthor">Freed, N.</span>, <span class="refAuthor">Klensin, J.</span>, and <span class="refAuthor">T. Hansen</span>, <span class="refTitle">"Media Type Specifications and Registration Procedures"</span>, <span class="seriesInfo">BCP 13</span>, <span class="seriesInfo">RFC 6838</span>, <span class="seriesInfo">DOI 10.17487/RFC6838</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6838">https://www.rfc-editor.org/info/rfc6838</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6920">[RFC6920]</dt>
        <dd>
<span class="refAuthor">Farrell, S.</span>, <span class="refAuthor">Kutscher, D.</span>, <span class="refAuthor">Dannewitz, C.</span>, <span class="refAuthor">Ohlman, B.</span>, <span class="refAuthor">Keranen, A.</span>, and <span class="refAuthor">P. Hallam-Baker</span>, <span class="refTitle">"Naming Things with Hashes"</span>, <span class="seriesInfo">RFC 6920</span>, <span class="seriesInfo">DOI 10.17487/RFC6920</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6920">https://www.rfc-editor.org/info/rfc6920</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7252">[RFC7252]</dt>
        <dd>
<span class="refAuthor">Shelby, Z.</span>, <span class="refAuthor">Hartke, K.</span>, and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"The Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 7252</span>, <span class="seriesInfo">DOI 10.17487/RFC7252</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7252">https://www.rfc-editor.org/info/rfc7252</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7519">[RFC7519]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">N. Sakimura</span>, <span class="refTitle">"JSON Web Token (JWT)"</span>, <span class="seriesInfo">RFC 7519</span>, <span class="seriesInfo">DOI 10.17487/RFC7519</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7519">https://www.rfc-editor.org/info/rfc7519</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7662">[RFC7662]</dt>
        <dd>
<span class="refAuthor">Richer, J., Ed.</span>, <span class="refTitle">"OAuth 2.0 Token Introspection"</span>, <span class="seriesInfo">RFC 7662</span>, <span class="seriesInfo">DOI 10.17487/RFC7662</span>, <time datetime="2015-10" class="refDate">October 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7662">https://www.rfc-editor.org/info/rfc7662</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8152">[RFC8152]</dt>
        <dd>
<span class="refAuthor">Schaad, J.</span>, <span class="refTitle">"CBOR Object Signing and Encryption (COSE)"</span>, <span class="seriesInfo">RFC 8152</span>, <span class="seriesInfo">DOI 10.17487/RFC8152</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8152">https://www.rfc-editor.org/info/rfc8152</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8392">[RFC8392]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Wahlstroem, E.</span>, <span class="refAuthor">Erdtman, S.</span>, and <span class="refAuthor">H. Tschofenig</span>, <span class="refTitle">"CBOR Web Token (CWT)"</span>, <span class="seriesInfo">RFC 8392</span>, <span class="seriesInfo">DOI 10.17487/RFC8392</span>, <time datetime="2018-05" class="refDate">May 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8392">https://www.rfc-editor.org/info/rfc8392</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8610">[RFC8610]</dt>
        <dd>
<span class="refAuthor">Birkholz, H.</span>, <span class="refAuthor">Vigano, C.</span>, and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures"</span>, <span class="seriesInfo">RFC 8610</span>, <span class="seriesInfo">DOI 10.17487/RFC8610</span>, <time datetime="2019-06" class="refDate">June 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8610">https://www.rfc-editor.org/info/rfc8610</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8693">[RFC8693]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Nadalin, A.</span>, <span class="refAuthor">Campbell, B., Ed.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">C. Mortimore</span>, <span class="refTitle">"OAuth 2.0 Token Exchange"</span>, <span class="seriesInfo">RFC 8693</span>, <span class="seriesInfo">DOI 10.17487/RFC8693</span>, <time datetime="2020-01" class="refDate">January 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8693">https://www.rfc-editor.org/info/rfc8693</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8747">[RFC8747]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Seitz, L.</span>, <span class="refAuthor">Selander, G.</span>, <span class="refAuthor">Erdtman, S.</span>, and <span class="refAuthor">H. Tschofenig</span>, <span class="refTitle">"Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)"</span>, <span class="seriesInfo">RFC 8747</span>, <span class="seriesInfo">DOI 10.17487/RFC8747</span>, <time datetime="2020-03" class="refDate">March 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8747">https://www.rfc-editor.org/info/rfc8747</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8949">[RFC8949]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span> and <span class="refAuthor">P. Hoffman</span>, <span class="refTitle">"Concise Binary Object Representation (CBOR)"</span>, <span class="seriesInfo">STD 94</span>, <span class="seriesInfo">RFC 8949</span>, <span class="seriesInfo">DOI 10.17487/RFC8949</span>, <time datetime="2020-12" class="refDate">December 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8949">https://www.rfc-editor.org/info/rfc8949</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9201">[RFC9201]</dt>
      <dd>
<span class="refAuthor">Seitz, L.</span>, <span class="refTitle">"Additional OAuth Parameters for Authentication and Authorization in Constrained Environments (ACE)"</span>, <span class="seriesInfo">RFC 9201</span>, <span class="seriesInfo">DOI 10.17487/RFC9201</span>, <time datetime="2022-08" class="refDate">August 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9201">https://www.rfc-editor.org/info/rfc9201</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="BLE">[BLE]</dt>
        <dd>
<span class="refAuthor">Bluetooth Special Interest Group</span>, <span class="refTitle">"Core Specification 5.3"</span>, <span class="seriesInfo">Section 4.4</span>, <time datetime="2021-07" class="refDate">July 2021</time>, <span>&lt;<a href="https://www.bluetooth.com/specifications/bluetooth-core-specification/">https://www.bluetooth.com/specifications/bluetooth-core-specification/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.gerdes-ace-dcaf-authorize">[DCAF]</dt>
        <dd>
<span class="refAuthor">Gerdes, S.</span>, <span class="refAuthor">Bergmann, O.</span>, and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"Delegated CoAP Authentication and Authorization Framework (DCAF)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-gerdes-ace-dcaf-authorize-04</span>, <time datetime="2015-10-19" class="refDate">19 October 2015</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-gerdes-ace-dcaf-authorize-04">https://datatracker.ietf.org/doc/html/draft-gerdes-ace-dcaf-authorize-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Margi10impact">[Margi10impact]</dt>
        <dd>
<span class="refAuthor">Margi, C.</span>, <span class="refAuthor">de Oliveira, B.</span>, <span class="refAuthor">de Sousa, G.</span>, <span class="refAuthor">Simplicio Jr, M.</span>, <span class="refAuthor">Barreto, P.</span>, <span class="refAuthor">Carvalho, T.</span>, <span class="refAuthor">Naeslund, M.</span>, and <span class="refAuthor">R. Gold</span>, <span class="refTitle">"Impact of Operating Systems on Wireless Sensor Networks (Security) Applications and Testbeds"</span>, <span class="refContent">Proceedings of the 19th International Conference on Computer
   Communications and Networks</span>, <span class="seriesInfo">DOI 10.1109/ICCCN.2010.5560028</span>, <time datetime="2010-08" class="refDate">August 2010</time>, <span>&lt;<a href="https://doi.org/10.1109/ICCCN.2010.5560028">https://doi.org/10.1109/ICCCN.2010.5560028</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="MQTT5.0">[MQTT5.0]</dt>
        <dd>
<span class="refAuthor">Banks, A.</span>, <span class="refAuthor">Briggs, E.</span>, <span class="refAuthor">Borgendale, K.</span>, and <span class="refAuthor">R. Gupta</span>, <span class="refTitle">"MQTT Version 5.0"</span>, <span class="refContent">OASIS Standard</span>, <time datetime="2019-03" class="refDate">March 2019</time>, <span>&lt;<a href="https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html">https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.erdtman-oauth-rpcc">[OAUTH-RPCC]</dt>
        <dd>
<span class="refAuthor">Seitz, L.</span>, <span class="refAuthor">Erdtman, S.</span>, and <span class="refAuthor">M. Tiloca</span>, <span class="refTitle">"Raw-Public-Key and Pre-Shared-Key as OAuth client credentials"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-erdtman-oauth-rpcc-00</span>, <time datetime="2017-11-21" class="refDate">21 November 2017</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-erdtman-oauth-rpcc-00">https://datatracker.ietf.org/doc/html/draft-erdtman-oauth-rpcc-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-oauth-pop-key-distribution">[POP-KEY-DIST]</dt>
        <dd>
<span class="refAuthor">Bradley, J.</span>, <span class="refAuthor">Hunt, P.</span>, <span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Tschofenig, H.</span>, and <span class="refAuthor">M. Meszaros</span>, <span class="refTitle">"OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-oauth-pop-key-distribution-07</span>, <time datetime="2019-03-27" class="refDate">27 March 2019</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-key-distribution-07">https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-key-distribution-07</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4949">[RFC4949]</dt>
        <dd>
<span class="refAuthor">Shirey, R.</span>, <span class="refTitle">"Internet Security Glossary, Version 2"</span>, <span class="seriesInfo">FYI 36</span>, <span class="seriesInfo">RFC 4949</span>, <span class="seriesInfo">DOI 10.17487/RFC4949</span>, <time datetime="2007-08" class="refDate">August 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4949">https://www.rfc-editor.org/info/rfc4949</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6690">[RFC6690]</dt>
        <dd>
<span class="refAuthor">Shelby, Z.</span>, <span class="refTitle">"Constrained RESTful Environments (CoRE) Link Format"</span>, <span class="seriesInfo">RFC 6690</span>, <span class="seriesInfo">DOI 10.17487/RFC6690</span>, <time datetime="2012-08" class="refDate">August 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6690">https://www.rfc-editor.org/info/rfc6690</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6819">[RFC6819]</dt>
        <dd>
<span class="refAuthor">Lodderstedt, T., Ed.</span>, <span class="refAuthor">McGloin, M.</span>, and <span class="refAuthor">P. Hunt</span>, <span class="refTitle">"OAuth 2.0 Threat Model and Security Considerations"</span>, <span class="seriesInfo">RFC 6819</span>, <span class="seriesInfo">DOI 10.17487/RFC6819</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6819">https://www.rfc-editor.org/info/rfc6819</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7009">[RFC7009]</dt>
        <dd>
<span class="refAuthor">Lodderstedt, T., Ed.</span>, <span class="refAuthor">Dronia, S.</span>, and <span class="refAuthor">M. Scurtescu</span>, <span class="refTitle">"OAuth 2.0 Token Revocation"</span>, <span class="seriesInfo">RFC 7009</span>, <span class="seriesInfo">DOI 10.17487/RFC7009</span>, <time datetime="2013-08" class="refDate">August 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7009">https://www.rfc-editor.org/info/rfc7009</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7228">[RFC7228]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span>, <span class="refAuthor">Ersue, M.</span>, and <span class="refAuthor">A. Keranen</span>, <span class="refTitle">"Terminology for Constrained-Node Networks"</span>, <span class="seriesInfo">RFC 7228</span>, <span class="seriesInfo">DOI 10.17487/RFC7228</span>, <time datetime="2014-05" class="refDate">May 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7228">https://www.rfc-editor.org/info/rfc7228</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7521">[RFC7521]</dt>
        <dd>
<span class="refAuthor">Campbell, B.</span>, <span class="refAuthor">Mortimore, C.</span>, <span class="refAuthor">Jones, M.</span>, and <span class="refAuthor">Y. Goland</span>, <span class="refTitle">"Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants"</span>, <span class="seriesInfo">RFC 7521</span>, <span class="seriesInfo">DOI 10.17487/RFC7521</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7521">https://www.rfc-editor.org/info/rfc7521</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7591">[RFC7591]</dt>
        <dd>
<span class="refAuthor">Richer, J., Ed.</span>, <span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Bradley, J.</span>, <span class="refAuthor">Machulak, M.</span>, and <span class="refAuthor">P. Hunt</span>, <span class="refTitle">"OAuth 2.0 Dynamic Client Registration Protocol"</span>, <span class="seriesInfo">RFC 7591</span>, <span class="seriesInfo">DOI 10.17487/RFC7591</span>, <time datetime="2015-07" class="refDate">July 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7591">https://www.rfc-editor.org/info/rfc7591</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7641">[RFC7641]</dt>
        <dd>
<span class="refAuthor">Hartke, K.</span>, <span class="refTitle">"Observing Resources in the Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 7641</span>, <span class="seriesInfo">DOI 10.17487/RFC7641</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7641">https://www.rfc-editor.org/info/rfc7641</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7744">[RFC7744]</dt>
        <dd>
<span class="refAuthor">Seitz, L., Ed.</span>, <span class="refAuthor">Gerdes, S., Ed.</span>, <span class="refAuthor">Selander, G.</span>, <span class="refAuthor">Mani, M.</span>, and <span class="refAuthor">S. Kumar</span>, <span class="refTitle">"Use Cases for Authentication and Authorization in Constrained Environments"</span>, <span class="seriesInfo">RFC 7744</span>, <span class="seriesInfo">DOI 10.17487/RFC7744</span>, <time datetime="2016-01" class="refDate">January 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7744">https://www.rfc-editor.org/info/rfc7744</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7959">[RFC7959]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span> and <span class="refAuthor">Z. Shelby, Ed.</span>, <span class="refTitle">"Block-Wise Transfers in the Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 7959</span>, <span class="seriesInfo">DOI 10.17487/RFC7959</span>, <time datetime="2016-08" class="refDate">August 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7959">https://www.rfc-editor.org/info/rfc7959</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8252">[RFC8252]</dt>
        <dd>
<span class="refAuthor">Denniss, W.</span> and <span class="refAuthor">J. Bradley</span>, <span class="refTitle">"OAuth 2.0 for Native Apps"</span>, <span class="seriesInfo">BCP 212</span>, <span class="seriesInfo">RFC 8252</span>, <span class="seriesInfo">DOI 10.17487/RFC8252</span>, <time datetime="2017-10" class="refDate">October 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8252">https://www.rfc-editor.org/info/rfc8252</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8259">[RFC8259]</dt>
        <dd>
<span class="refAuthor">Bray, T., Ed.</span>, <span class="refTitle">"The JavaScript Object Notation (JSON) Data Interchange Format"</span>, <span class="seriesInfo">STD 90</span>, <span class="seriesInfo">RFC 8259</span>, <span class="seriesInfo">DOI 10.17487/RFC8259</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8259">https://www.rfc-editor.org/info/rfc8259</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8414">[RFC8414]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Sakimura, N.</span>, and <span class="refAuthor">J. Bradley</span>, <span class="refTitle">"OAuth 2.0 Authorization Server Metadata"</span>, <span class="seriesInfo">RFC 8414</span>, <span class="seriesInfo">DOI 10.17487/RFC8414</span>, <time datetime="2018-06" class="refDate">June 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8414">https://www.rfc-editor.org/info/rfc8414</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[RFC8446]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8516">[RFC8516]</dt>
        <dd>
<span class="refAuthor">Keranen, A.</span>, <span class="refTitle">""Too Many Requests" Response Code for the Constrained Application Protocol"</span>, <span class="seriesInfo">RFC 8516</span>, <span class="seriesInfo">DOI 10.17487/RFC8516</span>, <time datetime="2019-01" class="refDate">January 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8516">https://www.rfc-editor.org/info/rfc8516</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8613">[RFC8613]</dt>
        <dd>
<span class="refAuthor">Selander, G.</span>, <span class="refAuthor">Mattsson, J.</span>, <span class="refAuthor">Palombini, F.</span>, and <span class="refAuthor">L. Seitz</span>, <span class="refTitle">"Object Security for Constrained RESTful Environments (OSCORE)"</span>, <span class="seriesInfo">RFC 8613</span>, <span class="seriesInfo">DOI 10.17487/RFC8613</span>, <time datetime="2019-07" class="refDate">July 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8613">https://www.rfc-editor.org/info/rfc8613</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8628">[RFC8628]</dt>
        <dd>
<span class="refAuthor">Denniss, W.</span>, <span class="refAuthor">Bradley, J.</span>, <span class="refAuthor">Jones, M.</span>, and <span class="refAuthor">H. Tschofenig</span>, <span class="refTitle">"OAuth 2.0 Device Authorization Grant"</span>, <span class="seriesInfo">RFC 8628</span>, <span class="seriesInfo">DOI 10.17487/RFC8628</span>, <time datetime="2019-08" class="refDate">August 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8628">https://www.rfc-editor.org/info/rfc8628</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9000">[RFC9000]</dt>
        <dd>
<span class="refAuthor">Iyengar, J., Ed.</span> and <span class="refAuthor">M. Thomson, Ed.</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="seriesInfo">RFC 9000</span>, <span class="seriesInfo">DOI 10.17487/RFC9000</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9000">https://www.rfc-editor.org/info/rfc9000</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9110">[RFC9110]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span>, <span class="refAuthor">Nottingham, M., Ed.</span>, and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"HTTP Semantics"</span>, <span class="seriesInfo">STD 97</span>, <span class="seriesInfo">RFC 9110</span>, <span class="seriesInfo">DOI 10.17487/RFC9110</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9110">https://www.rfc-editor.org/info/rfc9110</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9113">[RFC9113]</dt>
        <dd>
<span class="refAuthor">Thomson, M., Ed.</span> and <span class="refAuthor">C. Benfield, Ed.</span>, <span class="refTitle">"HTTP/2"</span>, <span class="seriesInfo">RFC 9113</span>, <span class="seriesInfo">DOI 10.17487/RFC9113</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9113">https://www.rfc-editor.org/info/rfc9113</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9147">[RFC9147]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refAuthor">Tschofenig, H.</span>, and <span class="refAuthor">N. Modadugu</span>, <span class="refTitle">"The Datagram Transport Layer Security (DTLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 9147</span>, <span class="seriesInfo">DOI 10.17487/RFC9147</span>, <time datetime="2022-04" class="refDate">April 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9147">https://www.rfc-editor.org/info/rfc9147</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9202">[RFC9202]</dt>
        <dd>
<span class="refAuthor">Gerdes, S.</span>, <span class="refAuthor">Bergmann, O.</span>, <span class="refAuthor">Bormann, C.</span>, <span class="refAuthor">Selander, G.</span>, and <span class="refAuthor">L. Seitz</span>, <span class="refTitle">"Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)"</span>, <span class="seriesInfo">RFC 9202</span>, <span class="seriesInfo">DOI 10.17487/RFC9202</span>, <time datetime="2022-08" class="refDate">August 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9202">https://www.rfc-editor.org/info/rfc9202</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9203">[RFC9203]</dt>
      <dd>
<span class="refAuthor">Palombini, F.</span>, <span class="refAuthor">Seitz, L.</span>, <span class="refAuthor">Selander, G.</span>, and <span class="refAuthor">M. Gunnarsson</span>, <span class="refTitle">"The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework"</span>, <span class="seriesInfo">RFC 9203</span>, <span class="seriesInfo">DOI 10.17487/RFC9203</span>, <time datetime="2022-08" class="refDate">August 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9203">https://www.rfc-editor.org/info/rfc9203</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="constraints">
<section id="appendix-A">
      <h2 id="name-design-justification">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-design-justification" class="section-name selfRef">Design Justification</a>
      </h2>
<p id="appendix-A-1">This section provides further insight into the design decisions
     of the solution documented in this document.  <a href="#overview" class="xref">Section 3</a>
     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.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">Common IoT constraints are:<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="appendix-A-3">
        <dt id="appendix-A-3.1">Low Power Radio:</dt>
        <dd style="margin-left: 1.5em" id="appendix-A-3.2">
          Many IoT devices are equipped with a small battery that needs
          to last for a long time.  For many constrained wireless devices, the
          highest energy cost is associated to transmitting or receiving
          messages (roughly by a factor of 10 compared to AES)
   <span>[<a href="#Margi10impact" class="xref">Margi10impact</a>]</span>.  It is therefore important
   to keep
   the total communication overhead low, including minimizing the number
   and size of messages sent and received, which has an impact of choice
   on the message format and protocol.  By using CoAP over UDP and 
   CBOR-encoded messages, some of these aspects are addressed.  Security
   protocols contribute to the communication overhead and can, in some
   cases, be optimized.  For example, authentication and key
   establishment may, in certain cases where security requirements
   allow, be replaced by the provisioning of security context by a trusted
   third party, using transport or application-layer security.<a href="#appendix-A-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-A-3.3">Low CPU Speed:</dt>
        <dd style="margin-left: 1.5em" id="appendix-A-3.4">
          Some IoT devices are equipped with processors that are significantly
          slower than those found in most current devices on the Internet.
          This typically has implications on what timely cryptographic
          operations a device is capable of performing, which in turn impacts,
          e.g., protocol latency.  Symmetric key cryptography may be used
          instead of the computationally more expensive public key cryptography
          where the security requirements so allow, but this may also require
          support for trusted, third-party-assisted secret key establishment
          using transport- or application-layer security.<a href="#appendix-A-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-A-3.5">Small Amount of Memory:</dt>
        <dd style="margin-left: 1.5em" id="appendix-A-3.6">
          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
          an impact on memory and code footprints.<a href="#appendix-A-3.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-A-3.7">User Interface Limitations:</dt>
        <dd style="margin-left: 1.5em" id="appendix-A-3.8">
          Protecting access to resources is both an important security as well
          as privacy feature.  End users and enterprise customers may not want
          to give access to the data collected by their IoT device or to
          functions it may offer to third parties.  Since the classical
          approach of requesting permissions from end users via a rich user
          interface does not work in many IoT deployment scenarios, these
          functions need to be delegated to user-controlled devices that are
          better suitable for such tasks, such as smartphones and tablets.<a href="#appendix-A-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-A-3.9">Communication Constraints:</dt>
        <dd style="margin-left: 1.5em" id="appendix-A-3.10">
          <p id="appendix-A-3.10.1">
          In certain constrained settings, an IoT device may not be able to
          communicate with a given device at all times.  Devices may be
          sleeping or just disconnected from the Internet because of general
          lack of connectivity in the area, cost reasons, or security
          reasons, e.g., to avoid an entry point for denial-of-service attacks.<a href="#appendix-A-3.10.1" class="pilcrow">¶</a></p>
<p id="appendix-A-3.10.2">
          The communication interactions this framework builds upon (as shown
          graphically in <a href="#fig_protocolFlow" class="xref">Figure 1</a>) may be
   accomplished
          using a variety of different protocols, and not all parts of the
          message flow are used in all applications due to the communication
          constraints.  Deployments making use of CoAP are expected, but this
   framework is not
          limited to them.  Other protocols, such as HTTP or
          Bluetooth Smart communication, that do not
          necessarily use IP could also be used.  The latter raises the need
          for application-layer security over the various interfaces.<a href="#appendix-A-3.10.2" class="pilcrow">¶</a></p>
</dd>
      <dd class="break"></dd>
</dl>
<p id="appendix-A-4">In the light of these constraints, we have made the following design
      decisions:<a href="#appendix-A-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="appendix-A-5">
        <dt id="appendix-A-5.1">CBOR, COSE, CWT:</dt>
        <dd style="margin-left: 1.5em" id="appendix-A-5.2">
   When using this framework, it is <span class="bcp14">RECOMMENDED</span> to use CBOR 
   <span>[<a href="#RFC8949" class="xref">RFC8949</a>]</span> as the data format.  Where CBOR data
   needs to be
   protected, the use of COSE <span>[<a href="#RFC8152" class="xref">RFC8152</a>]</span> is
   <span class="bcp14">RECOMMENDED</span>. 
   Furthermore, where self-contained tokens are needed, it is
   <span class="bcp14">RECOMMENDED</span>
   to use CWT <span>[<a href="#RFC8392" class="xref">RFC8392</a>]</span>.  These measures aim
   at reducing
   the size of messages sent over the wire, the RAM size of data objects
   that need to be kept in memory, and the size of libraries that devices
   need to support.<a href="#appendix-A-5.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-A-5.3">CoAP:</dt>
        <dd style="margin-left: 1.5em" id="appendix-A-5.4">
   When using this framework, it is <span class="bcp14">RECOMMENDED</span> to use CoAP 
   <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> instead of HTTP.  This does not
   preclude the
   use of other protocols specifically aimed at constrained devices,
   e.g., Bluetooth Low Energy (see <a href="#coap" class="xref">Section 3.2</a>). 
   This aims
   again at reducing the size of messages sent over the wire, the RAM size
   of data objects that need to be kept in memory, and the size of 
   libraries that devices need to support.<a href="#appendix-A-5.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-A-5.5">Access Information:</dt>
        <dd style="margin-left: 1.5em" id="appendix-A-5.6">
   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  <a href="#tokenResponse" class="xref">Section 5.8.2</a>).  This
   aims at
   enabling scenarios where a powerful client supporting multiple
   profiles needs to interact with an RS for which it does not know the
   supported profiles and the raw public key.<a href="#appendix-A-5.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-A-5.7">Proof of Possession:</dt>
        <dd style="margin-left: 1.5em" id="appendix-A-5.8">
   This framework makes use of proof-of-possession tokens, using
   the <code>cnf</code> claim <span>[<a href="#RFC8747" class="xref">RFC8747</a>]</span>.  A request
   parameter <code>cnf</code> and a Response parameter <code>cnf</code>, both having a
   value space semantically and syntactically identical to the <code>cnf</code>
   claim, are defined for the token endpoint to allow requesting and
   stating confirmation keys.  This aims at making token theft harder.
   Token theft is specifically relevant in constrained use cases, as
   communication often passes through middleboxes, which could be able
   to steal bearer tokens and use them to gain unauthorized access.<a href="#appendix-A-5.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-A-5.9">Authz-Info endpoint:</dt>
        <dd style="margin-left: 1.5em" id="appendix-A-5.10">
   This framework introduces a new way of providing access tokens
   to an RS by exposing an authz-info endpoint to which access tokens
   can be POSTed.  This aims at reducing the size of the request
   message and the code complexity at the RS.  The size of the request
   message is problematic, since many constrained protocols have severe
   message size limitations at the physical layer (e.g., in the order of
   100 bytes). This means that larger packets get fragmented, which in
   turn combines badly with the high rate of packet loss and the
   need to retransmit the whole message if one packet gets lost.
   Thus, separating sending of the request and sending of the access
   tokens helps to reduce fragmentation.<a href="#appendix-A-5.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-A-5.11">Client Credentials Grant:</dt>
        <dd style="margin-left: 1.5em" id="appendix-A-5.12">
   In this framework, the use of the client credentials grant is
   <span class="bcp14">RECOMMENDED</span> for machine-to-machine communication use cases,
   where 
   manual intervention of the resource owner to produce a grant token is
   not feasible.  The intention is that the resource owner would instead
   prearrange authorization with the AS based on the client's own
   credentials.  The client can then (without manual intervention) obtain
   access tokens from the AS.<a href="#appendix-A-5.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-A-5.13">Introspection:</dt>
        <dd style="margin-left: 1.5em" id="appendix-A-5.14">
   In this framework, the use of access token introspection is
   <span class="bcp14">RECOMMENDED</span>
   in cases where the client is constrained in a way that it cannot
   easily obtain new access tokens (i.e., it has connectivity issues
   that prevent it from communicating with the AS). In that case,
   it is <span class="bcp14">RECOMMENDED</span> to use a long-term token that could be a
   simple reference.  The RS is assumed to be able to communicate
   with the AS and can therefore perform introspection in order to
   learn the claims associated with the token reference.  The advantage
   of such an approach is that the resource owner can change the claims
   associated to the token reference without having to be in contact
   with the client, thus granting or revoking access rights.<a href="#appendix-A-5.14" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="app_rolesAndResponsibilities">
<section id="appendix-B">
      <h2 id="name-roles-and-responsibilities">
<a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-roles-and-responsibilities" class="section-name selfRef">Roles and Responsibilities</a>
      </h2>
<span class="break"></span><dl class="dlNewline" id="appendix-B-1">
        <dt id="appendix-B-1.1">Resource Owner</dt>
        <dd style="margin-left: 1.5em" id="appendix-B-1.2">
          <ul class="normal">
<li class="normal" id="appendix-B-1.2.1.1">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.<a href="#appendix-B-1.2.1.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.2.1.2">Make sure that clients can discover the AS that is in charge
     of the RS.<a href="#appendix-B-1.2.1.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.2.1.3">If the client-credentials grant is used, make sure that the AS
     has the necessary, up-to-date access control policies for the
     RS.<a href="#appendix-B-1.2.1.3" class="pilcrow">¶</a>
</li>
          </ul>
</dd>
        <dd class="break"></dd>
<dt id="appendix-B-1.3">Requesting Party</dt>
        <dd style="margin-left: 1.5em" id="appendix-B-1.4">
          <ul class="normal">
<li class="normal" id="appendix-B-1.4.1.1">Make sure that the client is provisioned the necessary
     credentials to authenticate to the AS.<a href="#appendix-B-1.4.1.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.4.1.2">Make sure that the client is configured to follow the security
     requirements of the requesting party when issuing requests
     (e.g., minimum communication security requirements or trust
     anchors).<a href="#appendix-B-1.4.1.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.4.1.3">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.<a href="#appendix-B-1.4.1.3" class="pilcrow">¶</a>
</li>
          </ul>
</dd>
        <dd class="break"></dd>
<dt id="appendix-B-1.5">Authorization Server</dt>
        <dd style="margin-left: 1.5em" id="appendix-B-1.6">
          <ul class="normal">
<li class="normal" id="appendix-B-1.6.1.1">Register the RS and manage corresponding security contexts.<a href="#appendix-B-1.6.1.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.6.1.2">Register clients and authentication credentials.<a href="#appendix-B-1.6.1.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.6.1.3">Allow resource owners to configure and update access control
     policies related to their registered RSs.<a href="#appendix-B-1.6.1.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.6.1.4">Expose the token endpoint to allow  clients to request
     tokens.<a href="#appendix-B-1.6.1.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.6.1.5">Authenticate clients that wish to request a token.<a href="#appendix-B-1.6.1.5" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.6.1.6">Process a token request using the authorization
     policies configured for the RS.<a href="#appendix-B-1.6.1.6" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.6.1.7">Optionally, expose the introspection endpoint that allows
     RSs to submit token introspection requests.<a href="#appendix-B-1.6.1.7" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.6.1.8">If providing an introspection endpoint, authenticate RSs that
     wish to get an introspection response.<a href="#appendix-B-1.6.1.8" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.6.1.9">If providing an introspection endpoint, process token
     introspection requests.<a href="#appendix-B-1.6.1.9" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.6.1.10">Optionally, handle token revocation.<a href="#appendix-B-1.6.1.10" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.6.1.11">Optionally, provide discovery metadata. See <span>[<a href="#RFC8414" class="xref">RFC8414</a>]</span>.<a href="#appendix-B-1.6.1.11" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.6.1.12">Optionally, handle refresh tokens.<a href="#appendix-B-1.6.1.12" class="pilcrow">¶</a>
</li>
          </ul>
</dd>
        <dd class="break"></dd>
<dt id="appendix-B-1.7">Client</dt>
        <dd style="margin-left: 1.5em" id="appendix-B-1.8">
          <ul class="normal">
<li class="normal" id="appendix-B-1.8.1.1">Discover the AS in charge of the RS that is to be targeted with
     a request.<a href="#appendix-B-1.8.1.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.8.1.2">
              <p id="appendix-B-1.8.1.2.1">Submit the token request (see step (A) of
     <a href="#fig_protocolFlow" class="xref">Figure 1</a>).<a href="#appendix-B-1.8.1.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-B-1.8.1.2.2.1">Authenticate to the AS.<a href="#appendix-B-1.8.1.2.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-B-1.8.1.2.2.2">Optionally (if not preconfigured), specify which RS, which
 resource(s), and which action(s) the request(s) will
 target.<a href="#appendix-B-1.8.1.2.2.2" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-B-1.8.1.2.2.3">If raw public keys (RPKs) or certificates are used, make sure
 the AS has the right RPK or certificate for this client.<a href="#appendix-B-1.8.1.2.2.3" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li class="normal" id="appendix-B-1.8.1.3">
              <p id="appendix-B-1.8.1.3.1">Process the access token and Access Information (see step (B)
     of <a href="#fig_protocolFlow" class="xref">Figure 1</a>).<a href="#appendix-B-1.8.1.3.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-B-1.8.1.3.2.1">Check that the Access Information provides the necessary
 security parameters (e.g., PoP key or information on
 communication security protocols supported by the RS).<a href="#appendix-B-1.8.1.3.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-B-1.8.1.3.2.2">Safely store the proof-of-possession key.<a href="#appendix-B-1.8.1.3.2.2" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-B-1.8.1.3.2.3">If provided by the AS, safely store the refresh token.<a href="#appendix-B-1.8.1.3.2.3" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li class="normal" id="appendix-B-1.8.1.4">
              <p id="appendix-B-1.8.1.4.1">Send the token and request to the RS (see step (C) of
     <a href="#fig_protocolFlow" class="xref">Figure 1</a>).<a href="#appendix-B-1.8.1.4.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-B-1.8.1.4.2.1">Authenticate towards the RS (this could coincide with the
 proof-of-possession process).<a href="#appendix-B-1.8.1.4.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-B-1.8.1.4.2.2">Transmit the token as specified by the AS (default is to the
 authz-info endpoint; alternative options are specified by
 profiles).<a href="#appendix-B-1.8.1.4.2.2" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-B-1.8.1.4.2.3">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).<a href="#appendix-B-1.8.1.4.2.3" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li class="normal" id="appendix-B-1.8.1.5">Process the RS response (see step (F) of
     <a href="#fig_protocolFlow" class="xref">Figure 1</a>) of the RS.<a href="#appendix-B-1.8.1.5" class="pilcrow">¶</a>
</li>
          </ul>
</dd>
        <dd class="break"></dd>
<dt id="appendix-B-1.9">Resource Server</dt>
        <dd style="margin-left: 1.5em" id="appendix-B-1.10">
          <ul class="normal">
<li class="normal" id="appendix-B-1.10.1.1">Expose a way to submit access tokens. By default, this is
     the authz-info endpoint.<a href="#appendix-B-1.10.1.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.10.1.2">
              <p id="appendix-B-1.10.1.2.1">Process an access token.<a href="#appendix-B-1.10.1.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-B-1.10.1.2.2.1">Verify the token is from a recognized AS.<a href="#appendix-B-1.10.1.2.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-B-1.10.1.2.2.2">Check the token's integrity.<a href="#appendix-B-1.10.1.2.2.2" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-B-1.10.1.2.2.3">Verify that the token applies to this RS.<a href="#appendix-B-1.10.1.2.2.3" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-B-1.10.1.2.2.4">Check that the token has not expired (if the token provides
 expiration information).<a href="#appendix-B-1.10.1.2.2.4" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-B-1.10.1.2.2.5">Store the token so that it can be retrieved in the context
 of a matching request.<a href="#appendix-B-1.10.1.2.2.5" class="pilcrow">¶</a>
</li>
              </ul>
<p id="appendix-B-1.10.1.2.3">
       Note: The order proposed here is not normative; any process
       that arrives at an equivalent result can be used.  A noteworthy
       consideration is whether one can use cheap operations early on to
       quickly discard nonapplicable or invalid tokens before
       performing expensive cryptographic operations (e.g., doing an
       expiration check before verifying a signature).<a href="#appendix-B-1.10.1.2.3" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="appendix-B-1.10.1.3">
              <p id="appendix-B-1.10.1.3.1">Process a request.<a href="#appendix-B-1.10.1.3.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-B-1.10.1.3.2.1">Set up communication security with the client.<a href="#appendix-B-1.10.1.3.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-B-1.10.1.3.2.2">Authenticate the client.<a href="#appendix-B-1.10.1.3.2.2" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-B-1.10.1.3.2.3">Match the client against existing tokens.<a href="#appendix-B-1.10.1.3.2.3" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-B-1.10.1.3.2.4">Check that tokens belonging to the client actually
 authorize the requested action.<a href="#appendix-B-1.10.1.3.2.4" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-B-1.10.1.3.2.5">Optionally, check that the matching tokens are still valid,
 using introspection (if this is possible.)<a href="#appendix-B-1.10.1.3.2.5" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li class="normal" id="appendix-B-1.10.1.4">Send a response following the agreed upon communication
     security mechanism(s).<a href="#appendix-B-1.10.1.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B-1.10.1.5">Safely store credentials, such as raw public keys, for
     authentication or proof-of-possession keys linked to access
     tokens.<a href="#appendix-B-1.10.1.5" class="pilcrow">¶</a>
</li>
          </ul>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="app_profileRequirements">
<section id="appendix-C">
      <h2 id="name-requirements-on-profiles">
<a href="#appendix-C" class="section-number selfRef">Appendix C. </a><a href="#name-requirements-on-profiles" class="section-name selfRef">Requirements on Profiles</a>
      </h2>
<p id="appendix-C-1">This section lists the requirements on profiles of this framework
      for the convenience of profile designers.<a href="#appendix-C-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C-2.1">Optionally, define new methods for the client to discover the
 necessary permissions and AS for accessing a resource different from
 the one proposed in Sections <a href="#asDiscovery" class="xref">5.1</a> and <a href="#specs" class="xref">4</a><a href="#appendix-C-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.2">Optionally, specify new grant types
 (<a href="#authorizationGrants" class="xref">Section 5.4</a>).<a href="#appendix-C-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.3">Optionally, define the use of client certificates as client credential
 type (<a href="#clientCredentials" class="xref">Section 5.5</a>).<a href="#appendix-C-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.4">Specify the communication protocol the client and RS must use
 (e.g., CoAP) (Sections <a href="#oauthProfile" class="xref">5</a> and <a href="#paramProfile" class="xref">5.8.4.3</a>).<a href="#appendix-C-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.5">Specify the security protocol the client and RS must use to protect
 their communication (e.g., OSCORE or DTLS).  This must provide
 encryption and integrity and replay protection (<a href="#paramProfile" class="xref">Section 5.8.4.3</a>).<a href="#appendix-C-2.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.6">Specify how the client and the RS mutually authenticate (<a href="#specs" class="xref">Section 4</a>).<a href="#appendix-C-2.6" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.7">Specify the proof-of-possession protocol(s) and how to select one
 if several are available.  Also specify which key types
 (e.g., symmetric/asymmetric) are supported by a specific proof-of-possession
 protocol (<a href="#paramTokenType" class="xref">Section 5.8.4.2</a>).<a href="#appendix-C-2.7" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.8">Specify a unique <code>ace_profile</code> identifier (<a href="#paramProfile" class="xref">Section 5.8.4.3</a>).<a href="#appendix-C-2.8" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.9">If introspection is supported, specify the communication and security
 protocol for introspection (<a href="#introspectionEndpoint" class="xref">Section 5.9</a>).<a href="#appendix-C-2.9" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.10">Specify the communication and security protocol for interactions between
 the client and AS. This must provide encryption, integrity protection,
 replay protection,  and a binding between requests and responses (Sections <a href="#oauthProfile" class="xref">5</a> and <a href="#tokenEndpoint" class="xref">5.8</a>).<a href="#appendix-C-2.10" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.11">Specify how/if the authz-info endpoint is protected, including
 how error responses are protected (<a href="#tokenAuthInfoEndpoint" class="xref">Section 5.10.1</a>).<a href="#appendix-C-2.11" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.12">Optionally, define other methods of token transport than the authz-info
 endpoint (<a href="#tokenAuthInfoEndpoint" class="xref">Section 5.10.1</a>).<a href="#appendix-C-2.12" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="app_registration">
<section id="appendix-D">
      <h2 id="name-assumptions-on-as-knowledge">
<a href="#appendix-D" class="section-number selfRef">Appendix D. </a><a href="#name-assumptions-on-as-knowledge" class="section-name selfRef">Assumptions on AS Knowledge about the C and RS</a>
      </h2>
<p id="appendix-D-1">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.<a href="#appendix-D-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-D-2.1">The identifier of the client or RS.<a href="#appendix-D-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-D-2.2">The profiles that the client or RS supports.<a href="#appendix-D-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-D-2.3">The scopes that the RS supports.<a href="#appendix-D-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-D-2.4">The audiences that the RS identifies with.<a href="#appendix-D-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-D-2.5">The key types (e.g., pre-shared symmetric key, raw public key,
 key length, and other key parameters) that the client or RS supports.<a href="#appendix-D-2.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-D-2.6">The types of access tokens the RS supports (e.g., CWT).<a href="#appendix-D-2.6" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-D-2.7">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.<a href="#appendix-D-2.7" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-D-2.8">The expiration time for access tokens issued to this RS
 (unless the RS accepts a default time chosen by the AS).<a href="#appendix-D-2.8" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-D-2.9">The symmetric key shared between the client and AS (if any).<a href="#appendix-D-2.9" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-D-2.10">The symmetric key shared between the RS and AS (if any).<a href="#appendix-D-2.10" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-D-2.11">The raw public key of the client or RS (if any).<a href="#appendix-D-2.11" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-D-2.12">Whether the RS has synchronized time (and thus is able to use the <code>exp</code>
 claim) or not.<a href="#appendix-D-2.12" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="app_diffOAuth">
<section id="appendix-E">
      <h2 id="name-differences-to-oauth-20">
<a href="#appendix-E" class="section-number selfRef">Appendix E. </a><a href="#name-differences-to-oauth-20" class="section-name selfRef">Differences to OAuth 2.0</a>
      </h2>
<p id="appendix-E-1">This document adapts OAuth 2.0 to be suitable for constrained environments.  
      This section lists the main differences from the normative requirements of
      OAuth 2.0.<a href="#appendix-E-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="appendix-E-2">
        <dt id="appendix-E-2.1">Use of TLS</dt>
        <dd style="margin-left: 1.5em" id="appendix-E-2.2">OAuth 2.0 requires the use of TLS to protect the
 communication between the AS and client when requesting an access token,
 between the client and RS when accessing a resource, and between the AS and RS if
 introspection is used.  This framework requires similar security
 properties but does not require that they be realized with TLS.  
 See <a href="#oauthProfile" class="xref">Section 5</a>.<a href="#appendix-E-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-E-2.3">Cardinality of <code>grant_type</code> parameter</dt>
        <dd style="margin-left: 1.5em" id="appendix-E-2.4">In client-to-AS requests 
 using OAuth 2.0, the <code>grant_type</code> parameter is required (per 
 <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>).  In this framework, this parameter
 is optional.  See <a href="#tokenRequest" class="xref">Section 5.8.1</a>.<a href="#appendix-E-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-E-2.5">Encoding of <code>scope</code> parameter</dt>
        <dd style="margin-left: 1.5em" id="appendix-E-2.6">In client-to-AS requests using OAuth
 2.0, the <code>scope</code> parameter is string encoded (per 
 <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>).  In this framework, this parameter
 may also be
 encoded as a byte string.  See <a href="#tokenRequest" class="xref">Section 5.8.1</a>.<a href="#appendix-E-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-E-2.7">Cardinality of <code>token_type</code> parameter</dt>
        <dd style="margin-left: 1.5em" id="appendix-E-2.8">In AS-to-client responses
 using OAuth 2.0, the <code>token_type</code> parameter is required (per 
 <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>).  In this framework, this parameter
 is
 optional.  See <a href="#tokenResponse" class="xref">Section 5.8.2</a>.<a href="#appendix-E-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-E-2.9">Access token retention</dt>
        <dd style="margin-left: 1.5em" id="appendix-E-2.10">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
        <a href="#tokenAuthInfoEndpoint" class="xref">Section 5.10.1</a>.<a href="#appendix-E-2.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="app_options">
<section id="appendix-F">
      <h2 id="name-deployment-examples">
<a href="#appendix-F" class="section-number selfRef">Appendix F. </a><a href="#name-deployment-examples" class="section-name selfRef">Deployment Examples</a>
      </h2>
<p id="appendix-F-1">There is a large variety of IoT deployments, as is indicated in
        <a href="#constraints" class="xref">Appendix A</a>, and this section highlights a few common
        variants.  This section is not normative but illustrates how the
        framework can be applied.<a href="#appendix-F-1" class="pilcrow">¶</a></p>
<p id="appendix-F-2">For each of the deployment variants, there are a number of possible
        security setups between clients, resource servers, and authorization
        servers.  The main focus in the following subsections is on how
        authorization of a client request for a resource hosted by an RS is
        performed.  This requires the security of the requests and
        responses between the clients and the RS to be considered.<a href="#appendix-F-2" class="pilcrow">¶</a></p>
<p id="appendix-F-3">Note: CBOR diagnostic notation is used for examples of requests
          and responses.<a href="#appendix-F-3" class="pilcrow">¶</a></p>
<div id="localTokenValidation">
<section id="appendix-F.1">
        <h3 id="name-local-token-validation">
<a href="#appendix-F.1" class="section-number selfRef">F.1. </a><a href="#name-local-token-validation" class="section-name selfRef">Local Token Validation</a>
        </h3>
<p id="appendix-F.1-1">In this scenario, the case where the resource server is offline is considered,
 i.e., it is not connected to the AS at the time of the access request.
 This access procedure involves steps (A), (B), (C), and (F) of <a href="#fig_protocolFlow" class="xref">Figure 1</a>.<a href="#appendix-F.1-1" class="pilcrow">¶</a></p>
<p id="appendix-F.1-2">Since the resource server must be able to verify the access token locally,
 self-contained access tokens must be used.<a href="#appendix-F.1-2" class="pilcrow">¶</a></p>
<p id="appendix-F.1-3">This example shows the interactions between a client, the
 authorization server, and a temperature sensor acting as a resource server.  Message
 exchanges A and B are shown in <a href="#fig_RSOffline" class="xref">Figure 11</a>.<a href="#appendix-F.1-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-F.1-4">
          <dt id="appendix-F.1-4.1">A:</dt>
          <dd style="margin-left: 2.0em" id="appendix-F.1-4.2">
            <p id="appendix-F.1-4.2.1">The client first generates a public-private key pair used for
     communication security with the RS.<a href="#appendix-F.1-4.2.1" class="pilcrow">¶</a></p>
<p id="appendix-F.1-4.2.2">The client sends a CoAP POST request to the token endpoint at the AS. 
     The security
            of this request can be transport or application layer. It is up the
            communication security profile to define. In the example, it is
     assumed that both the client and AS have performed mutual authentication,
     e.g., via DTLS.  The request contains the public key of the client and
     the <code>audience</code> 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.<a href="#appendix-F.1-4.2.2" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="appendix-F.1-4.3">B:</dt>
          <dd style="margin-left: 2.0em" id="appendix-F.1-4.4">
            <p id="appendix-F.1-4.4.1">The AS responds with a 2.05 (Content) response containing the
     Access Information, including the access token.
     The PoP access token contains the public key of the client, and the
     Access Information  contains the public key of the RS.  For communication
     security, this example uses DTLS RawPublicKey between the client and the
     RS. The issued token will have a short validity time, i.e., <code>exp</code> close
     to <code>iat</code>, in order to mitigate attacks using stolen client credentials.
     The token includes claims, such as <code>scope</code>, with the authorized access
     that an owner of the temperature device can enjoy.  In this example, the
     <code>scope</code> claim issued by the AS informs the RS that the owner of the
     token that can prove the possession of a key is authorized to make a GET
     request against the /temperature resource and a POST request on the
     /firmware resource.  Note that the syntax and semantics of the <code>scope</code> claim
     are application specific.<a href="#appendix-F.1-4.4.1" class="pilcrow">¶</a></p>
<p id="appendix-F.1-4.4.2">Note: In this example, it is assumed that the client knows what resource
     it wants to access and is therefore able to request specific
     <code>audience</code> and <code>scope</code> claims for the access token.<a href="#appendix-F.1-4.4.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
<span id="name-token-request-and-response-"></span><div id="fig_RSOffline">
<figure id="figure-11">
          <div class="alignLeft art-text artwork" id="appendix-F.1-5.1">
<pre>
         Authorization
  Client    Server
    |         |
    |&lt;=======&gt;| DTLS Connection Establishment
    |         |   and mutual authentication
    |         |
A:  +--------&gt;| Header: POST (Code=0.02)
    |  POST   | Uri-Path:"token"
    |         | Content-Format: application/ace+cbor
    |         | Payload: &lt;Request-Payload&gt;
    |         |
B:  |&lt;--------+ Header: 2.05 Content
    |  2.05   | Content-Format: application/ace+cbor
    |         | Payload: &lt;Response-Payload&gt;
    |         |
</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
<a href="#name-token-request-and-response-" class="selfRef">Token Request and Response Using Client Credentials</a>
          </figcaption></figure>
</div>
<p id="appendix-F.1-6">The information contained in the Request-Payload and the
    Response-Payload is shown in <a href="#fig_RSOfflineReq" class="xref">Figure 12</a>.
    Note that the parameter <code>rs_cnf</code> from
    <span>[<a href="#RFC9201" class="xref">RFC9201</a>]</span> is used to inform
    the client about the resource server's public key.<a href="#appendix-F.1-6" class="pilcrow">¶</a></p>
<span id="name-request-and-response-payloa"></span><div id="fig_RSOfflineReq">
<figure id="figure-12">
          <div id="appendix-F.1-7.1">
<pre class="lang-cbor-diag sourcecode">
Request-Payload :
{
  / audience / 5 : "tempSensorInLivingRoom",
  / client_id / 24 : "myclient",
  / req_cnf / 4 : {
  / COSE_Key / 1 : {
      / kid / 2 : b64'1Bg8vub9tLe1gHMzV76e',
      / kty / 1 : 2 / EC2 /,
      / crv / -1 : 1 / P-256 /,
      / x / -2 : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
      / y / -3 : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
    }
  }
}

Response-Payload :
{
  / access_token / 1 : b64'0INDoQEKoQVNKkXfb7xaWqMT'/ .../,
  / rs_cnf / 41 : {
    / COSE_Key / 1 : {
      / kid / 2 : b64'c29tZSBwdWJsaWMga2V5IGlk',
      / kty / 1 : 2 / EC2 /,
      / crv / -1 : 1 / P-256 /,
      / x / -2   : b64'MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4',
      / y / -3   : b64'4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM'
    }
  }
}
</pre>
</div>
<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
<a href="#name-request-and-response-payloa" class="selfRef">Request and Response Payload Details</a>
          </figcaption></figure>
</div>
<p id="appendix-F.1-8">The content of the access token is shown
    in <a href="#fig_BothcborMappingValueAsymmetricCWT" class="xref">Figure 13</a>.<a href="#appendix-F.1-8" class="pilcrow">¶</a></p>
<span id="name-access-token-including-publ"></span><div id="fig_BothcborMappingValueAsymmetricCWT">
<figure id="figure-13">
          <div id="appendix-F.1-9.1">
<pre class="lang-cbor-diag sourcecode">
{
  / aud / 3 : "tempSensorInLivingRoom",
  / iat / 6 : 1563451500,
  / exp / 4 : 1563453000,
  / scope / 9 :  "temperature_g firmware_p",
  / cnf / 8 : {
    / COSE_Key / 1 : {
      / kid / 2 : b64'1Bg8vub9tLe1gHMzV76e',
      / kty / 1 : 2 / EC2 /,
      / crv / -1 : 1 / P-256 /,
      / x / -2 : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
      / y / -3 : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
    }
  }
}
</pre>
</div>
<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
<a href="#name-access-token-including-publ" class="selfRef">Access Token Including Public Key of the Client</a>
          </figcaption></figure>
</div>
<p id="appendix-F.1-10">Messages C and F are shown in Figures
    <a href="#fig_RSOfflinePostAccessTokenAsymmetric" class="xref">14</a> and
    <a href="#fig_RSOfflineDTLSRequestAndResponse" class="xref">15</a>.<a href="#appendix-F.1-10" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-F.1-11">
          <dt id="appendix-F.1-11.1">C:</dt>
          <dd style="margin-left: 2.0em" id="appendix-F.1-11.2">
     The client then sends the PoP access token to the authz-info endpoint at
     the RS.  This is a plain CoAP POST request, i.e., no transport or
     application-layer security is used between the client and RS since the token is
     integrity protected
     between the AS and RS.  The RS verifies that the PoP access token was
     created by a
     known and trusted AS, which it applies to this RS, and that it is valid. 
     The RS caches
     the security context together with authorization information about this
     client contained in the PoP access token.<a href="#appendix-F.1-11.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span id="name-access-token-provisioning-t"></span><div id="fig_RSOfflinePostAccessTokenAsymmetric">
<figure id="figure-14">
          <div class="alignLeft art-text artwork" id="appendix-F.1-12.1">
<pre>
           Resource
 Client     Server
    |         |
C:  +--------&gt;| Header: POST (Code=0.02)
    |  POST   | Uri-Path:"authz-info"
    |         | Payload: 0INDoQEKoQVN ...
    |         |
    |&lt;--------+ Header: 2.04 Changed
    |  2.04   |
    |         |
</pre>
</div>
<figcaption><a href="#figure-14" class="selfRef">Figure 14</a>:
<a href="#name-access-token-provisioning-t" class="selfRef">Access Token Provisioning to the RS</a>
          </figcaption></figure>
</div>
<p id="appendix-F.1-13">The client and the RS runs the DTLS handshake using the raw
      public keys established in steps B and C.<a href="#appendix-F.1-13" class="pilcrow">¶</a></p>
<p id="appendix-F.1-14">The client sends a CoAP GET request to /temperature on the RS over
      DTLS. The RS verifies that the request is authorized based on
      previously established security context.<a href="#appendix-F.1-14" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-F.1-15">
          <dt id="appendix-F.1-15.1">F:</dt>
          <dd style="margin-left: 1.5em" id="appendix-F.1-15.2">The RS responds over the same DTLS channel with a CoAP 2.05 Content response
   containing a resource representation as payload.<a href="#appendix-F.1-15.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span id="name-resource-request-and-respon"></span><div id="fig_RSOfflineDTLSRequestAndResponse">
<figure id="figure-15">
          <div class="alignLeft art-text artwork" id="appendix-F.1-16.1">
<pre>
           Resource
 Client     Server
    |         |
    |&lt;=======&gt;| DTLS Connection Establishment
    |         |   using Raw Public Keys
    |         |
    +--------&gt;| Header: GET (Code=0.01)
    | GET     | Uri-Path: "temperature"
    |         |
    |         |
    |         |
F:  |&lt;--------+ Header: 2.05 Content
    | 2.05    | Payload: &lt;sensor value&gt;
    |         |
</pre>
</div>
<figcaption><a href="#figure-15" class="selfRef">Figure 15</a>:
<a href="#name-resource-request-and-respon" class="selfRef">Resource Request and Response Protected by DTLS</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="introspectionAidedTokenValidation">
<section id="appendix-F.2">
        <h3 id="name-introspection-aided-token-v">
<a href="#appendix-F.2" class="section-number selfRef">F.2. </a><a href="#name-introspection-aided-token-v" class="section-name selfRef">Introspection Aided Token Validation</a>
        </h3>
<p id="appendix-F.2-1">In this deployment scenario, it is assumed that a client is not able to
  access the AS at the time of the access request, whereas the RS is assumed
  to be connected to the back-end infrastructure. Thus, the RS can make use of
  token introspection.  This access procedure involves steps (A)-(F) of
  <a href="#fig_protocolFlow" class="xref">Figure 1</a> but assumes steps (A) and (B) have been
  carried out during a phase when the client had connectivity to the AS.<a href="#appendix-F.2-1" class="pilcrow">¶</a></p>
<p id="appendix-F.2-2">Since the client is assumed to be offline, at least for a certain period of
  time, a preprovisioned access token has to be long lived.  Since the client
  is constrained, the token will not be self-contained (i.e., not a CWT) but
  instead just a reference.  The resource server uses its connectivity to
  learn about the claims associated to the access token by using introspection,
  which is shown in the example below.<a href="#appendix-F.2-2" class="pilcrow">¶</a></p>
<p id="appendix-F.2-3">In the example, interactions between an offline client
    (key fob), an RS (online lock), and an AS is shown.  It is
    assumed that there is a provisioning step where the client has access to the
    AS.  This corresponds to message exchanges A and B, which are shown in
    <a href="#fig_cOffline" class="xref">Figure 16</a>.<a href="#appendix-F.2-3" class="pilcrow">¶</a></p>
<p id="appendix-F.2-4">Authorization consent from the resource owner can be preconfigured,
    but it can also be provided via an interactive flow with the resource
    owner.  An example of this for the key fob case could be that the
    resource owner has a connected car and buys a generic key to use with the
 car.  To authorize the key fob, the owner connects it to a computer that 
 then provides the UI for the device.  After that, OAuth 2.0 implicit flow
 can be used to authorize the key for the car at the car manufacturer's 
 AS.<a href="#appendix-F.2-4" class="pilcrow">¶</a></p>
<p id="appendix-F.2-5">Note: In this example, the client does not know the exact door it
    will be used to access since the token request is not sent at the
    time of access. So the <code>scope</code> and <code>audience</code> 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.<a href="#appendix-F.2-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-F.2-6">
          <dt id="appendix-F.2-6.1">A:</dt>
          <dd style="margin-left: 2.0em" id="appendix-F.2-6.2">The client sends a CoAP POST request to the token endpoint at the
 AS.  The request contains the <code>audience</code> parameter set to  "PACS1337"
 (Physical Access System (PACS)), a value that identifies the
 physical access control system to which the individual doors are
 connected.  The AS generates an access token as an opaque string, which
 it can match to the specific client and the targeted audience. It
 furthermore generates a symmetric proof-of-possession key. The
 communication security and authentication between the client and AS
 is assumed to have been provided at the transport layer (e.g., via DTLS)
   using a pre-shared security context (pre-shared key (PSK), RPK, or
   certificate).<a href="#appendix-F.2-6.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="appendix-F.2-6.3">B:</dt>
          <dd style="margin-left: 2.0em" id="appendix-F.2-6.4">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.<a href="#appendix-F.2-6.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="appendix-F.2-7">Note: In this example, we are using a symmetric key for a multi-RS
 audience, which is not recommended normally (see <a href="#audience" class="xref">Section 6.9</a>).
 However, in this case, the risk is deemed to be acceptable, since
 all the doors are part of the same physical access control system;
 therefore, the risk of a malicious RS impersonating the client towards
 another RS is low.<a href="#appendix-F.2-7" class="pilcrow">¶</a></p>
<span id="name-token-request-and-response-u"></span><div id="fig_cOffline">
<figure id="figure-16">
          <div class="alignLeft art-text artwork" id="appendix-F.2-8.1">
<pre>
         Authorization
 Client     Server
    |         |
    |&lt;=======&gt;| DTLS Connection Establishment
    |         |   and mutual authentication
    |         |
A:  +--------&gt;| Header: POST (Code=0.02)
    |  POST   | Uri-Path:"token"
    |         | Content-Format: application/ace+cbor
    |         | Payload: &lt;Request-Payload&gt;
    |         |
B:  |&lt;--------+ Header: 2.05 Content
    |         | Content-Format: application/ace+cbor
    |  2.05   | Payload: &lt;Response-Payload&gt;
    |         |
</pre>
</div>
<figcaption><a href="#figure-16" class="selfRef">Figure 16</a>:
<a href="#name-token-request-and-response-u" class="selfRef">Token Request and Response Using Client Credentials</a>
          </figcaption></figure>
</div>
<p id="appendix-F.2-9">The information contained in the Request-Payload and the
 Response-Payload is shown in <a href="#fig_cOfflineReq" class="xref">Figure 17</a>.<a href="#appendix-F.2-9" class="pilcrow">¶</a></p>
<span id="name-request-and-response-payload"></span><div id="fig_cOfflineReq">
<figure id="figure-17">
          <div id="appendix-F.2-10.1">
<pre class="lang-cbor-diag sourcecode">
Request-Payload:
{
  / client_id / 24 : "keyfob",
  / audience / 5   : "PACS1337"
}

Response-Payload:
{
  / access_token / 1 : b64'VGVzdCB0b2tlbg',
  / cnf / 8 : {
    / COSE_Key / 1 : {
      / kid / 2 : b64'c29tZSBwdWJsaWMga2V5IGlk',
      / kty / 1 : 4 / Symmetric /,
      / k / -1  : b64'ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE'
    }
  }
}
</pre>
</div>
<figcaption><a href="#figure-17" class="selfRef">Figure 17</a>:
<a href="#name-request-and-response-payload" class="selfRef">Request and Response Payload for the C Offline</a>
          </figcaption></figure>
</div>
<p id="appendix-F.2-11">In this case, the access token is just an opaque byte string referencing
   the authorization information at the AS.<a href="#appendix-F.2-11" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-F.2-12">
          <dt id="appendix-F.2-12.1">C:</dt>
          <dd style="margin-left: 2.0em" id="appendix-F.2-12.2">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.<a href="#appendix-F.2-12.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="appendix-F.2-12.3">D:</dt>
          <dd style="margin-left: 2.0em" id="appendix-F.2-12.4">The RS sends the token to the introspection
          endpoint on the AS using a CoAP POST request.  In this example, the RS and
   AS are assumed to have performed mutual authentication using a pre-shared security
   context (PSK, RPK, or certificate) with the RS acting as the DTLS client.<a href="#appendix-F.2-12.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="appendix-F.2-12.5">E:</dt>
          <dd style="margin-left: 2.0em" id="appendix-F.2-12.6">
            <p id="appendix-F.2-12.6.1">The AS provides the introspection response (2.05 Content)
 containing parameters about the token.  This includes the confirmation
 key (<code>cnf</code>) parameter that allows the RS to verify the client's proof of
 possession in step F. Note that our example in <a href="#fig_cOfflineIntroReq" class="xref">Figure 19</a> assumes a preestablished key
 (e.g., one
 used by the client and the RS for a previous token) that is now only
 referenced by its key identifier <code>kid</code>.<a href="#appendix-F.2-12.6.1" class="pilcrow">¶</a></p>
<p id="appendix-F.2-12.6.2">After receiving message E, the RS responds to the client's POST in
        step C with the CoAP response code 2.01 (Created).<a href="#appendix-F.2-12.6.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
<span id="name-token-introspection-for-the"></span><div id="fig_cOfflineIntrospection">
<figure id="figure-18">
          <div class="alignLeft art-text artwork" id="appendix-F.2-13.1">
<pre>
           Resource
  Client    Server
    |         |
C:  +--------&gt;| Header: POST (T=CON, Code=0.02)
    |  POST   | Uri-Path:"authz-info"
    |         | Payload: b64'VGVzdCB0b2tlbg'
    |         |
    |         |     Authorization
    |         |       Server
    |         |          |
    |      D: +---------&gt;| Header: POST (Code=0.02)
    |         |  POST    | Uri-Path: "introspect"
    |         |          | Content-Format: application/ace+cbor
    |         |          | Payload: &lt;Request-Payload&gt;
    |         |          |
    |      E: |&lt;---------+ Header: 2.05 Content
    |         |  2.05    | Content-Format: application/ace+cbor
    |         |          | Payload: &lt;Response-Payload&gt;
    |         |          |
    |         |
    |&lt;--------+ Header: 2.01 Created
    |  2.01   |
    |         |
</pre>
</div>
<figcaption><a href="#figure-18" class="selfRef">Figure 18</a>:
<a href="#name-token-introspection-for-the" class="selfRef">Token Introspection for the C Offline</a>
          </figcaption></figure>
</div>
<p id="appendix-F.2-14">The information contained in the Request-Payload and the
        Response-Payload is shown in <a href="#fig_cOfflineIntroReq" class="xref">Figure 19</a>.<a href="#appendix-F.2-14" class="pilcrow">¶</a></p>
<span id="name-request-and-response-payload-"></span><div id="fig_cOfflineIntroReq">
<figure id="figure-19">
          <div id="appendix-F.2-15.1">
<pre class="lang-cbor-diag sourcecode">
Request-Payload:
{
  / token /     11 : b64'VGVzdCB0b2tlbg',
  / client_id / 24 : "FrontDoor"
}

Response-Payload:
{
  / active / 10 : true,
  / aud /     3 : "lockOfDoor4711",
  / scope /   9 : "open close",
  / iat /     6 : 1563454000,
  / cnf /     8 : {
         / kid / 3 : b64'c29tZSBwdWJsaWMga2V5IGlk'
  }
}
</pre>
</div>
<figcaption><a href="#figure-19" class="selfRef">Figure 19</a>:
<a href="#name-request-and-response-payload-" class="selfRef">Request and Response Payload for Introspection</a>
          </figcaption></figure>
</div>
<p id="appendix-F.2-16">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.<a href="#appendix-F.2-16" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-F.2-17">
          <dt id="appendix-F.2-17.1">F:</dt>
          <dd style="margin-left: 2.0em" id="appendix-F.2-17.2">The RS responds with an appropriate response over the secure DTLS channel.<a href="#appendix-F.2-17.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span id="name-resource-request-and-respons"></span><div id="fig_cOfflineDTLSRequestAndResponse">
<figure id="figure-20">
          <div class="alignLeft art-text artwork" id="appendix-F.2-18.1">
<pre>
           Resource
  Client    Server
    |         |
    |&lt;=======&gt;| DTLS Connection Establishment
    |         |   using Pre Shared Key
    |         |
    +--------&gt;| Header: PUT (Code=0.03)
    | PUT     | Uri-Path: "state"
    |         | Payload: &lt;new state for the lock&gt;
    |         |
F:  |&lt;--------+ Header: 2.04 Changed
    | 2.04    | Payload: &lt;new state for the lock&gt;
    |         |
</pre>
</div>
<figcaption><a href="#figure-20" class="selfRef">Figure 20</a>:
<a href="#name-resource-request-and-respons" class="selfRef">Resource Request and Response Protected by OSCORE</a>
          </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
<div id="Acknowledgments">
<section id="appendix-G">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-G-1">This document is a product of the ACE Working Group of the IETF.<a href="#appendix-G-1" class="pilcrow">¶</a></p>
<p id="appendix-G-2">Thanks to <span class="contact-name">Eve Maler</span> for her contributions to the use of
      OAuth 2.0 and Unlicensed Mobile Access (UMA) in IoT scenarios, 
      <span class="contact-name">Robert Taylor</span> for his
      discussion input, and <span class="contact-name">Mališa Vučinić</span> for his input on the
      predecessors of this proposal.<a href="#appendix-G-2" class="pilcrow">¶</a></p>
<p id="appendix-G-3">Thanks to the authors of "<span>[<a href="#I-D.ietf-oauth-pop-key-distribution" class="xref">POP-KEY-DIST</a>]</span><a href="#I-D.ietf-oauth-pop-key-distribution" class="xref">OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution</a>" <span>[<a href="#I-D.ietf-oauth-pop-key-distribution" class="xref">POP-KEY-DIST</a>]</span>, from where
      parts of the security considerations where copied.<a href="#appendix-G-3" class="pilcrow">¶</a></p>
<p id="appendix-G-4">Thanks to <span class="contact-name">Stefanie Gerdes</span>, <span class="contact-name">Olaf       Bergmann</span>, and <span class="contact-name">Carsten       Bormann</span> for contributing their work on AS discovery from
      "<a href="#I-D.gerdes-ace-dcaf-authorize" class="xref">Delegated CoAP Authentication and Authorization Framework (DCAF)</a>" <span>[<a href="#I-D.gerdes-ace-dcaf-authorize" class="xref">DCAF</a>]</span> (see <a href="#asDiscovery" class="xref">Section 5.1</a>) and the considerations on multiple access tokens.<a href="#appendix-G-4" class="pilcrow">¶</a></p>
<p id="appendix-G-5">Thanks to <span class="contact-name">Jim Schaad</span> and <span class="contact-name">Mike       Jones</span> for their comprehensive reviews.<a href="#appendix-G-5" class="pilcrow">¶</a></p>
<p id="appendix-G-6">Thanks to <span class="contact-name">Benjamin Kaduk</span> for his input on various
      questions related to this work.<a href="#appendix-G-6" class="pilcrow">¶</a></p>
<p id="appendix-G-7">Thanks to <span class="contact-name">Cigdem Sengul</span> for some very useful review
      comments.<a href="#appendix-G-7" class="pilcrow">¶</a></p>
<p id="appendix-G-8">Thanks to <span class="contact-name">Carsten Bormann</span> for contributing the text for
      the CoRE Resource Type registry.<a href="#appendix-G-8" class="pilcrow">¶</a></p>
<p id="appendix-G-9">Thanks to <span class="contact-name">Roman Danyliw</span> for suggesting <a href="#app_diffOAuth" class="xref">Appendix E</a>
      (including its contents).<a href="#appendix-G-9" class="pilcrow">¶</a></p>
<p id="appendix-G-10"><span class="contact-name">Ludwig Seitz</span> and <span class="contact-name">Göran Selander</span>
      worked on this document as part of the CelticPlus project CyberWI, with funding
      from Vinnova. <span class="contact-name">Ludwig Seitz</span>
      has also received further funding for this work by Vinnova in the context of
      the CelticNext project CRITISEC.<a href="#appendix-G-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-H">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ludwig Seitz</span></div>
<div dir="auto" class="left"><span class="org">Combitech</span></div>
<div dir="auto" class="left"><span class="street-address">Djäknegatan 31</span></div>
<div dir="auto" class="left">SE-<span class="postal-code">211 35</span> <span class="locality">Malmö</span>
</div>
<div dir="auto" class="left"><span class="country-name">Sweden</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ludwig.seitz@combitech.com" class="email">ludwig.seitz@combitech.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Göran Selander</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left">SE-<span class="postal-code">164 80</span> <span class="locality">Kista</span>
</div>
<div dir="auto" class="left"><span class="country-name">Sweden</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:goran.selander@ericsson.com" class="email">goran.selander@ericsson.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Erik Wahlstroem</span></div>
<div dir="auto" class="left"><span class="country-name">Sweden</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:erik@wahlstromstekniska.se" class="email">erik@wahlstromstekniska.se</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Samuel Erdtman</span></div>
<div dir="auto" class="left"><span class="org">Spotify AB</span></div>
<div dir="auto" class="left"><span class="street-address">Birger Jarlsgatan 61, 4tr</span></div>
<div dir="auto" class="left">SE-<span class="postal-code">113 56</span> <span class="locality">Stockholm</span>
</div>
<div dir="auto" class="left"><span class="country-name">Sweden</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:erdtman@spotify.com" class="email">erdtman@spotify.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Hannes Tschofenig</span></div>
<div dir="auto" class="left"><span class="org">Arm Ltd.</span></div>
<div dir="auto" class="left">
<span class="postal-code">6067</span> <span class="locality">Absam</span>
</div>
<div dir="auto" class="left"><span class="country-name">Austria</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:Hannes.Tschofenig@arm.com" class="email">Hannes.Tschofenig@arm.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>