File: rfc8693.html

package info (click to toggle)
doc-rfc 20201128-1
links: PTS, VCS
area: non-free
in suites: bullseye
size: 1,307,124 kB
file content (3102 lines) | stat: -rw-r--r-- 145,221 bytes
parent folder | download | duplicates (2)
<!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 8693: OAuth 2.0 Token Exchange</title>
<meta content="Michael B. Jones" name="author">
<meta content="Anthony Nadalin" name="author">
<meta content="Brian Campbell" name="author">
<meta content="John Bradley" name="author">
<meta content="Chuck Mortimore" name="author">
<meta content="
       
 This specification defines a protocol for an HTTP- and JSON-based
 Security Token Service (STS) by defining how to request and obtain
 security tokens from OAuth 2.0 authorization servers,
 including security tokens employing impersonation and delegation.
       
    " name="description">
<meta content="xml2rfc 2.38.0" name="generator">
<meta content="JSON Web Token" name="keyword">
<meta content="JWT" name="keyword">
<meta content="Delegation" name="keyword">
<meta content="Impersonation" name="keyword">
<meta content="STS" name="keyword">
<meta content="Security Token Service" name="keyword">
<meta content="Exchange" name="keyword">
<meta content="Token" name="keyword">
<meta content="OAuth" name="keyword">
<meta content="8693" name="rfc.number">
<link href="rfc8693.xml" type="application/rfc+xml" rel="alternate">
<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 {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  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.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;
}
#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;
  }
  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;
  }

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* 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: 0 0 0.25em 0;
  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;
  }
}
/*
  The margin-left: 0 on <dd> removes all distinction
  between levels from nested <dl>s.  Undo that.
*/
dl.olPercent > dd,
dd {
  margin-left: revert;
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}</style>
<link href="rfc-local.css" type="text/css" rel="stylesheet">
<link href="https://dx.doi.org/10.17487/rfc8693" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange-19" 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 8693</td>
<td class="center">OAuth 2.0 Token Exchange</td>
<td class="right">January 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Jones, 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/rfc8693" class="eref">8693</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="2020-01" class="published">January 2020</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">M. Jones</div>
<div class="org">Microsoft</div>
</div>
<div class="author">
      <div class="author-name">A. Nadalin</div>
<div class="org">Microsoft</div>
</div>
<div class="author">
      <div class="author-name">B. Campbell, <span class="editor">Ed.</span>
</div>
<div class="org">Ping Identity</div>
</div>
<div class="author">
      <div class="author-name">J. Bradley</div>
<div class="org">Yubico</div>
</div>
<div class="author">
      <div class="author-name">C. Mortimore</div>
<div class="org">Visa</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8693</h1>
<h1 id="title">OAuth 2.0 Token Exchange</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 protocol for an HTTP- and JSON-based
 Security Token Service (STS) by defining how to request and obtain
 security tokens from OAuth 2.0 authorization servers,
 including security tokens employing impersonation and delegation.<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/rfc8693">https://www.rfc-editor.org/info/rfc8693</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) 2020 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 Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified 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="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-delegation-vs-impersonation" class="xref">Delegation vs. Impersonation Semantics</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-requirements-notation-and-c" class="xref">Requirements Notation and Conventions</a><a href="#section-toc.1-1.1.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.1.2.3">
                <p id="section-toc.1-1.1.2.3.1"><a href="#section-1.3" class="xref">1.3</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.1.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-token-exchange-request-and-" class="xref">Token Exchange Request and Response</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-request" class="xref">Request</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.2.2.1.2.1">
                    <p id="section-toc.1-1.2.2.1.2.1.1"><a href="#section-2.1.1" class="xref">2.1.1</a>.  <a href="#name-relationship-between-resour" class="xref">Relationship between Resource, Audience, and Scope</a><a href="#section-toc.1-1.2.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-response" class="xref">Response</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.2.2.2.2.1">
                    <p id="section-toc.1-1.2.2.2.2.1.1"><a href="#section-2.2.1" class="xref">2.2.1</a>.  <a href="#name-successful-response" class="xref">Successful Response</a><a href="#section-toc.1-1.2.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2.2.2.2.2">
                    <p id="section-toc.1-1.2.2.2.2.2.1"><a href="#section-2.2.2" class="xref">2.2.2</a>.  <a href="#name-error-response" class="xref">Error Response</a><a href="#section-toc.1-1.2.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-example-token-exchange" class="xref">Example Token Exchange</a><a href="#section-toc.1-1.2.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc 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-token-type-identifiers" class="xref">Token Type Identifiers</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc 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-json-web-token-claims-and-i" class="xref">JSON Web Token Claims and Introspection Response Parameters</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-act-actor-claim" class="xref">"act" (Actor) Claim</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-scope-scopes-claim" class="xref">"scope" (Scopes) Claim</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-client_id-client-identifier" class="xref">"client_id" (Client Identifier) Claim</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-may_act-authorized-actor-cl" class="xref">"may_act" (Authorized Actor) Claim</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc 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-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
<li class="toc 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-privacy-considerations" class="xref">Privacy Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
<li class="toc 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-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-oauth-uri-registration" class="xref">OAuth URI Registration</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-oauth-parameters-registrati" class="xref">OAuth Parameters Registration</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-oauth-access-token-type-reg" class="xref">OAuth Access Token Type Registration</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.7.2.4">
                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-json-web-token-claims-regis" class="xref">JSON Web Token Claims Registration</a><a href="#section-toc.1-1.7.2.4.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.7.2.5">
                <p id="section-toc.1-1.7.2.5.1"><a href="#section-7.5" class="xref">7.5</a>.  <a href="#name-oauth-token-introspection-r" class="xref">OAuth Token Introspection Response Registration</a><a href="#section-toc.1-1.7.2.5.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc 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-references" class="xref">References</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc 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-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc 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-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-additional-token-exchange-e" class="xref">Additional Token Exchange Examples</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-impersonation-token-exchang" class="xref">Impersonation Token Exchange Example</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.9.2.1.2.1">
                    <p id="section-toc.1-1.9.2.1.2.1.1"><a href="#section-a.1.1" class="xref">A.1.1</a>.  <a href="#name-token-exchange-request-2" class="xref">Token Exchange Request</a><a href="#section-toc.1-1.9.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.1.2.2">
                    <p id="section-toc.1-1.9.2.1.2.2.1"><a href="#section-a.1.2" class="xref">A.1.2</a>.  <a href="#name-subject-token-claims" class="xref">Subject Token Claims</a><a href="#section-toc.1-1.9.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.1.2.3">
                    <p id="section-toc.1-1.9.2.1.2.3.1"><a href="#section-a.1.3" class="xref">A.1.3</a>.  <a href="#name-token-exchange-response-2" class="xref">Token Exchange Response</a><a href="#section-toc.1-1.9.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.1.2.4">
                    <p id="section-toc.1-1.9.2.1.2.4.1"><a href="#section-a.1.4" class="xref">A.1.4</a>.  <a href="#name-issued-token-claims" class="xref">Issued Token Claims</a><a href="#section-toc.1-1.9.2.1.2.4.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-a.2" class="xref">A.2</a>.  <a href="#name-delegation-token-exchange-e" class="xref">Delegation Token Exchange Example</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.9.2.2.2.1">
                    <p id="section-toc.1-1.9.2.2.2.1.1"><a href="#section-a.2.1" class="xref">A.2.1</a>.  <a href="#name-token-exchange-request-4" class="xref">Token Exchange Request</a><a href="#section-toc.1-1.9.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.2.2.2">
                    <p id="section-toc.1-1.9.2.2.2.2.1"><a href="#section-a.2.2" class="xref">A.2.2</a>.  <a href="#name-subject-token-claims-3" class="xref">Subject Token Claims</a><a href="#section-toc.1-1.9.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.2.2.3">
                    <p id="section-toc.1-1.9.2.2.2.3.1"><a href="#section-a.2.3" class="xref">A.2.3</a>.  <a href="#name-actor-token-claims" class="xref">Actor Token Claims</a><a href="#section-toc.1-1.9.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.2.2.4">
                    <p id="section-toc.1-1.9.2.2.2.4.1"><a href="#section-a.2.4" class="xref">A.2.4</a>.  <a href="#name-token-exchange-response-4" class="xref">Token Exchange Response</a><a href="#section-toc.1-1.9.2.2.2.4.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.2.2.5">
                    <p id="section-toc.1-1.9.2.2.2.5.1"><a href="#section-a.2.5" class="xref">A.2.5</a>.  <a href="#name-issued-token-claims-3" class="xref">Issued Token Claims</a><a href="#section-toc.1-1.9.2.2.2.5.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
</ul>
</nav>
</section>
</div>
<div id="Introduction">
<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">
  A security token is a set of information that facilitates the sharing of
  identity and security information in heterogeneous environments or across
  security domains.  Examples of security tokens include JSON Web Tokens
  (JWTs) <span>[<a href="#RFC7519" class="xref">JWT</a>]</span> and Security Assertion Markup Language (SAML)
  2.0 assertions <span>[<a href="#OASIS.saml-core-2.0-os" class="xref">OASIS.saml-core-2.0-os</a>]</span>.  Security tokens are
  typically signed to achieve integrity and sometimes also encrypted to
  achieve confidentiality.  Security tokens are also sometimes described as
  assertions, such as in <span>[<a href="#RFC7521" class="xref">RFC7521</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
  A Security Token Service (STS) is a service capable of validating
  security tokens provided to it and issuing new security tokens in
  response, which enables clients to obtain appropriate
  access credentials for resources in heterogeneous environments or across security
  domains.
  Web Service clients have used WS-Trust <span>[<a href="#WS-Trust" class="xref">WS-Trust</a>]</span>
  as the protocol to interact with an STS for token exchange.
  While WS-Trust
  uses XML and SOAP, the trend in modern Web development
  has been towards RESTful (Representational State Transfer) patterns and JSON.
  The OAuth 2.0 Authorization Framework <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
  and OAuth 2.0 Bearer Tokens <span>[<a href="#RFC6750" class="xref">RFC6750</a>]</span>
  have emerged as popular standards for authorizing third-party
  applications' access to HTTP and RESTful resources.
  The conventional OAuth 2.0 interaction involves the exchange of some
  representation of resource owner authorization for an access token,
  which has proven to be an extremely useful pattern in practice. However,
  its input and output are somewhat too constrained as is to fully
  accommodate a security token exchange framework.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
  This specification defines a protocol extending OAuth 2.0 that enables
  clients to request and obtain security tokens from authorization servers acting in
  the role of an STS.
  Similar to OAuth 2.0, this specification focuses on client developer simplicity and
  requires only an HTTP client and JSON parser, which are nearly universally available
  in modern development environments. The STS protocol defined in this specification
  is not itself RESTful (an STS doesn't lend itself particularly well to a REST
  approach) but does utilize communication patterns and data formats that should be
  familiar to developers accustomed to working with RESTful systems.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
  A new grant type for a token exchange request and the associated specific parameters for
  such a request to the token endpoint are defined by this specification.
  A token exchange response is a normal OAuth 2.0 response from the token endpoint
  with a few additional parameters defined herein to provide information to the client.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
  The entity that makes the request to exchange tokens is considered the client in the
  context of the token exchange interaction. However, that does not restrict
  usage of this profile to traditional OAuth clients. An OAuth resource server, for example, might assume
  the role of the client during token exchange in order to trade an
  access token that it received in a protected resource request for
  a new token that is appropriate to include in a call to a backend
  service. The new token might be an access token that is more
  narrowly scoped for the downstream service or it could be an entirely different kind
  of token.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">
  The scope of this specification is limited to the definition of a
  basic request-and-response protocol for an STS-style token exchange utilizing OAuth 2.0.
  Although a few new JWT claims are defined that enable delegation semantics to be expressed,
  the specific syntax, semantics, and security characteristics of the tokens themselves
  (both those presented to the authorization server and those obtained by the client)
  are explicitly out of scope, and no requirements are placed on the trust model in
  which an implementation might be deployed. Additional profiles may provide
  more detailed requirements around the specific nature of the parties and trust involved,
  such as whether signing and/or encryption of tokens is needed or if proof-of-possession-style
  tokens will be required or issued. However, such details
  will often be policy decisions made with respect to the specific needs of individual
  deployments and will be configured or implemented accordingly.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">
  The security tokens obtained may be used in a number of contexts,
  the specifics of which are also beyond the scope of this specification.<a href="#section-1-7" class="pilcrow">¶</a></p>
<div id="DelegationImpersonation">
<section id="section-1.1">
        <h3 id="name-delegation-vs-impersonation">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-delegation-vs-impersonation" class="section-name selfRef">Delegation vs. Impersonation Semantics</a>
        </h3>
<p id="section-1.1-1">
    One common use case for an STS (as alluded to in the previous section)
    is to allow a resource server A to make calls to a backend service C on
    behalf of the requesting user B.  Depending on the local site policy and
    authorization infrastructure, it may be desirable for A to use its own
    credentials to access C along with an annotation of some form that A is
    acting on behalf of B ("delegation") or for A to be granted a limited access
    credential to C but that continues to identify B as the authorized
    entity ("impersonation").  Delegation and impersonation can be useful
    concepts in other scenarios involving multiple participants as well.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">
    When principal A impersonates principal B, A is given all
    the rights that B has within some defined rights context
    and is indistinguishable from B in that context.
    Thus, when principal A impersonates principal B, then insofar
    as any entity receiving such a token is concerned, they are
    actually dealing with B. It is true that some members of the
    identity system might have awareness that impersonation is
    going on, but it is not a requirement.
    For all intents and purposes, when A is impersonating B, A is B within the
    context of the rights authorized by the token. A's ability to impersonate B could
    be limited in scope or time, or even with a one-time-use restriction,
    whether via the contents of the token or an out-of-band mechanism.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">
    Delegation semantics are different than
    impersonation semantics, though the two are closely related.
    With delegation semantics, principal A still has its own identity
    separate from B, and it is explicitly understood that while B
    may have delegated some of its rights to A, any actions taken are
    being taken by A representing B. In a sense, A is an agent for B.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
<p id="section-1.1-4">
    Delegation and impersonation are not inclusive of all situations.
    When a principal is acting directly on its own behalf, for example,
    neither delegation nor impersonation are in play. They are, however,
    the more common semantics operating for token exchange and, as such, are
    given more direct treatment in this specification.<a href="#section-1.1-4" class="pilcrow">¶</a></p>
<p id="section-1.1-5">
    Delegation semantics are typically expressed in a token by including information about both the
    primary subject of the token as well as the actor to whom that subject has delegated some of its rights.
    Such a token is sometimes referred to as a composite token because it is composed of information
    about multiple subjects. Typically, in the request, the <code>subject_token</code>
    represents the identity of the party on
    behalf of whom the token is being requested while the <code>actor_token</code> represents
    the identity of the party to whom the access rights of the issued token are being delegated.
    A composite token issued by the authorization server will contain information about both parties.
    When and if a composite token is issued is at the discretion of the authorization server and
    applicable policy and configuration.<a href="#section-1.1-5" class="pilcrow">¶</a></p>
<p id="section-1.1-6">
    The specifics of representing a composite token and even whether or not
    such a token will be issued depend on the details of the implementation
    and the kind of token.  The representations of composite tokens that are
    not JWTs are beyond the scope of this specification.  The <code>actor_token</code> request parameter, however, does provide
    a means for providing information about the desired actor, and the JWT
    <code>act</code> claim can provide a representation of a
    chain of delegation.<a href="#section-1.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="RNC">
<section id="section-1.2">
        <h3 id="name-requirements-notation-and-c">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-requirements-notation-and-c" class="section-name selfRef">Requirements Notation and Conventions</a>
        </h3>
<p id="section-1.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-1.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Terminology">
<section id="section-1.3">
        <h3 id="name-terminology">
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
        </h3>
<p id="section-1.3-1">
   This specification uses the terms
   "access token type", "authorization server", "client", "client identifier",
   "resource server", "token endpoint", "token request", and "token response"
   defined by OAuth 2.0 <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>,
   and the terms "Base64url Encoding", "Claim", and "JWT Claims Set" defined by
   JSON Web Token (JWT) <span>[<a href="#RFC7519" class="xref">JWT</a>]</span>.<a href="#section-1.3-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="Messages">
<section id="section-2">
      <h2 id="name-token-exchange-request-and-">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-token-exchange-request-and-" class="section-name selfRef">Token Exchange Request and Response</a>
      </h2>
<div id="Request">
<section id="section-2.1">
        <h3 id="name-request">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-request" class="section-name selfRef">Request</a>
        </h3>
<p id="section-2.1-1">
  A client requests a security token by making a token request to the authorization
  server's token endpoint using the extension grant type mechanism defined
  in <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-4.5" class="relref">Section 4.5</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">
  Client authentication to the authorization server is done using the normal
  mechanisms provided by OAuth 2.0.
  <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>
  defines password-based authentication of the client,
  however, client authentication is extensible and other mechanisms are possible.
  For example, <span>[<a href="#RFC7523" class="xref">RFC7523</a>]</span> defines client authentication using bearer
  JSON Web Tokens (JWTs) <span>[<a href="#RFC7519" class="xref">JWT</a>]</span>.
  The supported methods of client authentication and whether or not to allow
  unauthenticated or unidentified clients are deployment decisions that are
  at the discretion of the authorization server.
  Note that omitting client authentication allows
  for a compromised token to be leveraged via an STS into other tokens by
  anyone possessing the compromised token. Thus, client
  authentication allows for additional authorization checks by the STS as to which
  entities are permitted to impersonate or receive delegations from other
  entities.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<p id="section-2.1-3">
  The client makes a token exchange request to the token endpoint with an extension
  grant type using the HTTP <code>POST</code> method. The
  following parameters are included in the HTTP request entity-body
  using the <code>application/x-www-form-urlencoded</code>
  format with a character encoding of UTF-8 as described 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-2.1-3" class="pilcrow">¶</a></p>
<dl class="dlNewline" id="section-2.1-4">
          <dt id="section-2.1-4.1">grant_type</dt>
<dd id="section-2.1-4.2">
            <span class="bcp14">REQUIRED</span>. The value
    <code>urn:ietf:params:oauth:grant-type:token-exchange</code>
    indicates that a token exchange is being performed.<a href="#section-2.1-4.2" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-4.3">resource</dt>
<dd id="section-2.1-4.4">
            <span class="bcp14">OPTIONAL</span>.
    A URI that indicates the target service or resource where the client intends to use
    the requested security token. This enables the authorization server to apply policy as appropriate
    for the target, such as determining the type and content of the token to be issued or if and how
    the token is to be encrypted.
    In many cases, a client will not have knowledge of the logical organization of the systems with
    which it interacts and will only know a URI of the service where it intends to use the token.
    The <code>resource</code> parameter allows the client to indicate to the authorization server
    where it intends to use the issued token by providing the location, typically as an https URL, in the
    token exchange request in the same form that will be used to access that resource.
    The authorization server will typically have the capability to map from a resource URI value to
    an appropriate policy. The value of the <code>resource</code> parameter <span class="bcp14">MUST</span> be an
    absolute URI, as specified by <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 <span class="bcp14">MAY</span> include a query component and <span class="bcp14">MUST NOT</span> include a fragment component.
    Multiple <code>resource</code> parameters may be used to indicate
    that the issued token is intended to be used at the multiple resources listed.
    See <span>[<a href="#I-D.ietf-oauth-resource-indicators" class="xref">OAUTH-RESOURCE</a>]</span> for additional
    background and uses of the <code>resource</code> parameter.<a href="#section-2.1-4.4" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-4.5">audience</dt>
<dd id="section-2.1-4.6">
            <span class="bcp14">OPTIONAL</span>.  The logical name of the target service where the client intends
    to use the requested security token. This serves a purpose similar to the
    <code>resource</code> parameter but with the client
    providing a logical name for the target service. Interpretation of the
    name requires that the value be something that both the client and the
    authorization server understand. An OAuth client identifier, a SAML entity
    identifier <span>[<a href="#OASIS.saml-core-2.0-os" class="xref">OASIS.saml-core-2.0-os</a>]</span>, and an OpenID Connect
    Issuer Identifier <span>[<a href="#OpenID.Core" class="xref">OpenID.Core</a>]</span> are examples of things that
    might be used as <code>audience</code> parameter values.
    However, <code>audience</code> values used with a given
    authorization server must be unique within that server to ensure that
    they are properly interpreted as the intended type of value.  Multiple
    <code>audience</code> parameters may be used to indicate
    that the issued token is intended to be used at the multiple audiences
    listed.  The <code>audience</code> and <code>resource</code> parameters may be used together to indicate
    multiple target services with a mix of logical names and resource URIs.<a href="#section-2.1-4.6" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-4.7">scope</dt>
<dd id="section-2.1-4.8">
            <span class="bcp14">OPTIONAL</span>.  A list of space-delimited, case-sensitive
    strings, as defined 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>, that allow the client to specify the desired scope of
    the requested security token in the context of the service or resource
    where the token will be used. The values and associated semantics of scope
    are service specific and expected to be described in the relevant service
    documentation.<a href="#section-2.1-4.8" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-4.9">requested_token_type</dt>
<dd id="section-2.1-4.10">
            <span class="bcp14">OPTIONAL</span>.
    An identifier, as described in <a href="#TokenTypeIdentifiers" class="xref">Section 3</a>, for the type of the requested security token.
    If the requested type is unspecified, the issued token type is at
    the discretion of the authorization server and may be dictated by
    knowledge of the requirements of the service or resource
    indicated by the <code>resource</code> or
    <code>audience</code> parameter.<a href="#section-2.1-4.10" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-4.11">subject_token</dt>
<dd id="section-2.1-4.12">
            <span class="bcp14">REQUIRED</span>.
    A security token that represents the
    identity of the party on behalf of whom the request is being made.
    Typically, the subject of this token will be the subject of
    the security token issued in response to the request.<a href="#section-2.1-4.12" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-4.13">subject_token_type</dt>
<dd id="section-2.1-4.14">
            <span class="bcp14">REQUIRED</span>.
    An identifier, as described in <a href="#TokenTypeIdentifiers" class="xref">Section 3</a>, that indicates the type of the security token in
    the <code>subject_token</code> parameter.<a href="#section-2.1-4.14" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-4.15">actor_token</dt>
<dd id="section-2.1-4.16">
            <span class="bcp14">OPTIONAL</span>.
    A security token that represents
    the identity of the acting party. Typically, this will be the party that is authorized to use the requested security token and act on behalf of the subject.<a href="#section-2.1-4.16" class="pilcrow">¶</a>
</dd>
<dt id="section-2.1-4.17">actor_token_type</dt>
<dd id="section-2.1-4.18">
    An identifier, as described in <a href="#TokenTypeIdentifiers" class="xref">Section 3</a>, that indicates the type of the security token in the
    <code>actor_token</code> parameter.
    This is <span class="bcp14">REQUIRED</span> when the <code>actor_token</code> parameter
    is present in the request but <span class="bcp14">MUST NOT</span> be included otherwise.<a href="#section-2.1-4.18" class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-2.1-5">
  In processing the request, the authorization server <span class="bcp14">MUST</span> perform the appropriate validation procedures for the indicated token
  type and, if the actor token is present, also
  perform the appropriate validation procedures for its indicated token type.
  The validity criteria and details of any particular token are beyond the scope of
  this document and are specific to the respective type of token and its content.<a href="#section-2.1-5" class="pilcrow">¶</a></p>
<p id="section-2.1-6">
  In the absence of one-time-use or other semantics specific to the token type, the act of performing
  a token exchange has no impact on the validity of the subject token or actor token.
  Furthermore, the exchange is a one-time event and does not create a tight linkage
  between the input and output tokens, so that (for example) while the expiration
  time of the output token may be influenced by that of the input token,
  renewal or extension of the input token is not expected to be reflected in
  the output token's properties.  It may still be appropriate or desirable to propagate
  token-revocation events. However, doing so is not a general property of the STS
  protocol and would be specific to a particular implementation, token type, or deployment.<a href="#section-2.1-6" class="pilcrow">¶</a></p>
<section id="section-2.1.1">
          <h4 id="name-relationship-between-resour">
<a href="#section-2.1.1" class="section-number selfRef">2.1.1. </a><a href="#name-relationship-between-resour" class="section-name selfRef">Relationship between Resource, Audience, and Scope</a>
          </h4>
<p id="section-2.1.1-1">
          When requesting a token, the client can indicate the desired target
          service(s) where it intends to use that token by way of the <code>audience</code> and <code>resource</code> parameters as well as indicate the
          desired scope of the requested token using the <code>scope</code> parameter.

          The semantics of such a request are that the client is asking for a token with the requested
          scope that is usable at all the requested target services. Effectively, the requested access rights of
          the token are the Cartesian product of all the scopes at all the target services.<a href="#section-2.1.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1.1-2">
          An authorization server may be unwilling or unable to fulfill any token request, but the likelihood
          of an unfulfillable request is significantly higher when very broad access rights are being solicited.
          As such, in the absence of specific knowledge about the relationship of systems in a deployment,
          clients should exercise discretion in the breadth of the access requested, particularly the
          number of target services. An authorization server can use the <code>invalid_target</code>
          error code, defined in <a href="#ErrorResponse" class="xref">Section 2.2.2</a>, to inform a client that it requested access to
          too many target services simultaneously.<a href="#section-2.1.1-2" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="Response">
<section id="section-2.2">
        <h3 id="name-response">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-response" class="section-name selfRef">Response</a>
        </h3>
<p id="section-2.2-1">
  The authorization server responds to a token exchange request with a normal
  OAuth 2.0 response from the token endpoint, as specified in
  <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-5" class="relref">Section 5</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>. Additional details and
  explanation are provided in the following subsections.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<div id="SuccessfulResponse">
<section id="section-2.2.1">
          <h4 id="name-successful-response">
<a href="#section-2.2.1" class="section-number selfRef">2.2.1. </a><a href="#name-successful-response" class="section-name selfRef">Successful Response</a>
          </h4>
<p id="section-2.2.1-1">
  If the request is valid and meets all policy and other criteria of the authorization server,
  a successful token response is constructed by adding the following parameters
  to the entity-body of the HTTP response using the "application/json"
  media type, as specified by <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span>, and an HTTP 200 status code.  The
  parameters are serialized into a JavaScript Object Notation (JSON)
  structure by adding each parameter at the top level.
  Parameter names and string values are included as JSON strings.
  Numerical values are included as JSON numbers.  The order of
  parameters does not matter and can vary.<a href="#section-2.2.1-1" class="pilcrow">¶</a></p>
<dl class="dlNewline" id="section-2.2.1-2">
            <dt id="section-2.2.1-2.1">access_token</dt>
<dd id="section-2.2.1-2.2">
              <span class="bcp14">REQUIRED</span>. The security token issued by the authorization server in response
  to the token exchange request.
  The <code>access_token</code> parameter from
  <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> is used here to carry the requested
  token, which allows this token exchange protocol to use the existing OAuth 2.0 request
  and response constructs defined for the token endpoint.
  The identifier <code>access_token</code> is used for historical
  reasons and the issued token need not be an OAuth access token.<a href="#section-2.2.1-2.2" class="pilcrow">¶</a>
</dd>
<dt id="section-2.2.1-2.3">issued_token_type</dt>
<dd id="section-2.2.1-2.4">
              <span class="bcp14">REQUIRED</span>.  An identifier, as described in <a href="#TokenTypeIdentifiers" class="xref">Section 3</a>,
  for the representation of the issued security token.<a href="#section-2.2.1-2.4" class="pilcrow">¶</a>
</dd>
<dt id="section-2.2.1-2.5">token_type</dt>
<dd id="section-2.2.1-2.6">
              <span class="bcp14">REQUIRED</span>.  A case-insensitive value specifying the method of using the
  access token issued, as specified in <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-7.1" class="relref">Section 7.1</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>.
  It provides the client with information about how to utilize the access
  token to access protected resources.  For example, a value of <code>Bearer</code>, as specified in <span>[<a href="#RFC6750" class="xref">RFC6750</a>]</span>,
  indicates that the issued security token is a bearer token and the client
  can simply present it as is without any additional proof of eligibility
  beyond the contents of the token itself.  Note that the meaning of this
  parameter is different from the meaning of the <code>issued_token_type</code> parameter, which declares the
  representation of the issued security token; the term "token type" is more
  typically used to mean the structural or syntactical representation of the security token, as it is in all <code>*_token_type</code> parameters in this specification.  If the
  issued token is not an access token or usable as an access token, then the
  <code>token_type</code> value <code>N_A</code>
  is used to indicate that an OAuth 2.0 <code>token_type</code>
  identifier is not applicable in that context.<a href="#section-2.2.1-2.6" class="pilcrow">¶</a>
</dd>
<dt id="section-2.2.1-2.7">expires_in</dt>
<dd id="section-2.2.1-2.8">
              <span class="bcp14">RECOMMENDED</span>.  The validity lifetime, in seconds, of the token issued by the
  authorization server. Oftentimes, the client will not have the inclination or capability
  to inspect the content of the token, and this parameter provides a consistent and token-type-agnostic
  indication of how long the token can be expected to be valid.
  For example, the value 1800 denotes that the token will
  expire in thirty minutes from the time the response was generated.<a href="#section-2.2.1-2.8" class="pilcrow">¶</a>
</dd>
<dt id="section-2.2.1-2.9">scope</dt>
<dd id="section-2.2.1-2.10">
              <span class="bcp14">OPTIONAL</span> if the scope of the issued security token is identical to the scope requested by the client;
  otherwise, it is <span class="bcp14">REQUIRED</span>.<a href="#section-2.2.1-2.10" class="pilcrow">¶</a>
</dd>
<dt id="section-2.2.1-2.11">refresh_token</dt>
<dd id="section-2.2.1-2.12">
              <span class="bcp14">OPTIONAL</span>.
  A refresh token will typically not be issued when the exchange is of one temporary
  credential (the subject_token) for a different temporary credential (the issued token)
  for use in some other context.
  A refresh token can be issued in cases where the client of the token exchange needs the
  ability to access a resource even when the original credential is no longer valid
  (e.g., user-not-present or offline scenarios where there is no longer any user entertaining
  an active session with the client).
  Profiles or deployments of this specification should clearly document the conditions
  under which a client should expect a refresh token in response to
  <code>urn:ietf:params:oauth:grant-type:token-exchange</code>
  grant type requests.<a href="#section-2.2.1-2.12" class="pilcrow">¶</a>
</dd>
</dl>
</section>
</div>
<div id="ErrorResponse">
<section id="section-2.2.2">
          <h4 id="name-error-response">
<a href="#section-2.2.2" class="section-number selfRef">2.2.2. </a><a href="#name-error-response" class="section-name selfRef">Error Response</a>
          </h4>
<p id="section-2.2.2-1">
    If the request itself is not valid or if either the <code>subject_token</code> or <code>actor_token</code> are invalid for any reason, or are
    unacceptable based on policy, the authorization server <span class="bcp14">MUST</span> construct an
    error response, 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>.
    The value of the <code>error</code> parameter <span class="bcp14">MUST</span> be the
    <code>invalid_request</code> error code.<a href="#section-2.2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2.2-2">
    If the authorization server is unwilling or unable to issue a token for any target service
    indicated by the <code>resource</code> or <code>audience</code> parameters,
    the <code>invalid_target</code> error code <span class="bcp14">SHOULD</span> be used in the error response.<a href="#section-2.2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.2.2-3">
    The authorization
    server <span class="bcp14">MAY</span> include additional information regarding the reasons for the error
    using the <code>error_description</code> as discussed 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-2.2.2-3" class="pilcrow">¶</a></p>
<p id="section-2.2.2-4">
    Other error codes may also be used, as appropriate.<a href="#section-2.2.2-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="MainExample">
<section id="section-2.3">
        <h3 id="name-example-token-exchange">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-example-token-exchange" class="section-name selfRef">Example Token Exchange</a>
        </h3>
<p id="section-2.3-1">
  The following example demonstrates a hypothetical token exchange in which
  an OAuth resource server
  assumes the role of the client during the exchange. It
  trades an access token, which it received in a protected resource request, for a new
  token that it will use to call to a backend service
  (extra line breaks and indentation in the examples are for display purposes only).<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.3-2">
  <a href="#main-prr" class="xref">Figure 1</a> shows the resource server receiving a protected resource request containing
  an OAuth access token in the Authorization header, as specified in
  <span><a href="https://www.rfc-editor.org/rfc/rfc6750#section-2.1" class="relref">Section 2.1</a> of [<a href="#RFC6750" class="xref">RFC6750</a>]</span>.<a href="#section-2.3-2" class="pilcrow">¶</a></p>
<span id="name-protected-resource-request"></span><div id="main-prr">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-2.3-3.1">
<pre>
 GET /resource HTTP/1.1
 Host: frontend.example.com
 Authorization: Bearer accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-protected-resource-request" class="selfRef">Protected Resource Request</a>
          </figcaption></figure>
</div>
<p id="section-2.3-4">
  In <a href="#main-tereq" class="xref">Figure 2</a>, the resource server assumes the role of
  client for the token exchange, and the access token from the request in
  <a href="#main-prr" class="xref">Figure 1</a> is sent to the authorization server using a
  request as specified in <a href="#Request" class="xref">Section 2.1</a>.  The value of the <code>subject_token</code> parameter carries the access token, and
  the value of the <code>subject_token_type</code> parameter
  indicates that it is an OAuth 2.0 access token.  The resource server, acting
  in the role of the client, uses its identifier and secret to authenticate to
  the authorization server using the HTTP Basic authentication scheme.  The
  <code>resource</code> parameter indicates the location of the
  backend service, &lt;https://backend.example.com/api&gt;, where the issued token
  will be used.<a href="#section-2.3-4" class="pilcrow">¶</a></p>
<span id="name-token-exchange-request"></span><div id="main-tereq">
<figure id="figure-2">
          <div class="artwork art-text alignLeft" id="section-2.3-5.1">
<pre>
 POST /as/token.oauth2 HTTP/1.1
 Host: as.example.com
 Authorization: Basic cnMwODpsb25nLXNlY3VyZS1yYW5kb20tc2VjcmV0
 Content-Type: application/x-www-form-urlencoded

 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
 &amp;resource=https%3A%2F%2Fbackend.example.com%2Fapi
 &amp;subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
 &amp;subject_token_type=
  urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-token-exchange-request" class="selfRef">Token Exchange Request</a>
          </figcaption></figure>
</div>
<p id="section-2.3-6">
  The authorization server validates the client credentials and the
  <code>subject_token</code> presented in the token
  exchange request. From the <code>resource</code>
  parameter, the authorization server is able to determine the
  appropriate policy to apply to the request and issues a token
  suitable for use at &lt;https://backend.example.com&gt;.
  The <code>access_token</code> parameter of the
  response shown in <a href="#main-teresp" class="xref">Figure 3</a> contains the new token, which is itself a bearer OAuth
  access token that is valid for one minute. The token happens to be
  a JWT; however, its structure and format are opaque to
  the client, so the <code>issued_token_type</code>
  indicates only that it is an access token.<a href="#section-2.3-6" class="pilcrow">¶</a></p>
<span id="name-token-exchange-response"></span><div id="main-teresp">
<figure id="figure-3">
          <div class="artwork art-text alignLeft" id="section-2.3-7.1">
<pre>
 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-cache, no-store

 {
  "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQiOiJo
    dHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2FzLmV
    4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1MzMsIn
    N1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQedw6rx
    f59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIWvmDCM
    y5-kdXjwhw",
  "issued_token_type":
      "urn:ietf:params:oauth:token-type:access_token",
  "token_type":"Bearer",
  "expires_in":60
 }
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-token-exchange-response" class="selfRef">Token Exchange Response</a>
          </figcaption></figure>
</div>
<p id="section-2.3-8">
  The resource server can then use the newly acquired access token in making
  a request to the backend server as illustrated in <a href="#main-beprr" class="xref">Figure 4</a>.<a href="#section-2.3-8" class="pilcrow">¶</a></p>
<span id="name-backend-protected-resource-"></span><div id="main-beprr">
<figure id="figure-4">
          <div class="artwork art-text alignLeft" id="section-2.3-9.1">
<pre>
 GET /api HTTP/1.1
 Host: backend.example.com
 Authorization: Bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQ
    iOiJodHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2
    FzLmV4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1M
    zMsInN1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQe
    dw6rxf59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIW
    vmDCMy5-kdXjwhw
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-backend-protected-resource-" class="selfRef">Backend Protected Resource Request</a>
          </figcaption></figure>
</div>
<p id="section-2.3-10">
    Additional examples can be found in <a href="#AdditionalExamples" class="xref">Appendix A</a>.<a href="#section-2.3-10" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="TokenTypeIdentifiers">
<section id="section-3">
      <h2 id="name-token-type-identifiers">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-token-type-identifiers" class="section-name selfRef">Token Type Identifiers</a>
      </h2>
<p id="section-3-1">
  Several parameters in this specification utilize an identifier as the value to
  describe the token in question.
  Specifically, they are the
  <code>requested_token_type</code>,
  <code>subject_token_type</code>, and <code>actor_token_type</code>
  parameters of the request and the <code>issued_token_type</code> member of the response.
  Token type identifiers are URIs.
  Token exchange can work with both tokens issued by other parties and tokens from
  the given authorization server. For the former, the token type identifier indicates
  the syntax (e.g., JWT or SAML 2.0) so the authorization server can parse it; for the latter, it indicates
  what the given authorization server issued it for (e.g., <code>access_token</code> or <code>refresh_token</code>).<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
  The following token type identifiers are defined by this specification.
  Other URIs <span class="bcp14">MAY</span> be used to indicate other token types.<a href="#section-3-2" class="pilcrow">¶</a></p>
<dl class="dlNewline" id="section-3-3">
        <dt id="section-3-3.1">urn:ietf:params:oauth:token-type:access_token</dt>
<dd id="section-3-3.2">
    Indicates that the token is an OAuth 2.0 access token issued by the given authorization server.<a href="#section-3-3.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3-3.3">urn:ietf:params:oauth:token-type:refresh_token</dt>
<dd id="section-3-3.4">
    Indicates that the token is an OAuth 2.0 refresh token issued by the given authorization server.<a href="#section-3-3.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3-3.5">urn:ietf:params:oauth:token-type:id_token</dt>
<dd id="section-3-3.6">
    Indicates that the token is an ID Token as defined in Section 2 of <span>[<a href="#OpenID.Core" class="xref">OpenID.Core</a>]</span>.<a href="#section-3-3.6" class="pilcrow">¶</a>
</dd>
<dt id="section-3-3.7">urn:ietf:params:oauth:token-type:saml1</dt>
<dd id="section-3-3.8">
    Indicates that the token is a base64url-encoded SAML 1.1 <span>[<a href="#OASIS.saml-core-1.1" class="xref">OASIS.saml-core-1.1</a>]</span> assertion.<a href="#section-3-3.8" class="pilcrow">¶</a>
</dd>
<dt id="section-3-3.9">urn:ietf:params:oauth:token-type:saml2</dt>
<dd id="section-3-3.10">
    Indicates that the token is a base64url-encoded SAML 2.0 <span>[<a href="#OASIS.saml-core-2.0-os" class="xref">OASIS.saml-core-2.0-os</a>]</span> assertion.<a href="#section-3-3.10" class="pilcrow">¶</a>
</dd>
</dl>
<p id="section-3-4">
  The value <code>urn:ietf:params:oauth:token-type:jwt</code>, which is defined in
  <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-9" class="relref">Section 9</a> of [<a href="#RFC7519" class="xref">JWT</a>]</span>, indicates that the token is a JWT.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">
  The distinction between an access token and a JWT is subtle.
  An access token represents a delegated authorization decision, whereas JWT is a token format.
  An access token can be formatted as a JWT but doesn't necessarily have to be. And a
  JWT might well be an access token, but not all JWTs are access tokens.

  The intent of this specification is that <code>urn:ietf:params:oauth:token-type:access_token</code>
  be an indicator that the token is a typical OAuth access token issued by the authorization server in question, opaque to the client,
  and usable the same manner as any other access token obtained from that authorization server.
  (It could well be a JWT, but the client isn't and needn't be aware of that fact.)
  Whereas, <code>urn:ietf:params:oauth:token-type:jwt</code> is to indicate specifically that a JWT is
  being requested or sent (perhaps in a cross-domain use case where the JWT is used as an authorization grant to
  obtain an access token from a different authorization server as is facilitated by <span>[<a href="#RFC7523" class="xref">RFC7523</a>]</span>).<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">
  Note that for tokens that are binary in nature, the URI used for conveying them
  needs to be associated with the semantics of a base64 or other
  encoding suitable for usage with HTTP and OAuth.<a href="#section-3-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="JWTClaims">
<section id="section-4">
      <h2 id="name-json-web-token-claims-and-i">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-json-web-token-claims-and-i" class="section-name selfRef">JSON Web Token Claims and Introspection Response Parameters</a>
      </h2>
<p id="section-4-1">
   It is useful to have defined mechanisms to express delegation within a
   token as well as to express authorization to delegate or
   impersonate. Although the token exchange protocol described herein can be
   used with any type of token, this section defines claims to express such
   semantics specifically for JWTs and in an OAuth 2.0 Token Introspection <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span> response.  Similar
   definitions for other types of tokens are possible but beyond the scope of
   this specification.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
   Note that the claims not established herein but used in examples and descriptions,
   such as <code>iss</code>, <code>sub</code>,
   <code>exp</code>, etc., are defined by <span>[<a href="#RFC7519" class="xref">JWT</a>]</span>.<a href="#section-4-2" class="pilcrow">¶</a></p>
<div id="actor">
<section id="section-4.1">
        <h3 id="name-act-actor-claim">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-act-actor-claim" class="section-name selfRef">"act" (Actor) Claim</a>
        </h3>
<p id="section-4.1-1">
      The <code>act</code> (actor) claim provides a means
      within a JWT to express that delegation has occurred and identify the
      acting party to whom authority has been delegated.  The <code>act</code> claim value is a JSON object, and members in
      the JSON object are claims that identify the actor.  The claims that
      make up the <code>act</code> claim identify and possibly
      provide additional information about the actor.  For example, the
      combination of the two claims <code>iss</code> and <code>sub</code> might be necessary to uniquely identify an
      actor.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">
      However, claims within the <code>act</code> claim pertain only to the identity of the actor
      and are not relevant to the validity of the containing JWT in the same manner as the top-level claims.
      Consequently, non-identity claims (e.g., <code>exp</code>, <code>nbf</code>,
      and <code>aud</code>) are not meaningful when used within an
      <code>act</code> claim and are therefore not used.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3"><a href="#act-ex" class="xref">Figure 5</a> illustrates the <code>act</code> (actor) claim within a JWT Claims Set.  The
        claims of the token itself are about user@example.com while the <code>act</code> claim indicates that admin@example.com is the
        current actor.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<span id="name-actor-claim"></span><div id="act-ex">
<figure id="figure-5">
          <div id="section-4.1-4.1">
<pre class="sourcecode lang-json">
 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "nbf":1443904077,
   "sub":"user@example.com",
   "act":
   {
     "sub":"admin@example.com"
   }
 }</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-actor-claim" class="selfRef">Actor Claim</a>
          </figcaption></figure>
</div>
<p id="section-4.1-5">
      A chain of delegation can be expressed by nesting one <code>act</code> claim within
      another. The outermost <code>act</code> claim represents the current actor while nested
      <code>act</code> claims represent prior actors. The least recent actor is the most deeply
      nested. The nested <code>act</code> claims
      serve as a history trail that connects the initial request and subject
      through the various delegation steps undertaken before reaching the
      current actor.  In this sense, the current actor is considered to
      include the entire authorization/delegation history, leading naturally
      to the nested structure described here.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
<p id="section-4.1-6">
      For the purpose of applying access control policy, the consumer of a token <span class="bcp14">MUST</span> only consider the token's
      top-level claims and the party identified as the current actor by the <code>act</code>
      claim. Prior actors identified by any nested <code>act</code> claims are
      informational only and are not to be considered in access control decisions.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
<p id="section-4.1-7">
        The following example in <a href="#acts-ex" class="xref">Figure 6</a> illustrates nested <code>act</code> (actor) claims within a JWT Claims Set.
        The claims of the token itself are about user@example.com while the <code>act</code> claim indicates
        that the system &lt;https://service16.example.com&gt; is the current actor and &lt;https://service77.example.com&gt; was a prior actor.
        Such a token might come about as the result of service16 receiving a token in a call from service77
        and exchanging it for a token suitable to call service26 while the authorization server
        notes the situation in the newly issued token.<a href="#section-4.1-7" class="pilcrow">¶</a></p>
<span id="name-nested-actor-claim"></span><div id="acts-ex">
<figure id="figure-6">
          <div id="section-4.1-8.1">
<pre class="sourcecode lang-json">
 {
   "aud":"https://service26.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904100,
   "nbf":1443904000,
   "sub":"user@example.com",
   "act":
   {
     "sub":"https://service16.example.com",
     "act":
     {
       "sub":"https://service77.example.com"
     }
   }
 }
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-nested-actor-claim" class="selfRef">Nested Actor Claim</a>
          </figcaption></figure>
</div>
<p id="section-4.1-9">
      When included as a top-level member of an OAuth token introspection response, <code>act</code>
      has the same semantics and format as the claim of the same name.<a href="#section-4.1-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="scopes">
<section id="section-4.2">
        <h3 id="name-scope-scopes-claim">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-scope-scopes-claim" class="section-name selfRef">"scope" (Scopes) Claim</a>
        </h3>
<p id="section-4.2-1">
      The value of the <code>scope</code> claim is a
      JSON string containing a space-separated list of
      scopes associated with the token, in the format described 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>.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2"><a href="#scope-ex" class="xref">Figure 7</a> illustrates the <code>scope</code> claim within a JWT Claims Set.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<span id="name-scopes-claim"></span><div id="scope-ex">
<figure id="figure-7">
          <div id="section-4.2-3.1">
<pre class="sourcecode lang-json">
 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "nbf":1443904077,
   "sub":"dgaf4mvfs75Fci_FL3heQA",
   "scope":"email profile phone address"
 }
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-scopes-claim" class="selfRef">Scopes Claim</a>
          </figcaption></figure>
</div>
<p id="section-4.2-4">
      <span><a href="#RFC7662" class="xref">OAuth 2.0 Token Introspection</a> [<a href="#RFC7662" class="xref">RFC7662</a>]</span> already defines the <code>scope</code>
      parameter to convey the scopes associated with the token.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="client_id">
<section id="section-4.3">
        <h3 id="name-client_id-client-identifier">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-client_id-client-identifier" class="section-name selfRef">"client_id" (Client Identifier) Claim</a>
        </h3>
<p id="section-4.3-1">
      The <code>client_id</code> claim carries the
      client identifier of the <span><a href="#RFC6749" class="xref">OAuth 2.0</a> [<a href="#RFC6749" class="xref">RFC6749</a>]</span> client that
      requested the token.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">
        The following example in <a href="#client_id-ex" class="xref">Figure 8</a> illustrates the <code>client_id</code> claim within a JWT Claims Set
        indicating an OAuth 2.0 client with "s6BhdRkqt3" as its identifier.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<span id="name-client-identifier-claim"></span><div id="client_id-ex">
<figure id="figure-8">
          <div id="section-4.3-3.1">
<pre class="sourcecode lang-json">
 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "sub":"user@example.com",
   "client_id":"s6BhdRkqt3"
 }
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-client-identifier-claim" class="selfRef">Client Identifier Claim</a>
          </figcaption></figure>
</div>
<p id="section-4.3-4">
      <span><a href="#RFC7662" class="xref">OAuth 2.0 Token Introspection</a> [<a href="#RFC7662" class="xref">RFC7662</a>]</span> already defines the <code>client_id</code>
      parameter as the client identifier for the OAuth 2.0 client that requested the token.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="may_act">
<section id="section-4.4">
        <h3 id="name-may_act-authorized-actor-cl">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-may_act-authorized-actor-cl" class="section-name selfRef">"may_act" (Authorized Actor) Claim</a>
        </h3>
<p id="section-4.4-1">
      The <code>may_act</code> claim makes a statement that one party is authorized to
      become the actor and act on behalf of another party.
      The claim might be used, for example, when a <code>subject_token</code> is
      presented to the token endpoint in a token exchange request and
      <code>may_act</code> claim in the subject token can be used by the authorization
      server to determine whether the client (or party identified in the
      <code>actor_token</code>) is authorized to engage in the requested delegation or
      impersonation.
      The claim value is a JSON object, and members in the JSON object are claims that identify the party that
      is asserted as being eligible to act for the party identified by
      the JWT containing the claim.
      The claims that make up the <code>may_act</code>
      claim identify and possibly provide additional information about the authorized actor.
      For example, the combination of the two claims <code>iss</code>
      and <code>sub</code> are sometimes necessary to uniquely identify an authorized actor,
      while the <code>email</code> claim might be used to provide additional useful information about
      that party.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">
      However, claims within the <code>may_act</code> claim pertain only to the identity of that party
      and are not relevant to the validity of the containing JWT
      in the same manner as top-level claims.
      Consequently, claims such as <code>exp</code>, <code>nbf</code>, and
      <code>aud</code> are not meaningful when used within a <code>may_act</code>
      claim and are therefore not used.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3"><a href="#may_act-ex" class="xref">Figure 9</a> illustrates the <code>may_act</code> claim within a JWT Claims Set.
        The claims of the token itself are about user@example.com while the <code>may_act</code> claim indicates
        that admin@example.com is authorized to act on behalf of user@example.com.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<span id="name-authorized-actor-claim"></span><div id="may_act-ex">
<figure id="figure-9">
          <div id="section-4.4-4.1">
<pre class="sourcecode lang-json">
 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "nbf":1443904077,
   "sub":"user@example.com",
   "may_act":
   {
     "sub":"admin@example.com"
   }
 }
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-authorized-actor-claim" class="selfRef">Authorized Actor Claim</a>
          </figcaption></figure>
</div>
<p id="section-4.4-5">
      When included as a top-level member of an OAuth token introspection response, <code>may_act</code>
      has the same semantics and format as the claim of the same name.<a href="#section-4.4-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="Security">
<section id="section-5">
      <h2 id="name-security-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-5-1">
        Much of the guidance from <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-10" class="relref">Section 10</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span>,
        the Security Considerations in The OAuth 2.0 Authorization Framework,
        is also applicable here.
        Furthermore, <span>[<a href="#RFC6819" class="xref">RFC6819</a>]</span>
        provides additional security considerations for OAuth, and
        <span>[<a href="#I-D.ietf-oauth-security-topics" class="xref">OAUTH-SECURITY</a>]</span>
        has updated security guidance based on deployment experience and new threats that have
        emerged since OAuth 2.0 was originally published.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
        All of the normal security issues that are discussed in <span>[<a href="#RFC7519" class="xref">JWT</a>]</span>,
        especially in relationship to comparing URIs and dealing with unrecognized values,
        also apply here.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">
        In addition, both delegation and impersonation introduce unique
        security issues.  Any time one principal is delegated the rights of
        another principal, the potential for abuse is a concern.  The use of
        the <code>scope</code> claim (in addition to other
        typical constraints such as a limited token lifetime) is suggested to
        mitigate potential for such abuse, as it restricts the contexts in
        which the delegated rights can be exercised.<a href="#section-5-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Privacy">
<section id="section-6">
      <h2 id="name-privacy-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
      </h2>
<p id="section-6-1">
        Tokens employed in the context of the functionality described herein
        may contain privacy-sensitive information and, to prevent
        disclosure of such information to unintended parties, <span class="bcp14">MUST</span> only be
        transmitted over encrypted channels, such as Transport Layer Security
        (TLS).  In cases where it is desirable to prevent disclosure of certain
        information to the client, the token <span class="bcp14">MUST</span> be encrypted to its
        intended recipient. Deployments <span class="bcp14">SHOULD</span> determine the minimally necessary
        amount of data and only include such information in issued tokens.
        In some cases, data minimization may include representing only an
        anonymous or pseudonymous user.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<div id="URIReg">
<section id="section-7.1">
        <h3 id="name-oauth-uri-registration">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-oauth-uri-registration" class="section-name selfRef">OAuth URI Registration</a>
        </h3>
<p id="section-7.1-1">
   IANA has registered the following values in the
   "OAuth URI" subregistry of the "OAuth Parameters" registry
   <span>[<a href="#IANA.OAuth.Parameters" class="xref">IANA.OAuth.Parameters</a>]</span>. The "OAuth URI" subregistry was
   established by <span>[<a href="#RFC6755" class="xref">RFC6755</a>]</span>.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-7.1-2.1">URN: urn:ietf:params:oauth:grant-type:token-exchange<a href="#section-7.1-2.1" class="pilcrow">¶</a>
</li>
<li id="section-7.1-2.2">Common Name: Token exchange grant type for OAuth 2.0<a href="#section-7.1-2.2" class="pilcrow">¶</a>
</li>
<li id="section-7.1-2.3">Change Controller: IESG<a href="#section-7.1-2.3" class="pilcrow">¶</a>
</li>
<li id="section-7.1-2.4">Specification Document: <a href="#Request" class="xref">Section 2.1</a> of RFC 8693<a href="#section-7.1-2.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.1-3.1">URN: urn:ietf:params:oauth:token-type:access_token<a href="#section-7.1-3.1" class="pilcrow">¶</a>
</li>
<li id="section-7.1-3.2">Common Name: Token type URI for an OAuth 2.0 access token<a href="#section-7.1-3.2" class="pilcrow">¶</a>
</li>
<li id="section-7.1-3.3">Change Controller: IESG<a href="#section-7.1-3.3" class="pilcrow">¶</a>
</li>
<li id="section-7.1-3.4">Specification Document: <a href="#TokenTypeIdentifiers" class="xref">Section 3</a> of RFC 8693<a href="#section-7.1-3.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.1-4.1">URN: urn:ietf:params:oauth:token-type:refresh_token<a href="#section-7.1-4.1" class="pilcrow">¶</a>
</li>
<li id="section-7.1-4.2">Common Name: Token type URI for an OAuth 2.0 refresh token<a href="#section-7.1-4.2" class="pilcrow">¶</a>
</li>
<li id="section-7.1-4.3">Change Controller: IESG<a href="#section-7.1-4.3" class="pilcrow">¶</a>
</li>
<li id="section-7.1-4.4">Specification Document: <a href="#TokenTypeIdentifiers" class="xref">Section 3</a> of RFC 8693<a href="#section-7.1-4.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.1-5.1">URN: urn:ietf:params:oauth:token-type:id_token<a href="#section-7.1-5.1" class="pilcrow">¶</a>
</li>
<li id="section-7.1-5.2">Common Name: Token type URI for an ID Token<a href="#section-7.1-5.2" class="pilcrow">¶</a>
</li>
<li id="section-7.1-5.3">Change Controller: IESG<a href="#section-7.1-5.3" class="pilcrow">¶</a>
</li>
<li id="section-7.1-5.4">Specification Document: <a href="#TokenTypeIdentifiers" class="xref">Section 3</a> of RFC 8693<a href="#section-7.1-5.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.1-6.1">URN: urn:ietf:params:oauth:token-type:saml1<a href="#section-7.1-6.1" class="pilcrow">¶</a>
</li>
<li id="section-7.1-6.2">Common Name: Token type URI for a base64url-encoded SAML 1.1 assertion<a href="#section-7.1-6.2" class="pilcrow">¶</a>
</li>
<li id="section-7.1-6.3">Change Controller: IESG<a href="#section-7.1-6.3" class="pilcrow">¶</a>
</li>
<li id="section-7.1-6.4">Specification Document: <a href="#TokenTypeIdentifiers" class="xref">Section 3</a> of RFC 8693<a href="#section-7.1-6.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.1-7.1">URN: urn:ietf:params:oauth:token-type:saml2<a href="#section-7.1-7.1" class="pilcrow">¶</a>
</li>
<li id="section-7.1-7.2">Common Name: Token type URI for a base64url-encoded SAML 2.0 assertion<a href="#section-7.1-7.2" class="pilcrow">¶</a>
</li>
<li id="section-7.1-7.3">Change Controller: IESG<a href="#section-7.1-7.3" class="pilcrow">¶</a>
</li>
<li id="section-7.1-7.4">Specification Document: <a href="#TokenTypeIdentifiers" class="xref">Section 3</a> of RFC 8693<a href="#section-7.1-7.4" class="pilcrow">¶</a>
</li>
</ul>
</section>
</div>
<div id="OAuthParametersReg">
<section id="section-7.2">
        <h3 id="name-oauth-parameters-registrati">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-oauth-parameters-registrati" class="section-name selfRef">OAuth Parameters Registration</a>
        </h3>
<p id="section-7.2-1">
   IANA has registered the following values
   in the "OAuth Parameters" subregistry of the "OAuth Parameters" registry
   <span>[<a href="#IANA.OAuth.Parameters" class="xref">IANA.OAuth.Parameters</a>]</span>. The "OAuth Parameters"
   subregistry was
   established by <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-7.2-2.1">Parameter name: audience<a href="#section-7.2-2.1" class="pilcrow">¶</a>
</li>
<li id="section-7.2-2.2">Parameter usage location: token request<a href="#section-7.2-2.2" class="pilcrow">¶</a>
</li>
<li id="section-7.2-2.3">Change controller: IESG<a href="#section-7.2-2.3" class="pilcrow">¶</a>
</li>
<li id="section-7.2-2.4">Specification document(s): <a href="#Request" class="xref">Section 2.1</a> of RFC 8693<a href="#section-7.2-2.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.2-3.1">Parameter name: requested_token_type<a href="#section-7.2-3.1" class="pilcrow">¶</a>
</li>
<li id="section-7.2-3.2">Parameter usage location: token request<a href="#section-7.2-3.2" class="pilcrow">¶</a>
</li>
<li id="section-7.2-3.3">Change controller: IESG<a href="#section-7.2-3.3" class="pilcrow">¶</a>
</li>
<li id="section-7.2-3.4">Specification document(s): <a href="#Request" class="xref">Section 2.1</a> of RFC 8693<a href="#section-7.2-3.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.2-4.1">Parameter name: subject_token<a href="#section-7.2-4.1" class="pilcrow">¶</a>
</li>
<li id="section-7.2-4.2">Parameter usage location: token request<a href="#section-7.2-4.2" class="pilcrow">¶</a>
</li>
<li id="section-7.2-4.3">Change controller: IESG<a href="#section-7.2-4.3" class="pilcrow">¶</a>
</li>
<li id="section-7.2-4.4">Specification document(s): <a href="#Request" class="xref">Section 2.1</a> of RFC 8693<a href="#section-7.2-4.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.2-5.1">Parameter name: subject_token_type<a href="#section-7.2-5.1" class="pilcrow">¶</a>
</li>
<li id="section-7.2-5.2">Parameter usage location: token request<a href="#section-7.2-5.2" class="pilcrow">¶</a>
</li>
<li id="section-7.2-5.3">Change controller: IESG<a href="#section-7.2-5.3" class="pilcrow">¶</a>
</li>
<li id="section-7.2-5.4">Specification document(s): <a href="#Request" class="xref">Section 2.1</a> of RFC 8693<a href="#section-7.2-5.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.2-6.1">Parameter name: actor_token<a href="#section-7.2-6.1" class="pilcrow">¶</a>
</li>
<li id="section-7.2-6.2">Parameter usage location: token request<a href="#section-7.2-6.2" class="pilcrow">¶</a>
</li>
<li id="section-7.2-6.3">Change controller: IESG<a href="#section-7.2-6.3" class="pilcrow">¶</a>
</li>
<li id="section-7.2-6.4">Specification document(s): <a href="#Request" class="xref">Section 2.1</a> of RFC 8693<a href="#section-7.2-6.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.2-7.1">Parameter name: actor_token_type<a href="#section-7.2-7.1" class="pilcrow">¶</a>
</li>
<li id="section-7.2-7.2">Parameter usage location: token request<a href="#section-7.2-7.2" class="pilcrow">¶</a>
</li>
<li id="section-7.2-7.3">Change controller: IESG<a href="#section-7.2-7.3" class="pilcrow">¶</a>
</li>
<li id="section-7.2-7.4">Specification document(s): <a href="#Request" class="xref">Section 2.1</a> of RFC 8693<a href="#section-7.2-7.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.2-8.1">Parameter name: issued_token_type<a href="#section-7.2-8.1" class="pilcrow">¶</a>
</li>
<li id="section-7.2-8.2">Parameter usage location: token response<a href="#section-7.2-8.2" class="pilcrow">¶</a>
</li>
<li id="section-7.2-8.3">Change controller: IESG<a href="#section-7.2-8.3" class="pilcrow">¶</a>
</li>
<li id="section-7.2-8.4">Specification document(s): <a href="#SuccessfulResponse" class="xref">Section 2.2.1</a> of RFC 8693<a href="#section-7.2-8.4" class="pilcrow">¶</a>
</li>
</ul>
</section>
</div>
<div id="TokenTypeReg">
<section id="section-7.3">
        <h3 id="name-oauth-access-token-type-reg">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-oauth-access-token-type-reg" class="section-name selfRef">OAuth Access Token Type Registration</a>
        </h3>
<p id="section-7.3-1">
          IANA has registered the following access token type
   in the "OAuth Access Token Types" subregistry of the "OAuth
   Parameters" registry
   <span>[<a href="#IANA.OAuth.Parameters" class="xref">IANA.OAuth.Parameters</a>]</span>. The "OAuth Access Token
   Types" subregistry was
   established by <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-7.3-2.1">Type name: N_A<a href="#section-7.3-2.1" class="pilcrow">¶</a>
</li>
<li id="section-7.3-2.2">Additional Token Endpoint Response Parameters: none<a href="#section-7.3-2.2" class="pilcrow">¶</a>
</li>
<li id="section-7.3-2.3">HTTP Authentication Scheme(s): none<a href="#section-7.3-2.3" class="pilcrow">¶</a>
</li>
<li id="section-7.3-2.4">Change controller: IESG<a href="#section-7.3-2.4" class="pilcrow">¶</a>
</li>
<li id="section-7.3-2.5">Specification document(s): <a href="#SuccessfulResponse" class="xref">Section 2.2.1</a> of RFC 8693<a href="#section-7.3-2.5" class="pilcrow">¶</a>
</li>
</ul>
</section>
</div>
<div id="ClaimsReg">
<section id="section-7.4">
        <h3 id="name-json-web-token-claims-regis">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-json-web-token-claims-regis" class="section-name selfRef">JSON Web Token Claims Registration</a>
        </h3>
<p id="section-7.4-1">
   IANA has registered the following Claims
   in the "JSON Web Token Claims" subregistry of the "JSON Web Token
   (JWT)" registry
   <span>[<a href="#IANA.JWT" class="xref">IANA.JWT</a>]</span>. The "JSON Web Token Claims"
   subregistry was
   established by <span>[<a href="#RFC7519" class="xref">JWT</a>]</span>.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-7.4-2.1">Claim Name: act<a href="#section-7.4-2.1" class="pilcrow">¶</a>
</li>
<li id="section-7.4-2.2">Claim Description: Actor<a href="#section-7.4-2.2" class="pilcrow">¶</a>
</li>
<li id="section-7.4-2.3">Change Controller: IESG<a href="#section-7.4-2.3" class="pilcrow">¶</a>
</li>
<li id="section-7.4-2.4">Specification Document(s): <a href="#actor" class="xref">Section 4.1</a> of RFC 8693<a href="#section-7.4-2.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.4-3.1">Claim Name: scope<a href="#section-7.4-3.1" class="pilcrow">¶</a>
</li>
<li id="section-7.4-3.2">Claim Description: Scope Values<a href="#section-7.4-3.2" class="pilcrow">¶</a>
</li>
<li id="section-7.4-3.3">Change Controller: IESG<a href="#section-7.4-3.3" class="pilcrow">¶</a>
</li>
<li id="section-7.4-3.4">Specification Document(s): <a href="#scopes" class="xref">Section 4.2</a> of RFC 8693<a href="#section-7.4-3.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.4-4.1">Claim Name: client_id<a href="#section-7.4-4.1" class="pilcrow">¶</a>
</li>
<li id="section-7.4-4.2">Claim Description: Client Identifier<a href="#section-7.4-4.2" class="pilcrow">¶</a>
</li>
<li id="section-7.4-4.3">Change Controller: IESG<a href="#section-7.4-4.3" class="pilcrow">¶</a>
</li>
<li id="section-7.4-4.4">Specification Document(s): <a href="#client_id" class="xref">Section 4.3</a> of RFC 8693<a href="#section-7.4-4.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.4-5.1">Claim Name: may_act<a href="#section-7.4-5.1" class="pilcrow">¶</a>
</li>
<li id="section-7.4-5.2">Claim Description: Authorized Actor - the party that is authorized to become the actor<a href="#section-7.4-5.2" class="pilcrow">¶</a>
</li>
<li id="section-7.4-5.3">Change Controller: IESG<a href="#section-7.4-5.3" class="pilcrow">¶</a>
</li>
<li id="section-7.4-5.4">Specification Document(s): <a href="#may_act" class="xref">Section 4.4</a> of RFC 8693<a href="#section-7.4-5.4" class="pilcrow">¶</a>
</li>
</ul>
</section>
</div>
<div id="IntrospectionReg">
<section id="section-7.5">
        <h3 id="name-oauth-token-introspection-r">
<a href="#section-7.5" class="section-number selfRef">7.5. </a><a href="#name-oauth-token-introspection-r" class="section-name selfRef">OAuth Token Introspection Response Registration</a>
        </h3>
<p id="section-7.5-1">
          IANA has registered the following values
          in the "OAuth Token Introspection Response" registry of the "OAuth
   Parameters" registry
          <span>[<a href="#IANA.OAuth.Parameters" class="xref">IANA.OAuth.Parameters</a>]</span>. The "OAuth Token
   Introspection Response" registry was
          established by <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>.<a href="#section-7.5-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-7.5-2.1">Name: act<a href="#section-7.5-2.1" class="pilcrow">¶</a>
</li>
<li id="section-7.5-2.2">Description: Actor<a href="#section-7.5-2.2" class="pilcrow">¶</a>
</li>
<li id="section-7.5-2.3">Change Controller: IESG<a href="#section-7.5-2.3" class="pilcrow">¶</a>
</li>
<li id="section-7.5-2.4">Specification Document(s): <a href="#actor" class="xref">Section 4.1</a> of RFC 8693<a href="#section-7.5-2.4" class="pilcrow">¶</a>
</li>
</ul>
<ul>
<li id="section-7.5-3.1">Name: may_act<a href="#section-7.5-3.1" class="pilcrow">¶</a>
</li>
<li id="section-7.5-3.2">Description: Authorized Actor - the party that is authorized to become the actor<a href="#section-7.5-3.2" class="pilcrow">¶</a>
</li>
<li id="section-7.5-3.3">Change Controller: IESG<a href="#section-7.5-3.3" class="pilcrow">¶</a>
</li>
<li id="section-7.5-3.4">Specification Document(s): <a href="#may_act" class="xref">Section 4.4</a> of RFC 8693<a href="#section-7.5-3.4" class="pilcrow">¶</a>
</li>
</ul>
</section>
</div>
</section>
</div>
<section id="section-8">
      <h2 id="name-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-normative-references">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="IANA.JWT">[IANA.JWT]</dt>
<dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"JSON Web Token (JWT)"</span>, <span>&lt;<a href="https://www.iana.org/assignments/jwt">https://www.iana.org/assignments/jwt</a>&gt;</span>. </dd>
<dt id="IANA.OAuth.Parameters">[IANA.OAuth.Parameters]</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>
<dt id="RFC7519">[JWT]</dt>
<dd>
<span class="refAuthor">Jones, M.</span><span class="refAuthor">, Bradley, J.</span><span class="refAuthor">, and 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">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>
<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">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>
<dt id="RFC3986">[RFC3986]</dt>
<dd>
<span class="refAuthor">Berners-Lee, T.</span><span class="refAuthor">, Fielding, R.</span><span class="refAuthor">, and 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">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>
<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">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>
<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">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>
<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">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>
<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">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>
</dl>
</section>
<section id="section-8.2">
        <h3 id="name-informative-references">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="OASIS.saml-core-1.1">[OASIS.saml-core-1.1]</dt>
<dd>
<span class="refAuthor">Maler, E.</span><span class="refAuthor">, Mishra, P.</span><span class="refAuthor">, and R. Philpott</span>, <span class="refTitle">"Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1"</span>, <span class="seriesInfo">OASIS Standard oasis-sstc-saml-core-1.1</span>, <time datetime="2003-09">September 2003</time>, <span>&lt;<a href="https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf">https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf</a>&gt;</span>. </dd>
<dt id="OASIS.saml-core-2.0-os">[OASIS.saml-core-2.0-os]</dt>
<dd>
<span class="refAuthor">Cantor, S.</span><span class="refAuthor">, Kemp, J.</span><span class="refAuthor">, Philpott, R.</span><span class="refAuthor">, and E. Maler</span>, <span class="refTitle">"Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0"</span>, <span class="seriesInfo">OASIS Standard saml-core-2.0-os</span>, <time datetime="2005-03">March 2005</time>, <span>&lt;<a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf</a>&gt;</span>. </dd>
<dt id="I-D.ietf-oauth-resource-indicators">[OAUTH-RESOURCE]</dt>
<dd>
<span class="refAuthor">Campbell, B.</span><span class="refAuthor">, Bradley, J.</span><span class="refAuthor">, and H. Tschofenig</span>, <span class="refTitle">"Resource Indicators for OAuth 2.0"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-oauth-resource-indicators-08</span>, <time datetime="2019-09-11">11 September 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-08">https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-08</a>&gt;</span>. </dd>
<dt id="I-D.ietf-oauth-security-topics">[OAUTH-SECURITY]</dt>
<dd>
<span class="refAuthor">Lodderstedt, T.</span><span class="refAuthor">, Bradley, J.</span><span class="refAuthor">, Labunets, A.</span><span class="refAuthor">, and D. Fett</span>, <span class="refTitle">"OAuth 2.0 Security Best Current Practice"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-oauth-security-topics-13</span>, <time datetime="2019-07-08">8 July 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13">https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13</a>&gt;</span>. </dd>
<dt id="OpenID.Core">[OpenID.Core]</dt>
<dd>
<span class="refAuthor">Sakimura, N.</span><span class="refAuthor">, Bradley, J.</span><span class="refAuthor">, Jones, M.</span><span class="refAuthor">, de Medeiros, B.</span><span class="refAuthor">, and C. Mortimore</span>, <span class="refTitle">"OpenID Connect Core 1.0"</span>, <time datetime="2014-11">November 2014</time>, <span>&lt;<a href="https://openid.net/specs/openid-connect-core-1_0.html">https://openid.net/specs/openid-connect-core-1_0.html</a>&gt;</span>. </dd>
<dt id="RFC6750">[RFC6750]</dt>
<dd>
<span class="refAuthor">Jones, M.</span><span class="refAuthor"> and 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">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>
<dt id="RFC6755">[RFC6755]</dt>
<dd>
<span class="refAuthor">Campbell, B.</span><span class="refAuthor"> and H. Tschofenig</span>, <span class="refTitle">"An IETF URN Sub-Namespace for OAuth"</span>, <span class="seriesInfo">RFC 6755</span>, <span class="seriesInfo">DOI 10.17487/RFC6755</span>, <time datetime="2012-10">October 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6755">https://www.rfc-editor.org/info/rfc6755</a>&gt;</span>. </dd>
<dt id="RFC6819">[RFC6819]</dt>
<dd>
<span class="refAuthor">Lodderstedt, T., Ed.</span><span class="refAuthor">, McGloin, M.</span><span class="refAuthor">, and 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">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>
<dt id="RFC7521">[RFC7521]</dt>
<dd>
<span class="refAuthor">Campbell, B.</span><span class="refAuthor">, Mortimore, C.</span><span class="refAuthor">, Jones, M.</span><span class="refAuthor">, and 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">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>
<dt id="RFC7523">[RFC7523]</dt>
<dd>
<span class="refAuthor">Jones, M.</span><span class="refAuthor">, Campbell, B.</span><span class="refAuthor">, and C. Mortimore</span>, <span class="refTitle">"JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants"</span>, <span class="seriesInfo">RFC 7523</span>, <span class="seriesInfo">DOI 10.17487/RFC7523</span>, <time datetime="2015-05">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7523">https://www.rfc-editor.org/info/rfc7523</a>&gt;</span>. </dd>
<dt id="WS-Trust">[WS-Trust]</dt>
<dd>
<span class="refAuthor">Nadalin, A., Ed.</span><span class="refAuthor">, Goodner, M., Ed.</span><span class="refAuthor">, Gudgin, M., Ed.</span><span class="refAuthor">, Barbir, A., Ed.</span><span class="refAuthor">, and H. Granqvist, Ed.</span>, <span class="refTitle">"WS-Trust 1.4"</span>, <time datetime="2012-02">February 2012</time>, <span>&lt;<a href="https://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html">https://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html</a>&gt;</span>. </dd>
</dl>
</section>
</section>
<div id="AdditionalExamples">
<section id="section-appendix.a">
      <h2 id="name-additional-token-exchange-e">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-additional-token-exchange-e" class="section-name selfRef">Additional Token Exchange Examples</a>
      </h2>
<p id="section-appendix.a-1">
      Two example token exchanges are provided in the following sections
      illustrating impersonation and delegation, respectively
      (with extra line breaks and indentation for display purposes only).<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<div id="ImpersonationExample">
<section id="section-a.1">
        <h2 id="name-impersonation-token-exchang">
<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-impersonation-token-exchang" class="section-name selfRef">Impersonation Token Exchange Example</a>
        </h2>
<div id="ImpersonationRequest">
<section id="section-a.1.1">
          <h3 id="name-token-exchange-request-2">
<a href="#section-a.1.1" class="section-number selfRef">A.1.1. </a><a href="#name-token-exchange-request-2" class="section-name selfRef">Token Exchange Request</a>
          </h3>
<p id="section-a.1.1-1">
        In the following token exchange request, a client is requesting a token
        with impersonation semantics (delegation is impossible with only a <code>subject_token</code>
        and no <code>actor_token</code>).
        The client tells the authorization server that it needs a token for use at
        the target service with the logical name
 <code>urn:example:cooperation-context</code>.<a href="#section-a.1.1-1" class="pilcrow">¶</a></p>
<span id="name-token-exchange-request-3"></span><div id="ImpersonationRequestEx">
<figure id="figure-10">
            <div class="artwork art-text alignLeft" id="section-a.1.1-2.1">
<pre>
 POST /as/token.oauth2 HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded

 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
 &amp;audience=urn%3Aexample%3Acooperation-context
 &amp;subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc
   zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI
   uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTA2MDAsIm5iZiI6MTQ0MTkwOTAwMCwic
   3ViIjoiYmRjQGV4YW1wbGUubmV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN
   0b3J5In0.PRBg-jXn4cJuj1gmYXFiGkZzRuzbXZ_sDxdE98ddW44ufsbWLKd3JJ1VZ
   hF64pbTtfjy4VXFVBDaQpKjn5JzAw
 &amp;subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-token-exchange-request-3" class="selfRef">Token Exchange Request</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="ImpersonationSubjectClaims">
<section id="section-a.1.2">
          <h3 id="name-subject-token-claims">
<a href="#section-a.1.2" class="section-number selfRef">A.1.2. </a><a href="#name-subject-token-claims" class="section-name selfRef">Subject Token Claims</a>
          </h3>
<p id="section-a.1.2-1">
  The <code>subject_token</code> in the prior request is a JWT, and
  the decoded JWT Claims Set is shown here. The JWT is
  intended for consumption by the authorization server within a specific time window.
  The subject of the JWT (<code>bdc@example.net</code>) is
  the party on behalf of whom the new token is being requested.<a href="#section-a.1.2-1" class="pilcrow">¶</a></p>
<span id="name-subject-token-claims-2"></span><div id="ImpersonationSubjectClaimsEx">
<figure id="figure-11">
            <div id="section-a.1.2-2.1">
<pre class="sourcecode lang-json">
  {
    "aud":"https://as.example.com",
    "iss":"https://original-issuer.example.net",
    "exp":1441910600,
    "nbf":1441909000,
    "sub":"bdc@example.net",
    "scope":"orders profile history"
  }
</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
<a href="#name-subject-token-claims-2" class="selfRef">Subject Token Claims</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="ImpersonationResponse">
<section id="section-a.1.3">
          <h3 id="name-token-exchange-response-2">
<a href="#section-a.1.3" class="section-number selfRef">A.1.3. </a><a href="#name-token-exchange-response-2" class="section-name selfRef">Token Exchange Response</a>
          </h3>
<p id="section-a.1.3-1">
  The <code>access_token</code> parameter of the token exchange
  response shown below contains the new token that the client requested.
  The other parameters of the response indicate that the token is a bearer access token
  that expires in an hour.<a href="#section-a.1.3-1" class="pilcrow">¶</a></p>
<span id="name-token-exchange-response-3"></span><div id="ImpersonationResponseEx">
<figure id="figure-12">
            <div class="artwork art-text alignLeft" id="section-a.1.3-2.1">
<pre>
 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-cache, no-store

 {
  "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
    6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
    eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic3ViIjoiYmRjQGV4YW1wbGUub
    mV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN0b3J5In0.rMdWpSGNACTvnF
    uOL74sYZ6MVuld2Z2WkGLmQeR9ztj6w2OXraQlkJmGjyiCq24kcB7AI2VqVxl3wSW
    nVKh85A",
  "issued_token_type":
    "urn:ietf:params:oauth:token-type:access_token",
  "token_type":"Bearer",
  "expires_in":3600
 }
</pre>
</div>
<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
<a href="#name-token-exchange-response-3" class="selfRef">Token Exchange Response</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="ImpersonationIssuedClaims">
<section id="section-a.1.4">
          <h3 id="name-issued-token-claims">
<a href="#section-a.1.4" class="section-number selfRef">A.1.4. </a><a href="#name-issued-token-claims" class="section-name selfRef">Issued Token Claims</a>
          </h3>
<p id="section-a.1.4-1">
  The decoded JWT Claims Set of the issued token is shown below. The new JWT is
  issued by the authorization server and intended for consumption by a system entity
  known by the logical name <code>urn:example:cooperation-context</code>
  any time before its expiration.
  The subject (<code>sub</code>) of the JWT
  is the same as the subject the token used to make the request,
  which effectively enables the client to impersonate that subject
  at the system entity known by the logical name of
  <code>urn:example:cooperation-context</code> by using the token.<a href="#section-a.1.4-1" class="pilcrow">¶</a></p>
<span id="name-issued-token-claims-2"></span><div id="ImpersonationIssuedClaimsEx">
<figure id="figure-13">
            <div id="section-a.1.4-2.1">
<pre class="sourcecode lang-json">
  {
    "aud":"urn:example:cooperation-context",
    "iss":"https://as.example.com",
    "exp":1441913610,
    "sub":"bdc@example.net",
    "scope":"orders profile history"
  }
</pre>
</div>
<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
<a href="#name-issued-token-claims-2" class="selfRef">Issued Token Claims</a>
            </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
<div id="DelegationExample">
<section id="section-a.2">
        <h2 id="name-delegation-token-exchange-e">
<a href="#section-a.2" class="section-number selfRef">A.2. </a><a href="#name-delegation-token-exchange-e" class="section-name selfRef">Delegation Token Exchange Example</a>
        </h2>
<div id="DelegationRequest">
<section id="section-a.2.1">
          <h3 id="name-token-exchange-request-4">
<a href="#section-a.2.1" class="section-number selfRef">A.2.1. </a><a href="#name-token-exchange-request-4" class="section-name selfRef">Token Exchange Request</a>
          </h3>
<p id="section-a.2.1-1">
        In the following token exchange request, a client is requesting a token
        and providing both a <code>subject_token</code> and an <code>actor_token</code>.
        The client tells the authorization server that it needs a token for use at
        the target service with the logical name
 <code>urn:example:cooperation-context</code>. Policy at the
        authorization server dictates that the issued token be a composite.<a href="#section-a.2.1-1" class="pilcrow">¶</a></p>
<span id="name-token-exchange-request-5"></span><div id="DelegationRequestEx">
<figure id="figure-14">
            <div class="artwork art-text alignLeft" id="section-a.2.1-2.1">
<pre>
 POST /as/token.oauth2 HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded

 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
 &amp;audience=urn%3Aexample%3Acooperation-context
 &amp;subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc
   zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI
   uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInNjb3BlIjoic3RhdHVzIGZlZ
   WQiLCJzdWIiOiJ1c2VyQGV4YW1wbGUubmV0IiwibWF5X2FjdCI6eyJzdWIiOiJhZG1
   pbkBleGFtcGxlLm5ldCJ9fQ.4rPRSWihQbpMIgAmAoqaJojAxj-p2X8_fAtAGTXrvM
   xU-eEZHnXqY0_AOZgLdxw5DyLzua8H_I10MCcckF-Q_g
 &amp;subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
 &amp;actor_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwczo
   vL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXIuZ
   XhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInN1YiI6ImFkbWluQGV4YW1wbGU
   ubmV0In0.7YQ-3zPfhUvzje5oqw8COCvN5uP6NsKik9CVV6cAOf4QKgM-tKfiOwcgZ
   oUuDL2tEs6tqPlcBlMjiSzEjm3yBg
 &amp;actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
</pre>
</div>
<figcaption><a href="#figure-14" class="selfRef">Figure 14</a>:
<a href="#name-token-exchange-request-5" class="selfRef">Token Exchange Request</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="DelegationSubjectClaims">
<section id="section-a.2.2">
          <h3 id="name-subject-token-claims-3">
<a href="#section-a.2.2" class="section-number selfRef">A.2.2. </a><a href="#name-subject-token-claims-3" class="section-name selfRef">Subject Token Claims</a>
          </h3>
<p id="section-a.2.2-1">
        The <code>subject_token</code> in the prior request is a JWT, and
        the decoded JWT Claims Set is shown here. The JWT is
        intended for consumption by the authorization server
        before a specific expiration time.
 The subject of the JWT
 (<code>user@example.net</code>) is
 the party on behalf of whom the new token is being requested.<a href="#section-a.2.2-1" class="pilcrow">¶</a></p>
<span id="name-subject-token-claims-4"></span><div id="DelegationSubjectClaimsEx">
<figure id="figure-15">
            <div id="section-a.2.2-2.1">
<pre class="sourcecode lang-json">
  {
    "aud":"https://as.example.com",
    "iss":"https://original-issuer.example.net",
    "exp":1441910060,
    "scope":"status feed",
    "sub":"user@example.net",
    "may_act":
    {
      "sub":"admin@example.net"
    }
  }
</pre>
</div>
<figcaption><a href="#figure-15" class="selfRef">Figure 15</a>:
<a href="#name-subject-token-claims-4" class="selfRef">Subject Token Claims</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="DelegationActorClaims">
<section id="section-a.2.3">
          <h3 id="name-actor-token-claims">
<a href="#section-a.2.3" class="section-number selfRef">A.2.3. </a><a href="#name-actor-token-claims" class="section-name selfRef">Actor Token Claims</a>
          </h3>
<p id="section-a.2.3-1">
        The <code>actor_token</code> in the prior request is a JWT, and
        the decoded JWT Claims Set is shown here. This JWT is also
        intended for consumption by the authorization server
        before a specific expiration time.
 The subject of the JWT
 (<code>admin@example.net</code>) is
 the actor that will wield the security token being requested.<a href="#section-a.2.3-1" class="pilcrow">¶</a></p>
<span id="name-actor-token-claims-2"></span><div id="DelegationActorClaimsEx">
<figure id="figure-16">
            <div id="section-a.2.3-2.1">
<pre class="sourcecode lang-json">
  {
    "aud":"https://as.example.com",
    "iss":"https://original-issuer.example.net",
    "exp":1441910060,
    "sub":"admin@example.net"
  }
</pre>
</div>
<figcaption><a href="#figure-16" class="selfRef">Figure 16</a>:
<a href="#name-actor-token-claims-2" class="selfRef">Actor Token Claims</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="DelegationResponse">
<section id="section-a.2.4">
          <h3 id="name-token-exchange-response-4">
<a href="#section-a.2.4" class="section-number selfRef">A.2.4. </a><a href="#name-token-exchange-response-4" class="section-name selfRef">Token Exchange Response</a>
          </h3>
<p id="section-a.2.4-1">
        The <code>access_token</code> parameter of the token exchange
        response shown below contains the new token that the client requested.
        The other parameters of the response indicate that the token is a JWT
 that expires in an hour and that the access token type is not applicable
 since the issued token is not an access token.<a href="#section-a.2.4-1" class="pilcrow">¶</a></p>
<span id="name-token-exchange-response-5"></span><div id="DelegationResponseEx">
<figure id="figure-17">
            <div class="artwork art-text alignLeft" id="section-a.2.4-2.1">
<pre>
 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-cache, no-store

 {
  "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
    6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
    eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic2NvcGUiOiJzdGF0dXMgZmVlZ
    CIsInN1YiI6InVzZXJAZXhhbXBsZS5uZXQiLCJhY3QiOnsic3ViIjoiYWRtaW5AZX
    hhbXBsZS5uZXQifX0.3paKl9UySKYB5ng6_cUtQ2qlO8Rc_y7Mea7IwEXTcYbNdwG
    9-G1EKCFe5fW3H0hwX-MSZ49Wpcb1SiAZaOQBtw",
  "issued_token_type":"urn:ietf:params:oauth:token-type:jwt",
  "token_type":"N_A",
  "expires_in":3600
 }
</pre>
</div>
<figcaption><a href="#figure-17" class="selfRef">Figure 17</a>:
<a href="#name-token-exchange-response-5" class="selfRef">Token Exchange Response</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="DelegationIssuedClaims">
<section id="section-a.2.5">
          <h3 id="name-issued-token-claims-3">
<a href="#section-a.2.5" class="section-number selfRef">A.2.5. </a><a href="#name-issued-token-claims-3" class="section-name selfRef">Issued Token Claims</a>
          </h3>
<p id="section-a.2.5-1">
        The decoded JWT Claims Set of the issued token is shown below. The new JWT is
        issued by the authorization server and intended for consumption by a system entity
        known by the logical name
 <code>urn:example:cooperation-context</code>
 any time before its expiration.
        The subject (<code>sub</code>)
  of the JWT
 is the same as the subject of
 the <code>subject_token</code> used to make the request.
  The actor (<code>act</code>) of the JWT is the same as the subject
 of the <code>actor_token</code> used to make the request.

        This indicates delegation and identifies
 <code>admin@example.net</code> as the current actor to whom authority
        has been delegated to act on behalf of <code>user@example.net</code>.<a href="#section-a.2.5-1" class="pilcrow">¶</a></p>
<span id="name-issued-token-claims-4"></span><div id="DelegationIssuedClaimsEx">
<figure id="figure-18">
            <div id="section-a.2.5-2.1">
<pre class="sourcecode lang-json">
  {
    "aud":"urn:example:cooperation-context",
    "iss":"https://as.example.com",
    "exp":1441913610,
    "scope":"status feed",
    "sub":"user@example.net",
    "act":
    {
      "sub":"admin@example.net"
    }
  }
</pre>
</div>
<figcaption><a href="#figure-18" class="selfRef">Figure 18</a>:
<a href="#name-issued-token-claims-4" class="selfRef">Issued Token Claims</a>
            </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="Acknowledgements">
<section id="section-appendix.b">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.b-1">
        This specification was developed within the OAuth Working Group, which
        includes dozens of active and dedicated participants.
        It was produced under the chairmanship of
        <span class="contact-name">Hannes Tschofenig</span>, <span class="contact-name">Derek  Atkins</span>, and <span class="contact-name">Rifaat Shekh-Yusef</span>,
        with <span class="contact-name">Kathleen Moriarty</span>, <span class="contact-name">Stephen  Farrell</span>, <span class="contact-name">Eric Rescorla</span>, <span class="contact-name">Roman  Danyliw</span>, and <span class="contact-name">Benjamin Kaduk</span> serving as
        Security Area Directors.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<p id="section-appendix.b-2">
        The following individuals contributed ideas, feedback, and wording
 to this specification:
 <span class="contact-name">Caleb Baker</span>,
  <span class="contact-name">Vittorio Bertocci</span>,
        <span class="contact-name">Mike Brown</span>,
  <span class="contact-name">Thomas Broyer</span>,
        <span class="contact-name">Roman Danyliw</span>,
 <span class="contact-name">William Denniss</span>,
  <span class="contact-name">Vladimir Dzhuvinov</span>,
        <span class="contact-name">Eric Fazendin</span>,
 <span class="contact-name">Phil Hunt</span>,
  <span class="contact-name">Benjamin Kaduk</span>,
 <span class="contact-name">Jason Keglovitz</span>,
  <span class="contact-name">Torsten Lodderstedt</span>,
        <span class="contact-name">Barry Leiba</span>,
  <span class="contact-name">Adam Lewis</span>,
  <span class="contact-name">James Manger</span>,
  <span class="contact-name">Nov Matake</span>,
 <span class="contact-name">Matt Miller</span>,
        <span class="contact-name">Hilarie Orman</span>,
 <span class="contact-name">Matthew Perry</span>,
  <span class="contact-name">Eric Rescorla</span>,
 <span class="contact-name">Justin Richer</span>,
<span class="contact-name">Adam Roach</span>,
  <span class="contact-name">Rifaat Shekh-Yusef</span>,
 <span class="contact-name">Scott Tomilson</span>,
 and
        <span class="contact-name">Hannes Tschofenig</span>.<a href="#section-appendix.b-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.c">
      <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">Michael B. Jones</span></div>
<div dir="auto" class="left"><span class="org">Microsoft</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mbj@microsoft.com" class="email">mbj@microsoft.com</a>
</div>
<div class="url">
<span>URI:</span>
<a href="https://self-issued.info/" class="url">https://self-issued.info/</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Anthony Nadalin</span></div>
<div dir="auto" class="left"><span class="org">Microsoft</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:tonynad@microsoft.com" class="email">tonynad@microsoft.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Brian Campbell (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Ping Identity</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:brian.d.campbell@gmail.com" class="email">brian.d.campbell@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">John Bradley</span></div>
<div dir="auto" class="left"><span class="org">Yubico</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ve7jtb@ve7jtb.com" class="email">ve7jtb@ve7jtb.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Chuck Mortimore</span></div>
<div dir="auto" class="left"><span class="org">Visa</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:chuck.mortimore@visa.com" class="email">chuck.mortimore@visa.com</a>
</div>
</address>
</section>
</div>
<script>var toc = document.getElementById("toc");
var tocToggle = toc.querySelector("h2");
var tocNav = toc.querySelector("nav");

// mobile menu toggle
tocToggle.onclick = function(event) {
    if (window.innerWidth < 1024) {
 var tocNavDisplay = tocNav.currentStyle ? tocNav.currentStyle.display : getComputedStyle(tocNav, null).display;
 if (tocNavDisplay == "none") {
     tocNav.style.display = "block";
 } else {
     tocNav.style.display = "none";
 }
    }
}

// toc anchor scroll to anchor
tocNav.addEventListener("click", function (event) {
    event.preventDefault();
    if (event.target.nodeName == 'A') {
 if (window.innerWidth < 1024) {
     tocNav.style.display = "none";
 }
 var href = event.target.getAttribute("href");
 var anchorId = href.substr(1);
 var anchor =  document.getElementById(anchorId);
 anchor.scrollIntoView(true);
 window.history.pushState("","",href);
    }
});

// switch toc mode when window resized
window.onresize = function () {
    if (window.innerWidth < 1024) {
 tocNav.style.display = "none";
    } else {
 tocNav.style.display = "block";
    }
}
</script>
</body>
</html>