File: rfc9101.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (3295 lines) | stat: -rw-r--r-- 161,853 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9101: The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)</title>
<meta content="Nat Sakimura" name="author">
<meta content="John Bradley" name="author">
<meta content="Michael B. Jones" name="author">
<meta content="
       The authorization request in OAuth 2.0 described in RFC 6749 utilizes
      query parameter serialization, which means that authorization request
      parameters are encoded in the URI of the request and sent through user
      agents such as web browsers.  While it is easy to implement, it means
      that a) the communication through the user agents is not integrity
      protected and thus, the parameters can be tainted, b) the source of
      the communication is not authenticated, and c) the communication
      through the user agents can be monitored.  Because of these weaknesses,
      several attacks to the protocol have now been put forward. 
       This document introduces the ability to send request parameters in a
      JSON Web Token (JWT) instead, which allows the request to be signed with
      JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so
      that the integrity, source authentication, and confidentiality
      properties of the authorization request are attained.  The request can
      be sent by value or by reference.
       
    " name="description">
<meta content="xml2rfc 3.9.1" name="generator">
<meta content="Assertion" name="keyword">
<meta content="Claim" name="keyword">
<meta content="Security Token" name="keyword">
<meta content="OAuth" name="keyword">
<meta content="JavaScript Object Notation" name="keyword">
<meta content="JSON" name="keyword">
<meta content="JSON Web Token" name="keyword">
<meta content="JWT" name="keyword">
<meta content="JSON Web Signature" name="keyword">
<meta content="JWS" name="keyword">
<meta content="JSON Web Encryption" name="keyword">
<meta content="JWE" name="keyword">
<meta content="9101" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.9.1
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc9101.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#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;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9101" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq-34" 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 9101</td>
<td class="center">OAuth JAR</td>
<td class="right">August 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Sakimura, 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/rfc9101" class="eref">9101</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="2021-08" class="published">August 2021</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">N. Sakimura</div>
<div class="org">NAT.Consulting</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">M. Jones</div>
<div class="org">Microsoft</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9101</h1>
<h1 id="title">The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">The authorization request in OAuth 2.0 described in RFC 6749 utilizes
      query parameter serialization, which means that authorization request
      parameters are encoded in the URI of the request and sent through user
      agents such as web browsers.  While it is easy to implement, it means
      that a) the communication through the user agents is not integrity
      protected and thus, the parameters can be tainted, b) the source of
      the communication is not authenticated, and c) the communication
      through the user agents can be monitored.  Because of these weaknesses,
      several attacks to the protocol have now been put forward.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">This document introduces the ability to send request parameters in a
      JSON Web Token (JWT) instead, which allows the request to be signed with
      JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so
      that the integrity, source authentication, and confidentiality
      properties of the authorization request are attained.  The request can
      be sent by value or by reference.<a href="#section-abstract-2" 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/rfc9101">https://www.rfc-editor.org/info/rfc9101</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) 2021 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="ulEmpty ulBare toc compact">
<li class="ulEmpty ulBare toc compact" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
<ul class="toc compact ulEmpty ulBare">
<li class="toc compact ulEmpty ulBare" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty ulBare toc compact" 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-terminology" class="xref">Terminology</a></p>
<ul class="toc compact ulEmpty ulBare">
<li class="toc compact ulEmpty ulBare" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-request-object" class="xref">Request Object</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" 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-request-object-uri" class="xref">Request Object URI</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty ulBare toc compact" 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-symbols-and-abbreviated-ter" class="xref">Symbols and Abbreviated Terms</a></p>
</li>
          <li class="ulEmpty ulBare toc compact" 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-request-object-2" class="xref">Request Object</a></p>
</li>
          <li class="ulEmpty ulBare toc compact" 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-authorization-request" class="xref">Authorization Request</a></p>
<ul class="toc compact ulEmpty ulBare">
<li class="toc compact ulEmpty ulBare" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-passing-a-request-object-by" class="xref">Passing a Request Object by Value</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-passing-a-request-object-by-" class="xref">Passing a Request Object by Reference</a></p>
<ul class="toc compact ulEmpty ulBare">
<li class="toc compact ulEmpty ulBare" id="section-toc.1-1.5.2.2.2.1">
                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-uri-referencing-the-request" class="xref">URI Referencing the Request Object</a></p>
</li>
                  <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.5.2.2.2.2">
                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-request-using-the-request_u" class="xref">Request Using the "request_uri" Request Parameter</a></p>
</li>
                  <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.5.2.2.2.3">
                    <p id="section-toc.1-1.5.2.2.2.3.1"><a href="#section-5.2.3" class="xref">5.2.3</a>.  <a href="#name-authorization-server-fetche" class="xref">Authorization Server Fetches Request Object</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty ulBare toc compact" 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-validating-jwt-based-reques" class="xref">Validating JWT-Based Requests</a></p>
<ul class="toc compact ulEmpty ulBare">
<li class="toc compact ulEmpty ulBare" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-jwe-encrypted-request-objec" class="xref">JWE Encrypted Request Object</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-jws-signed-request-object" class="xref">JWS-Signed Request Object</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-request-parameter-assembly-" class="xref">Request Parameter Assembly and Validation</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty ulBare toc compact" 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-authorization-server-respon" class="xref">Authorization Server Response</a></p>
</li>
          <li class="ulEmpty ulBare toc compact" 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-tls-requirements" class="xref">TLS Requirements</a></p>
</li>
          <li class="ulEmpty ulBare toc compact" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
<ul class="toc compact ulEmpty ulBare">
<li class="toc compact ulEmpty ulBare" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-oauth-parameters-registrati" class="xref">OAuth Parameters Registration</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-oauth-authorization-server-" class="xref">OAuth Authorization Server Metadata Registry</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.9.2.3">
                <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-oauth-dynamic-client-regist" class="xref">OAuth Dynamic Client Registration Metadata Registry</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.9.2.4">
                <p id="section-toc.1-1.9.2.4.1"><a href="#section-9.4" class="xref">9.4</a>.  <a href="#name-media-type-registration" class="xref">Media Type Registration</a></p>
<ul class="toc compact ulEmpty ulBare">
<li class="toc compact ulEmpty ulBare" id="section-toc.1-1.9.2.4.2.1">
                    <p id="section-toc.1-1.9.2.4.2.1.1"><a href="#section-9.4.1" class="xref">9.4.1</a>.  <a href="#name-registry-contents" class="xref">Registry Contents</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty ulBare toc compact" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
<ul class="toc compact ulEmpty ulBare">
<li class="toc compact ulEmpty ulBare" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-choice-of-algorithms" class="xref">Choice of Algorithms</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-request-source-authenticati" class="xref">Request Source Authentication</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#section-10.3" class="xref">10.3</a>.  <a href="#name-explicit-endpoints" class="xref">Explicit Endpoints</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.10.2.4">
                <p id="section-toc.1-1.10.2.4.1"><a href="#section-10.4" class="xref">10.4</a>.  <a href="#name-risks-associated-with-reque" class="xref">Risks Associated with request_uri</a></p>
<ul class="toc compact ulEmpty ulBare">
<li class="toc compact ulEmpty ulBare" id="section-toc.1-1.10.2.4.2.1">
                    <p id="section-toc.1-1.10.2.4.2.1.1"><a href="#section-10.4.1" class="xref">10.4.1</a>.  <a href="#name-ddos-attack-on-the-authoriz" class="xref">DDoS Attack on the Authorization Server</a></p>
</li>
                  <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.10.2.4.2.2">
                    <p id="section-toc.1-1.10.2.4.2.2.1"><a href="#section-10.4.2" class="xref">10.4.2</a>.  <a href="#name-request-uri-rewrite" class="xref">Request URI Rewrite</a></p>
</li>
                </ul>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.10.2.5">
                <p id="section-toc.1-1.10.2.5.1"><a href="#section-10.5" class="xref">10.5</a>.  <a href="#name-downgrade-attack" class="xref">Downgrade Attack</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.10.2.6">
                <p id="section-toc.1-1.10.2.6.1"><a href="#section-10.6" class="xref">10.6</a>.  <a href="#name-tls-security-considerations" class="xref">TLS Security Considerations</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.10.2.7">
                <p id="section-toc.1-1.10.2.7.1"><a href="#section-10.7" class="xref">10.7</a>.  <a href="#name-parameter-mismatches" class="xref">Parameter Mismatches</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.10.2.8">
                <p id="section-toc.1-1.10.2.8.1"><a href="#section-10.8" class="xref">10.8</a>.  <a href="#name-cross-jwt-confusion" class="xref">Cross-JWT Confusion</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty ulBare toc compact" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-privacy-considerations" class="xref">Privacy Considerations</a></p>
<ul class="toc compact ulEmpty ulBare">
<li class="toc compact ulEmpty ulBare" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-collection-limitation" class="xref">Collection Limitation</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-disclosure-limitation" class="xref">Disclosure Limitation</a></p>
<ul class="toc compact ulEmpty ulBare">
<li class="toc compact ulEmpty ulBare" id="section-toc.1-1.11.2.2.2.1">
                    <p id="section-toc.1-1.11.2.2.2.1.1"><a href="#section-11.2.1" class="xref">11.2.1</a>.  <a href="#name-request-disclosure" class="xref">Request Disclosure</a></p>
</li>
                  <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.11.2.2.2.2">
                    <p id="section-toc.1-1.11.2.2.2.2.1"><a href="#section-11.2.2" class="xref">11.2.2</a>.  <a href="#name-tracking-using-request-obje" class="xref">Tracking Using Request Object URI</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty ulBare toc compact" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="toc compact ulEmpty ulBare">
<li class="toc compact ulEmpty ulBare" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="xref">12.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="toc compact ulEmpty ulBare" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="xref">12.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty ulBare toc compact" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="ulEmpty ulBare toc compact" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<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">
   The authorization request in <span><a href="#RFC6749" class="xref">OAuth 2.0</a> [<a href="#RFC6749" class="xref">RFC6749</a>]</span>
   utilizes query parameter
      serialization and is typically sent through user agents such as web browsers.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
   For example, the parameters <code>response_type</code>, <code>client_id</code>, <code>state</code>, and <code>redirect_uri</code> are encoded in the URI of the request:<a href="#section-1-2" class="pilcrow">¶</a></p>
<div id="section-1-3">
<pre class="sourcecode lang-http-message">
    GET /authorize?response_type=code&amp;client_id=s6BhdRkqt3&amp;state=xyz
    &amp;redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com
</pre><a href="#section-1-3" class="pilcrow">¶</a>
</div>
<p id="section-1-4">
   While it is easy to implement,  the encoding in the URI 
   does not allow application-layer security to be used to
   provide confidentiality and integrity protection. 
   While TLS is used to offer communication security 
   between the client and the user agent as well as the user agent and the
   authorization server, TLS sessions are terminated in the user agent.
   In addition, TLS sessions may be terminated 
      prematurely at some middlebox (such as a load balancer).<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
   As a result, the authorization request of <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span> has
   shortcomings in that:<a href="#section-1-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-1-6">
        <dt>(a)</dt>
<dd id="section-1-6.1">the communication through the user agents is
 not integrity protected, and thus, the parameters can be tainted
 (integrity protection failure);<a href="#section-1-6.1" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(b)</dt>
<dd id="section-1-6.2">the source of the communication is not authenticated  
 (source authentication failure);<a href="#section-1-6.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(c)</dt>
<dd id="section-1-6.3">the communication through the user agents can be monitored
 (containment/confidentiality failure).<a href="#section-1-6.3" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-1-7">
   Due to these inherent weaknesses, several attacks against the
   protocol, such as redirection URI rewriting, have been identified.<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">
   The use of application-layer security mitigates these issues.<a href="#section-1-8" class="pilcrow">¶</a></p>
<p id="section-1-9">
      The use of application-layer security allows requests to be prepared by
      a trusted third party so that a client application cannot request more
      permissions than previously agreed upon.<a href="#section-1-9" class="pilcrow">¶</a></p>
<p id="section-1-10">
      Furthermore, passing the request by reference allows the reduction of over-the-wire overhead.<a href="#section-1-10" class="pilcrow">¶</a></p>
<p id="section-1-11">The <span><a href="#RFC7519" class="xref">JWT</a> [<a href="#RFC7519" class="xref">RFC7519</a>]</span> encoding has been chosen because of:<a href="#section-1-11" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-1-12">
        <dt>(1)</dt>
<dd id="section-1-12.1">its close relationship with JSON,
        which is used as OAuth's response format<a href="#section-1-12.1" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(2)</dt>
<dd id="section-1-12.2">its developer friendliness due to its textual nature<a href="#section-1-12.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(3)</dt>
<dd id="section-1-12.3">its relative compactness compared to XML<a href="#section-1-12.3" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(4)</dt>
<dd id="section-1-12.4">its development status as a Proposed Standard,  along
 with the associated signing and encryption methods
        <span>[<a href="#RFC7515" class="xref">RFC7515</a>]</span> <span>[<a href="#RFC7516" class="xref">RFC7516</a>]</span><a href="#section-1-12.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(5)</dt>
<dd id="section-1-12.5">the relative ease of JWS and JWE compared to XML Signature and Encryption.<a href="#section-1-12.5" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-1-13">The parameters <code>request</code> and <code>request_uri</code> are
      introduced as additional authorization request parameters for the <span><a href="#RFC6749" class="xref">OAuth 2.0</a> [<a href="#RFC6749" class="xref">RFC6749</a>]</span> flows. The <code>request</code> parameter
      is a <span><a href="#RFC7519" class="xref">JSON Web Token (JWT)</a> [<a href="#RFC7519" class="xref">RFC7519</a>]</span> whose JWT Claims
      Set holds the JSON-encoded OAuth 2.0 authorization request parameters.
      Note that, in contrast to RFC 7519, the elements of the Claims Set are
      encoded OAuth request parameters <span>[<a href="#IANA.OAuth.Parameters" class="xref">IANA.OAuth.Parameters</a>]</span>,
      supplemented with only a few of the IANA-managed JSON Web Token Claims
      <span>[<a href="#IANA.JWT.Claims" class="xref">IANA.JWT.Claims</a>]</span>, in particular, <code>iss</code> and
      <code>aud</code>.  The JWT in the <code>request</code> parameter is integrity
      protected and source authenticated using JWS.<a href="#section-1-13" class="pilcrow">¶</a></p>
<p id="section-1-14">
   The <span><a href="#RFC7519" class="xref">JWT</a> [<a href="#RFC7519" class="xref">RFC7519</a>]</span> can be passed to the authorization endpoint by reference,
      in which case the parameter <code>request_uri</code> is
      used instead of <code>request</code>.<a href="#section-1-14" class="pilcrow">¶</a></p>
<p id="section-1-15">Using <span><a href="#RFC7519" class="xref">JWT</a> [<a href="#RFC7519" class="xref">RFC7519</a>]</span> as the request encoding instead of query
      parameters has several advantages:<a href="#section-1-15" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-1-16">
        <dt>(a)</dt>
<dd id="section-1-16.1">Integrity protection.
   The request can be signed so that the integrity of the request can be checked.<a href="#section-1-16.1" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(b)</dt>
<dd id="section-1-16.2">Source authentication.
   The request can be signed so that the signer can be authenticated.<a href="#section-1-16.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(c)</dt>
<dd id="section-1-16.3">Confidentiality protection.
   The request can be encrypted so that end-to-end 
   confidentiality can be provided even if the TLS connection is 
   terminated at one point or another (including at and before user agents).<a href="#section-1-16.3" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(d)</dt>
<dd id="section-1-16.4">Collection minimization.  The request can be signed by a trusted
        third party attesting that the authorization request is compliant with
        a certain policy.  For example, a request can be pre-examined by a
        trusted third party to confirm that all the personal data requested is
        strictly necessary to perform the process that the end user asked for;
        the request would then be signed by that trusted third party.  The
        authorization server then examines the signature and shows the
        conformance status to the end user who would have some assurance as to
        the legitimacy of the request when authorizing it.  In some cases, it
        may even be desirable to skip the authorization dialogue under such
        circumstances.<a href="#section-1-16.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-1-17">There are a few cases where request by reference is useful, such as:<a href="#section-1-17" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-1-18">
        <li id="section-1-18.1">when it is desirable to reduce the size of a transmitted request.
        The use of application-layer security increases the size of the
        request particularly when public-key cryptography is used.<a href="#section-1-18.1" class="pilcrow">¶</a>
</li>
        <li id="section-1-18.2">when the client does not want to do the application-level
        cryptography.  The authorization server may provide an endpoint to
        accept the authorization request through direct communication with the
        client, so that the client is authenticated and the channel is TLS
        protected.<a href="#section-1-18.2" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-1-19">This capability is in use by OpenID Connect <span>[<a href="#OpenID.Core" class="xref">OpenID.Core</a>]</span>.<a href="#section-1-19" class="pilcrow">¶</a></p>
<section id="section-1.1">
        <h3 id="name-requirements-language">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
        </h3>
<p id="section-1.1-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.1-1" class="pilcrow">¶</a></p>
</section>
</section>
<div id="Terminology">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">For the purposes of this specification, the following terms and
      definitions apply in addition to what is defined in 
   <span><a href="#RFC6749" class="xref">OAuth 2.0 Framework</a> [<a href="#RFC6749" class="xref">RFC6749</a>]</span>, 
   <span><a href="#RFC7515" class="xref">JSON Web Signature</a> [<a href="#RFC7515" class="xref">RFC7515</a>]</span>, and 
   <span><a href="#RFC7516" class="xref">JSON Web Encryption</a> [<a href="#RFC7516" class="xref">RFC7516</a>]</span>.<a href="#section-2-1" class="pilcrow">¶</a></p>
<div id="request_object">
<section id="section-2.1">
        <h3 id="name-request-object">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-request-object" class="section-name selfRef">Request Object</a>
        </h3>
<p id="section-2.1-1">
   A Request Object is a <span><a href="#RFC7519" class="xref">JSON Web Token
   (JWT)</a> [<a href="#RFC7519" class="xref">RFC7519</a>]</span> whose JWT Claims
   Set holds the JSON-encoded OAuth 2.0 authorization request
   parameters.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="request_uri">
<section id="section-2.2">
        <h3 id="name-request-object-uri">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-request-object-uri" class="section-name selfRef">Request Object URI</a>
        </h3>
<p id="section-2.2-1">A Request Object URI is an absolute URI that references the set of
        parameters comprising an OAuth 2.0 authorization request.  The content
        of the resource referenced by the URI is a <span><a href="#request_object" class="xref">Request Object</a> (<a href="#request_object" class="xref">Section 2.1</a>)</span>, unless the URI was
        provided to the client by the same authorization server, in which case
        the content is an implementation detail at the discretion of the
        authorization server. The content being a Request Object is to ensure interoperability in
        cases where the provider of the <code>request_uri</code> is a separate
        entity from the consumer, such as when a client provides a URI
        referencing a Request Object stored on the client's backend service
        that is made accessible via HTTPS. In the latter case, where the
        authorization server is both provider and consumer of the URI, such as
        when it offers an endpoint that provides a URI in exchange for a
        Request Object, this interoperability concern does not apply.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="abbreviation">
<section id="section-3">
      <h2 id="name-symbols-and-abbreviated-ter">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-symbols-and-abbreviated-ter" class="section-name selfRef">Symbols and Abbreviated Terms</a>
      </h2>
<p id="section-3-1">
 The following abbreviations are common to this specification.<a href="#section-3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3-2">
        <dt id="section-3-2.1">JSON:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.2">JavaScript Object Notation<a href="#section-3-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.3">JWT:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.4">JSON Web Token<a href="#section-3-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.5">JWS:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.6">JSON Web Signature<a href="#section-3-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.7">JWE:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.8">JSON Web Encryption<a href="#section-3-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.9">URI:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.10">Uniform Resource Identifier<a href="#section-3-2.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.11">URL:</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.12">Uniform Resource Locator<a href="#section-3-2.12" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="authorization_request_object">
<section id="section-4">
      <h2 id="name-request-object-2">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-request-object-2" class="section-name selfRef">Request Object</a>
      </h2>
<p id="section-4-1">A <span><a href="#request_object" class="xref">Request Object</a> (<a href="#request_object" class="xref">Section 2.1</a>)</span> is used to
      provide authorization request parameters for an OAuth 2.0 authorization
      request. It <span class="bcp14">MUST</span> contain all the parameters (including extension
      parameters) used to process the <span><a href="#RFC6749" class="xref">OAuth 2.0</a> [<a href="#RFC6749" class="xref">RFC6749</a>]</span>
      authorization request except the <code>request</code> and
      <code>request_uri</code> parameters that are defined in
      this document.
   The parameters are represented as the JWT Claims of the object.
   Parameter names and string values <span class="bcp14">MUST</span> be included as JSON strings. 
   Since Request Objects are handled across domains and potentially 
   outside of a closed ecosystem, per <span><a href="https://www.rfc-editor.org/rfc/rfc8259#section-8.1" class="relref">Section 8.1</a> of [<a href="#RFC8259" class="xref">RFC8259</a>]</span>, 
   these JSON strings <span class="bcp14">MUST</span> be encoded using UTF-8 <span>[<a href="#RFC3629" class="xref">RFC3629</a>]</span>. 
   Numerical values <span class="bcp14">MUST</span> be included as JSON numbers. 
   The Request Object <span class="bcp14">MAY</span> include any extension parameters. 

   This <span><a href="#RFC8259" class="xref">JSON</a> [<a href="#RFC8259" class="xref">RFC8259</a>]</span> object constitutes the
      JWT Claims Set defined in <span><a href="#RFC7519" class="xref">JWT</a> [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.
   The JWT Claims Set is then signed or signed and encrypted.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">To sign, <span><a href="#RFC7515" class="xref">JSON Web Signature (JWS)</a> [<a href="#RFC7515" class="xref">RFC7515</a>]</span> is
      used.  The result is a JWS-signed <span><a href="#RFC7519" class="xref">JWT</a> [<a href="#RFC7519" class="xref">RFC7519</a>]</span>. If
      signed, the Authorization Request Object <span class="bcp14">SHOULD</span> contain
      the Claims <code>iss</code> (issuer) and <code>aud</code> (audience) as members
      with their semantics being the same as defined in the <span><a href="#RFC7519" class="xref">JWT</a> [<a href="#RFC7519" class="xref">RFC7519</a>]</span> specification.  The value of <code>aud</code>
      should be the value of the authorization server (AS) <code>issuer</code>, as
      defined in <span><a href="#RFC8414" class="xref">RFC 8414</a> [<a href="#RFC8414" class="xref">RFC8414</a>]</span>.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">To encrypt, <span><a href="#RFC7516" class="xref">JWE</a> [<a href="#RFC7516" class="xref">RFC7516</a>]</span> is used. 
   When both signature and encryption are being applied, 
   the JWT <span class="bcp14">MUST</span> be signed, then encrypted, as described in
   <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-11.2" class="relref">Section 11.2</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.
   The result is a Nested JWT, as defined in
   <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">
     The client determines the algorithms used to sign and encrypt
     Request Objects.  The algorithms chosen need to be supported by
     both the client and the authorization server.  The client can
     inform the authorization server of the algorithms that it supports
     in its dynamic client registration metadata <span>[<a href="#RFC7591" class="xref">RFC7591</a>]</span>, specifically, the metadata values
     <code>request_object_signing_alg</code>,
     <code>request_object_encryption_alg</code>, and
     <code>request_object_encryption_enc</code>.  Likewise, the
     authorization server can inform the client of the algorithms that
     it supports in its authorization server metadata <span>[<a href="#RFC8414" class="xref">RFC8414</a>]</span>, specifically, the metadata values
     <code>request_object_signing_alg_values_supported</code>,
     <code>request_object_encryption_alg_values_supported</code>, and
     <code>request_object_encryption_enc_values_supported</code>.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">
     The Request Object <span class="bcp14">MAY</span> be sent by value, as
     described in <a href="#RequestParameter" class="xref">Section 5.1</a>,
     or by reference, as described in <a href="#RequestUriParameter" class="xref">Section 5.2</a>.
     <code>request</code> and
     <code>request_uri</code> parameters
     <span class="bcp14">MUST NOT</span> be included in Request Objects.<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="section-4-6">
   A <span><a href="#request_object" class="xref">Request Object</a> (<a href="#request_object" class="xref">Section 2.1</a>)</span> has the media
   type <span>[<a href="#RFC2046" class="xref">RFC2046</a>]</span>
        <code>application/oauth-authz-req+jwt</code>.  Note that some existing
   deployments may alternatively be using the type
   <code>application/jwt</code>.<a href="#section-4-6" class="pilcrow">¶</a></p>
<p id="section-4-7" class="keepWithNext">
       The following is an example of the Claims in
       a Request Object before base64url <span>[<a href="#RFC7515" class="xref">RFC7515</a>]</span> encoding and signing. 
   Note that it includes the extension parameters
   <code>nonce</code> and <code>max_age</code>.<a href="#section-4-7" class="pilcrow">¶</a></p>
<div id="section-4-8">
<pre class="sourcecode lang-json">
  {
   "iss": "s6BhdRkqt3",
   "aud": "https://server.example.com",
   "response_type": "code id_token",
   "client_id": "s6BhdRkqt3",
   "redirect_uri": "https://client.example.org/cb",
   "scope": "openid",
   "state": "af0ifjsldkj",
   "nonce": "n-0S6_WzA2Mj",
   "max_age": 86400
  }
</pre><a href="#section-4-8" class="pilcrow">¶</a>
</div>
<p id="section-4-9" class="keepWithNext">
       Signing it with the <code>RS256</code> algorithm <span>[<a href="#RFC7518" class="xref">RFC7518</a>]</span>
       results in this Request Object value
       (with line wraps within values for display purposes only):<a href="#section-4-9" class="pilcrow">¶</a></p>
<div id="section-4-10">
<pre class="sourcecode lang-jwt">
  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
</pre><a href="#section-4-10" class="pilcrow">¶</a>
</div>
<p id="section-4-11" class="keepWithNext">
       The following RSA public key, represented in JSON Web Key (JWK)
       format, can be used to validate the Request Object signature in
       this and subsequent Request Object examples (with line wraps
       within values for display purposes only):<a href="#section-4-11" class="pilcrow">¶</a></p>
<div id="section-4-12">
<pre class="sourcecode lang-json">
  {
   "kty":"RSA",
   "kid":"k2bdc",
   "n":"x5RbkAZkmpRxia65qRQ1wwSMSxQUnS7gcpVTV_cdHmfmG2ltd2yabEO9XadD8
        pJNZubINPpmgHh3J1aD9WRwS05ucmFq3CfFsluLt13_7oX5yDRSKX7poXmT_5
        ko8k4NJZPMAO8fPToDTH7kHYbONSE2FYa5GZ60CUsFhSonI-dcMDJ0Ary9lxI
        w5k2z4TAdARVWcS7sD07VhlMMshrwsPHBQgTatlkxyIHXbYdtak8fqvNAwr7O
        lVEvM_Ipf5OfmdB8Sd-wjzaBsyP4VhJKoi_qdgSzpC694XZeYPq45Sw-q51iF
        UlcOlTCI7z6jltUtnR6ySn6XDGFnzH5Fe5ypw",
   "e":"AQAB"
  }
</pre><a href="#section-4-12" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="authreq">
<section id="section-5">
      <h2 id="name-authorization-request">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-authorization-request" class="section-name selfRef">Authorization Request</a>
      </h2>
<p id="section-5-1">The client constructs the authorization request URI 
   by adding the following parameters
   to the query component of the authorization
      endpoint URI using the <code>application/x-www-form-urlencoded</code>
      format:<a href="#section-5-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5-2">
        <dt id="section-5-2.1">request</dt>
        <dd style="margin-left: 1.5em" id="section-5-2.2">
          <span class="bcp14">REQUIRED</span> unless <code>request_uri</code>
          is specified. The <span><a href="#request_object" class="xref">Request Object</a> (<a href="#request_object" class="xref">Section 2.1</a>)</span> that
          holds authorization request parameters stated in
          <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-4" class="relref">Section 4</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span> (OAuth 2.0). 
   If this parameter is present in the authorization request, 
   <code>request_uri</code> <span class="bcp14">MUST NOT</span> be present.<a href="#section-5-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-5-2.3">request_uri</dt>
        <dd style="margin-left: 1.5em" id="section-5-2.4">
          <span class="bcp14">REQUIRED</span> unless <code>request</code>
          is specified. The absolute URI, as defined by <span><a href="#RFC3986" class="xref">RFC 3986</a> [<a href="#RFC3986" class="xref">RFC3986</a>]</span>, that is the <span><a href="#request_uri" class="xref">Request Object URI</a> (<a href="#request_uri" class="xref">Section 2.2</a>)</span> referencing the
   authorization request
          parameters stated in <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-4" class="relref">Section 4</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span> (OAuth
          2.0).
   If this parameter is present in the authorization request, 
   <code>request</code> <span class="bcp14">MUST NOT</span> be present.<a href="#section-5-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-5-2.5">client_id</dt>
        <dd style="margin-left: 1.5em" id="section-5-2.6">
          <span class="bcp14">REQUIRED</span>. <span><a href="#RFC6749" class="xref">OAuth 2.0</a> [<a href="#RFC6749" class="xref">RFC6749</a>]</span>
          <code>client_id</code>. The value <span class="bcp14">MUST</span> match the
          <code>request</code> or <code>request_uri</code>
          <span><a href="#request_object" class="xref">Request Object's</a> (<a href="#request_object" class="xref">Section 2.1</a>)</span>
          <code>client_id</code>.<a href="#section-5-2.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-5-3">The client directs the resource owner to the constructed URI
      using an HTTP redirection response or by other means available to it
      via the user agent.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">For example, the client directs the end user's user agent to make the
      following HTTPS request:<a href="#section-5-4" class="pilcrow">¶</a></p>
<div id="section-5-5">
<pre class="sourcecode lang-http-message">
GET /authz?client_id=s6BhdRkqt3&amp;request=eyJhbG..AlMGzw HTTP/1.1
Host: server.example.com
</pre><a href="#section-5-5" class="pilcrow">¶</a>
</div>
<p id="section-5-6" class="keepWithPrevious">
 The value for the request parameter is abbreviated 
 for brevity.<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7">The Authorization Request Object <span class="bcp14">MUST</span> be one of the following:<a href="#section-5-7" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-5-8">
        <dt>(a)</dt>
<dd id="section-5-8.1">JWS signed<a href="#section-5-8.1" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(b)</dt>
<dd id="section-5-8.2">JWS signed and JWE encrypted<a href="#section-5-8.2" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-5-9">The client <span class="bcp14">MAY</span> send the parameters included in 
   the Request Object duplicated in the query parameters as well 
   for backward compatibility, etc. 
   However, the authorization server supporting this specification 
   <span class="bcp14">MUST</span> only use the parameters included in the Request Object.<a href="#section-5-9" class="pilcrow">¶</a></p>
<div id="RequestParameter">
<section id="section-5.1">
        <h3 id="name-passing-a-request-object-by">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-passing-a-request-object-by" class="section-name selfRef">Passing a Request Object by Value</a>
        </h3>
<p id="section-5.1-1">The client sends the authorization request as a 
   Request Object to the authorization endpoint as the 
   <code>request</code> parameter value.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2" class="keepWithNext">The following is an example of an
       authorization request using the <code>request</code>
       parameter
       (with line wraps within values for display purposes only):<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<div id="section-5.1-3">
<pre class="sourcecode lang-url">
  https://server.example.com/authorize?client_id=s6BhdRkqt3&amp;
    request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6
    ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs
    ZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAg
    ICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6
    ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAi
    b3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2Ui
    OiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VU
    ElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC
    0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKz
    uKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3E
    YLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W
    9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3
    j1i7tLR_5Nz-g
</pre><a href="#section-5.1-3" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="RequestUriParameter">
<section id="section-5.2">
        <h3 id="name-passing-a-request-object-by-">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-passing-a-request-object-by-" class="section-name selfRef">Passing a Request Object by Reference</a>
        </h3>
<p id="section-5.2-1">
   The <code>request_uri</code> authorization request parameter enables
   OAuth authorization requests to be passed by reference rather than
   by value.  This parameter is used identically to the
   <code>request</code> parameter, except that the Request Object value is
   retrieved from the resource identified by the specified URI rather
   than passed by value.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">
   The entire Request URI <span class="bcp14">SHOULD NOT</span> exceed 512 ASCII characters.
   There are two reasons for this restriction:<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5.2-3">
          <li id="section-5.2-3.1">Many phones on the market as of this writing still do not accept
          large payloads.  The restriction is typically either 512 or 1024
          ASCII characters.<a href="#section-5.2-3.1" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-3.2">On a slow connection such as a 2G mobile connection, a large URL
          would cause a slow response; therefore, the use of such is not
          advisable from the user-experience point of view.<a href="#section-5.2-3.2" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-5.2-4">
   The contents of the resource referenced by the <code>request_uri</code>
          <span class="bcp14">MUST</span> be a Request Object and <span class="bcp14">MUST</span> be reachable by the authorization server
   unless the URI was provided to the client by the authorization server.
   In the first case, the <code>request_uri</code> <span class="bcp14">MUST</span> be
   an <code>https</code> URI,
   as specified in <span><a href="https://www.rfc-editor.org/rfc/rfc7230#section-2.7.2" class="relref">Section 2.7.2</a> of [<a href="#RFC7230" class="xref">RFC7230</a>]</span>.
   In the second case, it <span class="bcp14">MUST</span> be a URN,
   as specified in <span>[<a href="#RFC8141" class="xref">RFC8141</a>]</span>.<a href="#section-5.2-4" class="pilcrow">¶</a></p>
<p id="section-5.2-5" class="keepWithNext">The following is an example of
     the contents of a Request Object resource that can be
     referenced by a <code>request_uri</code>
     (with line wraps within values for display purposes only):<a href="#section-5.2-5" class="pilcrow">¶</a></p>
<div id="section-5.2-6">
<pre class="sourcecode lang-jwt">
  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
</pre><a href="#section-5.2-6" class="pilcrow">¶</a>
</div>
<div id="CreateRequestUri">
<section id="section-5.2.1">
          <h4 id="name-uri-referencing-the-request">
<a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-uri-referencing-the-request" class="section-name selfRef">URI Referencing the Request Object</a>
          </h4>
<p id="section-5.2.1-1">
     The client stores the Request Object resource either
     locally or remotely at a URI the authorization server can access. 
 Such a facility may be provided by the authorization server 
 or a trusted third party. For example, the authorization server may 
 provide a URL to which the client POSTs the Request Object and 
 obtains the Request URI. 
     This URI is the Request Object URI, <code>request_uri</code>.<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
<p id="section-5.2.1-2">
     It is possible for the Request Object to include values that 
     are to be revealed only to the authorization server.
     As such, the <code>request_uri</code> <span class="bcp14">MUST</span> have
     appropriate entropy for its lifetime
     so that the URI is not guessable if publicly retrievable.
     For the guidance, refer to 
     <span><a href="https://www.rfc-editor.org/rfc/rfc6819#section-5.1.4.2.2" class="relref">Section 5.1.4.2.2</a> of [<a href="#RFC6819" class="xref">RFC6819</a>]</span> and
     "<a href="#CapURLs" class="xref">Good Practices for Capability URLs</a>" <span>[<a href="#CapURLs" class="xref">CapURLs</a>]</span>.
     It is <span class="bcp14">RECOMMENDED</span> that the <code>request_uri</code> be removed
 after a reasonable timeout
     unless access control measures are taken.<a href="#section-5.2.1-2" class="pilcrow">¶</a></p>
<p id="section-5.2.1-3" class="keepWithNext">The following is an example
     of a Request Object URI value
       (with line wraps within values for display purposes only).
       In this example, a trusted third-party service hosts the Request Object.<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
<div id="section-5.2.1-4">
<pre class="sourcecode lang-url">
  https://tfp.example.org/request.jwt/
    GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
</pre><a href="#section-5.2.1-4" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="UseRequestUri">
<section id="section-5.2.2">
          <h4 id="name-request-using-the-request_u">
<a href="#section-5.2.2" class="section-number selfRef">5.2.2. </a><a href="#name-request-using-the-request_u" class="section-name selfRef">Request Using the "request_uri" Request Parameter</a>
          </h4>
<p id="section-5.2.2-1">The client sends the authorization request to the
   authorization endpoint.<a href="#section-5.2.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2.2-2" class="keepWithNext">The following is an example
     of an authorization request using the <code>request_uri</code> parameter
     (with line wraps within values for display purposes only):<a href="#section-5.2.2-2" class="pilcrow">¶</a></p>
<div id="section-5.2.2-3">
<pre class="sourcecode lang-url">
  https://server.example.com/authorize?
    client_id=s6BhdRkqt3
    &amp;request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
    %2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
</pre><a href="#section-5.2.2-3" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="GetRequestUri">
<section id="section-5.2.3">
          <h4 id="name-authorization-server-fetche">
<a href="#section-5.2.3" class="section-number selfRef">5.2.3. </a><a href="#name-authorization-server-fetche" class="section-name selfRef">Authorization Server Fetches Request Object</a>
          </h4>
<p id="section-5.2.3-1">Upon receipt of the Request, the authorization server
          <span class="bcp14">MUST</span> send an HTTP <code>GET</code> request to the
          <code>request_uri</code> to retrieve the referenced Request Object
          unless the Request Object is stored in a way so that the server can
          retrieve it through other mechanisms securely and parse it to
          recreate the authorization request parameters.<a href="#section-5.2.3-1" class="pilcrow">¶</a></p>
<p id="section-5.2.3-2" class="keepWithNext">The following is an example of this fetch
          process.  In this example, a trusted third-party service hosts the
          Request Object.<a href="#section-5.2.3-2" class="pilcrow">¶</a></p>
<div id="section-5.2.3-3">
<pre class="sourcecode lang-http-message">
GET /request.jwt/GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM HTTP/1.1
Host: tfp.example.org
</pre><a href="#section-5.2.3-3" class="pilcrow">¶</a>
</div>
<p id="section-5.2.3-4" class="keepWithNext">The following is an example of the fetch
     response:<a href="#section-5.2.3-4" class="pilcrow">¶</a></p>
<div id="section-5.2.3-5">
<pre class="sourcecode lang-http-message">
  HTTP/1.1 200 OK
  Date: Thu, 20 Aug 2020 23:52:39 GMT
  Server: Apache/2.4.43 (tfp.example.org)
  Content-type: application/oauth-authz-req+jwt
  Content-Length: 797
  Last-Modified: Wed, 19 Aug 2020 23:52:32 GMT

  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
</pre><a href="#section-5.2.3-5" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="JWTRequestValidation">
<section id="section-6">
      <h2 id="name-validating-jwt-based-reques">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-validating-jwt-based-reques" class="section-name selfRef">Validating JWT-Based Requests</a>
      </h2>
<div id="EncryptedRequestObject">
<section id="section-6.1">
        <h3 id="name-jwe-encrypted-request-objec">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-jwe-encrypted-request-objec" class="section-name selfRef">JWE Encrypted Request Object</a>
        </h3>
<p id="section-6.1-1">
     If the Request Object is encrypted, 
     the authorization server <span class="bcp14">MUST</span> decrypt the JWT in accordance with
     the <span><a href="#RFC7516" class="xref">JSON Web Encryption</a> [<a href="#RFC7516" class="xref">RFC7516</a>]</span> 
     specification.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">
 The result is a signed Request Object.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<p id="section-6.1-3">
     If decryption fails, the authorization server <span class="bcp14">MUST</span>
     return an <code>invalid_request_object</code> error to the client in
     response to the authorization request.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="SignedRequestObject">
<section id="section-6.2">
        <h3 id="name-jws-signed-request-object">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-jws-signed-request-object" class="section-name selfRef">JWS-Signed Request Object</a>
        </h3>
<p id="section-6.2-1">
     The authorization server <span class="bcp14">MUST</span> validate the
     signature of the JWS-signed <span>[<a href="#RFC7515" class="xref">RFC7515</a>]</span> Request
     Object. If a <code>kid</code> Header Parameter is present, the key identified
     <span class="bcp14">MUST</span> be the key used and <span class="bcp14">MUST</span> be a
     key associated with the client. The signature <span class="bcp14">MUST</span>
     be validated using a key associated with the client and the
     algorithm specified in the <code>alg</code> Header Parameter. Algorithm verification <span class="bcp14">MUST</span> be performed, as specified in Sections <a href="https://www.rfc-editor.org/rfc/rfc8725#section-3.1" class="relref">3.1</a> and <a href="https://www.rfc-editor.org/rfc/rfc8725#section-3.2" class="relref">3.2</a> of <span>[<a href="#RFC8725" class="xref">RFC8725</a>]</span>.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">
     If the key is not associated with the client or if signature
     validation fails, the authorization server <span class="bcp14">MUST</span>
     return an <code>invalid_request_object</code> error to the client in response to the authorization request.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="RequestParameterValidation">
<section id="section-6.3">
        <h3 id="name-request-parameter-assembly-">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-request-parameter-assembly-" class="section-name selfRef">Request Parameter Assembly and Validation</a>
        </h3>
<p id="section-6.3-1">
     The authorization server <span class="bcp14">MUST</span> extract 
     the set of authorization request parameters 
     from the Request Object value.
     The authorization server <span class="bcp14">MUST</span> only use the 
     parameters in the Request Object, even if the 
     same parameter is provided in the query parameter.
     The client ID values in the <code>client_id</code> request parameter
     and in the Request Object <code>client_id</code> claim <span class="bcp14">MUST</span> be identical.
     The authorization server then validates the request,
     as specified in <span><a href="#RFC6749" class="xref">OAuth 2.0</a> [<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">
     If the Client ID check or the request validation fails, then the
     authorization server <span class="bcp14">MUST</span> return an error to the
     client in response to the authorization request, 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> (OAuth 2.0).<a href="#section-6.3-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-7">
      <h2 id="name-authorization-server-respon">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-authorization-server-respon" class="section-name selfRef">Authorization Server Response</a>
      </h2>
<p id="section-7-1">The authorization server response is created and sent to the client as in
      <span><a href="https://www.rfc-editor.org/rfc/rfc6749#section-4" class="relref">Section 4</a> of [<a href="#RFC6749" class="xref">RFC6749</a>]</span> (OAuth 2.0).<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">In addition, this document uses these additional error values:<a href="#section-7-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-7-3">
        <dt id="section-7-3.1">invalid_request_uri</dt>
        <dd style="margin-left: 1.5em" id="section-7-3.2">
   The <code>request_uri</code> in the 
 authorization request returns an error or contains invalid data.<a href="#section-7-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-7-3.3">invalid_request_object</dt>
        <dd style="margin-left: 1.5em" id="section-7-3.4">
     The request parameter contains
          an invalid Request Object.<a href="#section-7-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-7-3.5">request_not_supported</dt>
        <dd style="margin-left: 1.5em" id="section-7-3.6">
   The authorization server does not support 
   the use of the <code>request</code> parameter.<a href="#section-7-3.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-7-3.7">request_uri_not_supported</dt>
        <dd style="margin-left: 1.5em" id="section-7-3.8">
   The authorization server does not support the use of 
   the <code>request_uri</code> parameter.<a href="#section-7-3.8" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
<div id="tlsreq">
<section id="section-8">
      <h2 id="name-tls-requirements">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-tls-requirements" class="section-name selfRef">TLS Requirements</a>
      </h2>
<p id="section-8-1">
 Client implementations supporting the Request Object URI method 
 <span class="bcp14">MUST</span> support TLS, following  
 <span><a href="#RFC7525" class="xref">"Recommendations for Secure Use 
 of Transport Layer Security (TLS) and 
 Datagram Transport Layer Security (DTLS)"</a> [<a href="#RFC7525" class="xref">RFC7525</a>]</span>.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">
 To protect against information disclosure and tampering,
 confidentiality protection <span class="bcp14">MUST</span> be applied using TLS with a 
 cipher suite that provides confidentiality and integrity protection.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3"> HTTP clients <span class="bcp14">MUST</span> also verify the TLS server certificate, using
            DNS-ID 
   <span>[<a href="#RFC6125" class="xref">RFC6125</a>]</span>, to avoid man-in-the-middle attacks.
     The rules and guidelines defined in
              <span>[<a href="#RFC6125" class="xref">RFC6125</a>]</span> apply here, with the following considerations:<a href="#section-8-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8-4.1">
   Support for DNS-ID identifier type (that is, the dNSName identity
        in the subjectAltName extension) is <span class="bcp14">REQUIRED</span>.  Certification
        authorities that issue server certificates
   <span class="bcp14">MUST</span> support
        the DNS-ID identifier type, and the DNS-ID identifier type <span class="bcp14">MUST</span>
      be present in server certificates.<a href="#section-8-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-4.2">
        DNS names in server certificates <span class="bcp14">MAY</span> contain the
      wildcard character <code>*</code>.<a href="#section-8-4.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-4.3">
        Clients <span class="bcp14">MUST NOT</span> use CN-ID identifiers; a Common Name
        field (CN field) may be present in the server certificate's subject
        name but <span class="bcp14">MUST NOT</span> be used for authentication within
        the rules described in <span>[<a href="#RFC7525" class="xref">RFC7525</a>]</span>.<a href="#section-8-4.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-4.4">
        SRV-ID and URI-ID as described in <span><a href="https://www.rfc-editor.org/rfc/rfc6125#section-6.5" class="relref">Section 6.5</a> of [<a href="#RFC6125" class="xref">RFC6125</a>]</span>
          <span class="bcp14">MUST NOT</span> be used for comparison.<a href="#section-8-4.4" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="IANA">
<section id="section-9">
      <h2 id="name-iana-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<div id="OAuthParametersRegistry">
<section id="section-9.1">
        <h3 id="name-oauth-parameters-registrati">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-oauth-parameters-registrati" class="section-name selfRef">OAuth Parameters Registration</a>
        </h3>
<p id="section-9.1-1">Since the Request Object is a JWT, the core JWT claims cannot be
        used for any purpose in the Request Object other than for what JWT
        dictates.  Thus, they have been registered as OAuth
        authorization request parameters to avoid future OAuth extensions
        using them with different meanings.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
<p id="section-9.1-2">This specification adds the following values to the "OAuth
        Parameters" registry <span>[<a href="#IANA.OAuth.Parameters" class="xref">IANA.OAuth.Parameters</a>]</span>
        established by <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9.1-3">
          <dt id="section-9.1-3.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-3.2">
            <code>iss</code><a href="#section-9.1-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-3.3">Parameter Usage Location:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-3.4">authorization request<a href="#section-9.1-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-3.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-3.6">IETF<a href="#section-9.1-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-3.7">Specification Document(s):</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-3.8">This document and <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.1" class="relref">Section 4.1.1</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-9.1-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9.1-4">
          <dt id="section-9.1-4.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-4.2">
            <code>sub</code><a href="#section-9.1-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-4.3">Parameter Usage Location:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-4.4">authorization request<a href="#section-9.1-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-4.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-4.6">IETF<a href="#section-9.1-4.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-4.7">Specification Document(s):</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-4.8">This document and <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.2" class="relref">Section 4.1.2</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-9.1-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9.1-5">
          <dt id="section-9.1-5.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-5.2">
            <code>aud</code><a href="#section-9.1-5.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-5.3">Parameter Usage Location:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-5.4">authorization request<a href="#section-9.1-5.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-5.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-5.6">IETF<a href="#section-9.1-5.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-5.7">Specification Document(s):</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-5.8">This document and <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3" class="relref">Section 4.1.3</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-9.1-5.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9.1-6">
          <dt id="section-9.1-6.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-6.2">
            <code>exp</code><a href="#section-9.1-6.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-6.3">Parameter Usage Location:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-6.4">authorization request<a href="#section-9.1-6.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-6.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-6.6">IETF<a href="#section-9.1-6.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-6.7">Specification Document(s):</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-6.8">This document and <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.4" class="relref">Section 4.1.4</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-9.1-6.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9.1-7">
          <dt id="section-9.1-7.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-7.2">
            <code>nbf</code><a href="#section-9.1-7.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-7.3">Parameter Usage Location:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-7.4">authorization request<a href="#section-9.1-7.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-7.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-7.6">IETF<a href="#section-9.1-7.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-7.7">Specification Document(s):</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-7.8">This document and <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.5" class="relref">Section 4.1.5</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-9.1-7.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9.1-8">
          <dt id="section-9.1-8.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-8.2">
            <code>iat</code><a href="#section-9.1-8.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-8.3">Parameter Usage Location:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-8.4">authorization request<a href="#section-9.1-8.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-8.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-8.6">IETF<a href="#section-9.1-8.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-8.7">Specification Document(s):</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-8.8">This document and <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.6" class="relref">Section 4.1.6</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-9.1-8.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9.1-9">
          <dt id="section-9.1-9.1">Name:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-9.2">
            <code>jti</code><a href="#section-9.1-9.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-9.3">Parameter Usage Location:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-9.4">authorization request<a href="#section-9.1-9.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-9.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-9.6">IETF<a href="#section-9.1-9.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.1-9.7">Specification Document(s):</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-9.8">This document and <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.7" class="relref">Section 4.1.7</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-9.1-9.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="OAuthAuthorizationServerMetadataRegistry">
<section id="section-9.2">
        <h3 id="name-oauth-authorization-server-">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-oauth-authorization-server-" class="section-name selfRef">OAuth Authorization Server Metadata Registry</a>
        </h3>
<p id="section-9.2-1">This specification adds the following value to the "OAuth
        Authorization Server Metadata" registry <span>[<a href="#IANA.OAuth.Parameters" class="xref">IANA.OAuth.Parameters</a>]</span> established by <span>[<a href="#RFC8414" class="xref">RFC8414</a>]</span>.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9.2-2">
          <dt id="section-9.2-2.1">Metadata Name:</dt>
          <dd style="margin-left: 1.5em" id="section-9.2-2.2">
            <code>require_signed_request_object</code><a href="#section-9.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.2-2.3">Metadata Description:</dt>
          <dd style="margin-left: 1.5em" id="section-9.2-2.4">Indicates where authorization
   request needs to be protected as Request Object and provided through
   either <code>request</code> or <code>request_uri parameter</code>.<a href="#section-9.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.2-2.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-9.2-2.6">IETF<a href="#section-9.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.2-2.7">Specification Document(s):</dt>
          <dd style="margin-left: 1.5em" id="section-9.2-2.8">
            <a href="#require_signed_request_object" class="xref">Section 10.5</a> of this document.<a href="#section-9.2-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="OAuthDynamicClientRegistrationMetadataRegistry">
<section id="section-9.3">
        <h3 id="name-oauth-dynamic-client-regist">
<a href="#section-9.3" class="section-number selfRef">9.3. </a><a href="#name-oauth-dynamic-client-regist" class="section-name selfRef">OAuth Dynamic Client Registration Metadata Registry</a>
        </h3>
<p id="section-9.3-1">This specification adds the following value to the "OAuth Dynamic
        Client Registration Metadata" registry <span>[<a href="#IANA.OAuth.Parameters" class="xref">IANA.OAuth.Parameters</a>]</span> established by <span>[<a href="#RFC7591" class="xref">RFC7591</a>]</span>.<a href="#section-9.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9.3-2">
          <dt id="section-9.3-2.1">Metadata Name:</dt>
          <dd style="margin-left: 1.5em" id="section-9.3-2.2">
            <code>require_signed_request_object</code><a href="#section-9.3-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.3-2.3">Metadata Description:</dt>
          <dd style="margin-left: 1.5em" id="section-9.3-2.4">Indicates where authorization
   request needs to be protected as Request Object and provided through
   either <code>request</code> or <code>request_uri parameter</code>.<a href="#section-9.3-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.3-2.5">Change Controller:</dt>
          <dd style="margin-left: 1.5em" id="section-9.3-2.6">IETF<a href="#section-9.3-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-9.3-2.7">Specification Document(s):</dt>
          <dd style="margin-left: 1.5em" id="section-9.3-2.8">
            <a href="#require_signed_request_object" class="xref">Section 10.5</a> of this document.<a href="#section-9.3-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="MediaReg">
<section id="section-9.4">
        <h3 id="name-media-type-registration">
<a href="#section-9.4" class="section-number selfRef">9.4. </a><a href="#name-media-type-registration" class="section-name selfRef">Media Type Registration</a>
        </h3>
<div id="MediaContents">
<section id="section-9.4.1">
          <h4 id="name-registry-contents">
<a href="#section-9.4.1" class="section-number selfRef">9.4.1. </a><a href="#name-registry-contents" class="section-name selfRef">Registry Contents</a>
          </h4>
<p id="section-9.4.1-1">
                    This section registers the
                    <code>application/oauth-authz-req+jwt</code>
                    media type <span>[<a href="#RFC2046" class="xref">RFC2046</a>]</span> in the "Media Types"
                    registry <span>[<a href="#IANA.MediaTypes" class="xref">IANA.MediaTypes</a>]</span> in the manner
                    described in <span>[<a href="#RFC6838" class="xref">RFC6838</a>]</span>. It can be used to
                    indicate that the content is a JWT containing Request
                    Object claims.<a href="#section-9.4.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9.4.1-2">
            <dt id="section-9.4.1-2.1">Type name:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.2">application<a href="#section-9.4.1-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.3">Subtype name:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.4">oauth-authz-req+jwt<a href="#section-9.4.1-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.5">Required parameters:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.6">N/A<a href="#section-9.4.1-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.7">Optional parameters:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.8">N/A<a href="#section-9.4.1-2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.9">Encoding considerations:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.10">binary;
            a Request Object is a JWT;
            JWT values are encoded as a
            series of base64url-encoded values (some of which may be the
            empty string) separated by period (<code>.</code>) characters.<a href="#section-9.4.1-2.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.11">Security considerations:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.12">See <a href="#Security" class="xref">Section 10</a>
     of RFC 9101<a href="#section-9.4.1-2.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.13">Interoperability considerations:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.14">N/A<a href="#section-9.4.1-2.14" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.15">Published specification:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.16">
              <a href="#authorization_request_object" class="xref">Section 4</a> of RFC 9101<a href="#section-9.4.1-2.16" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.17">Applications that use this media type:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.18">Applications
     that use Request Objects to make an OAuth 2.0 authorization
     request<a href="#section-9.4.1-2.18" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.19">Fragment identifier considerations:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.20">N/A<a href="#section-9.4.1-2.20" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.21">Additional information:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.22">
              <p id="section-9.4.1-2.22.1"><br></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9.4.1-2.22.2">
                <dt id="section-9.4.1-2.22.2.1">Deprecated alias names for this type:</dt>
                <dd style="margin-left: 1.5em" id="section-9.4.1-2.22.2.2">N/A<a href="#section-9.4.1-2.22.2.2" class="pilcrow">¶</a>
</dd>
                <dd class="break"></dd>
<dt id="section-9.4.1-2.22.2.3">Magic number(s):</dt>
                <dd style="margin-left: 1.5em" id="section-9.4.1-2.22.2.4">N/A<a href="#section-9.4.1-2.22.2.4" class="pilcrow">¶</a>
</dd>
                <dd class="break"></dd>
<dt id="section-9.4.1-2.22.2.5">File extension(s):</dt>
                <dd style="margin-left: 1.5em" id="section-9.4.1-2.22.2.6">N/A<a href="#section-9.4.1-2.22.2.6" class="pilcrow">¶</a>
</dd>
                <dd class="break"></dd>
<dt id="section-9.4.1-2.22.2.7">Macintosh file type code(s):</dt>
                <dd style="margin-left: 1.5em" id="section-9.4.1-2.22.2.8">N/A<a href="#section-9.4.1-2.22.2.8" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
</dl>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.23">Person &amp; email address to contact for further
     information:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.24">
              <br>Nat Sakimura &lt;nat@nat.consulting&gt;<a href="#section-9.4.1-2.24" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.25">Intended usage:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.26">COMMON<a href="#section-9.4.1-2.26" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.27">Restrictions on usage:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.28">none<a href="#section-9.4.1-2.28" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.29">Author:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.30">Nat Sakimura &lt;nat@nat.consulting&gt;<a href="#section-9.4.1-2.30" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.31">Change controller:</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.32">IETF<a href="#section-9.4.1-2.32" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-9.4.1-2.33">Provisional registration?</dt>
            <dd style="margin-left: 1.5em" id="section-9.4.1-2.34">No<a href="#section-9.4.1-2.34" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="Security">
<section id="section-10">
      <h2 id="name-security-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-10-1">In addition to all the <span><a href="#RFC6819" class="xref">security
      considerations discussed in OAuth 2.0</a> [<a href="#RFC6819" class="xref">RFC6819</a>]</span>, the security
      considerations in <span>[<a href="#RFC7515" class="xref">RFC7515</a>]</span>, <span>[<a href="#RFC7516" class="xref">RFC7516</a>]</span>,
      <span>[<a href="#RFC7518" class="xref">RFC7518</a>]</span>, and <span>[<a href="#RFC8725" class="xref">RFC8725</a>]</span> need to be
      considered.  Also, there are several academic papers such as <span>[<a href="#BASIN" class="xref">BASIN</a>]</span> that provide useful insight into the security
      properties of protocols like OAuth.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">
   In consideration of the above, this document advises taking the
   following security considerations into account.<a href="#section-10-2" class="pilcrow">¶</a></p>
<div id="alg_choice">
<section id="section-10.1">
        <h3 id="name-choice-of-algorithms">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-choice-of-algorithms" class="section-name selfRef">Choice of Algorithms</a>
        </h3>
<p id="section-10.1-1">When sending the Authorization Request Object through the
 <code>request</code> parameter, it <span class="bcp14">MUST</span> be either
 signed using <span><a href="#RFC7515" class="xref">JWS</a> [<a href="#RFC7515" class="xref">RFC7515</a>]</span>
 or signed and then encrypted using <span><a href="#RFC7515" class="xref">JWS</a> [<a href="#RFC7515" class="xref">RFC7515</a>]</span> and
 <span><a href="#RFC7516" class="xref">JWE</a> [<a href="#RFC7516" class="xref">RFC7516</a>]</span>, respectively,
 with algorithms considered appropriate at the time.<a href="#section-10.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="src_authn">
<section id="section-10.2">
        <h3 id="name-request-source-authenticati">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-request-source-authenticati" class="section-name selfRef">Request Source Authentication</a>
        </h3>
<p id="section-10.2-1">
   The source of the authorization request <span class="bcp14">MUST</span> always be 
   verified. There are several ways to do it:<a href="#section-10.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-10.2-2">
          <dt>(a)</dt>
<dd id="section-10.2-2.1">Verifying the JWS Signature of the Request Object.<a href="#section-10.2-2.1" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt>(b)</dt>
<dd id="section-10.2-2.2">Verifying that the symmetric key for the JWE encryption is the
          correct one if the JWE is using symmetric encryption. Note, however,
          that if public key encryption is used, no source authentication is
          enabled by the encryption, as any party can encrypt to the public
          key.<a href="#section-10.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt>(c)</dt>
<dd id="section-10.2-2.3">Verifying the TLS Server Identity of the Request Object URI.
   In this case, the authorization server <span class="bcp14">MUST</span> know 
   out-of-band that the client uses the Request Object URI and 
   only the client is covered by the TLS certificate. 
   In general, this is not a reliable method.<a href="#section-10.2-2.3" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt>(d)</dt>
<dd id="section-10.2-2.4">When an authorization server implements a service
   that returns a Request Object URI in exchange for
   a Request Object, the authorization
   server <span class="bcp14">MUST</span> perform client authentication to accept 
   the Request Object and bind the client identifier 
   to the Request Object URI it is providing.
   It <span class="bcp14">MUST</span> validate the signature, per (a).
   Since the Request Object URI can be replayed, the lifetime 
   of the Request Object URI <span class="bcp14">MUST</span> be short and preferably 
   one-time use. The entropy of the Request Object URI 
 <span class="bcp14">MUST</span> be sufficiently large. 
            The adequate shortness of the validity and 
            the entropy of the Request Object URI depends 
            on the risk calculation based on the value  
            of the resource being protected. A general guidance 
            for the validity time would be less than a minute, 
            and the Request Object URI is to include a cryptographic  
            random value of 128 bits or more at the time of the 
            writing of this specification.<a href="#section-10.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt>(e)</dt>
<dd id="section-10.2-2.5">When a trusted third-party service returns a Request Object URI
          in exchange for a Request Object, it <span class="bcp14">MUST</span> validate
          the signature, per (a).  In addition, the authorization server
          <span class="bcp14">MUST</span> be trusted by the third-party service and
          <span class="bcp14">MUST</span> know out-of-band that the client is also trusted by it.<a href="#section-10.2-2.5" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="explicit_endpoints">
<section id="section-10.3">
        <h3 id="name-explicit-endpoints">
<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-explicit-endpoints" class="section-name selfRef">Explicit Endpoints</a>
        </h3>
<p id="section-10.3-1">
       Although this specification does not require them, 
       research such as <span>[<a href="#BASIN" class="xref">BASIN</a>]</span> points out that 
       it is a good practice to explicitly state 
       the intended interaction endpoints and the message 
       position in the sequence in a tamper-evident 
       manner so that the intent of the initiator is unambiguous. It
       is <span class="bcp14">RECOMMENDED</span> by this specification to use this
       practice for the following endpoints defined in <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>, <span>[<a href="#RFC6750" class="xref">RFC6750</a>]</span>, and <span>[<a href="#RFC8414" class="xref">RFC8414</a>]</span>:<a href="#section-10.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-10.3-2">
          <dt>(a)</dt>
<dd id="section-10.3-2.1">Protected resources (<code>protected_resources</code>)<a href="#section-10.3-2.1" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt>(b)</dt>
<dd id="section-10.3-2.2">Authorization endpoint (<code>authorization_endpoint</code>)<a href="#section-10.3-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt>(c)</dt>
<dd id="section-10.3-2.3">Redirection URI (<code>redirect_uri</code>)<a href="#section-10.3-2.3" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt>(d)</dt>
<dd id="section-10.3-2.4">Token endpoint (<code>token_endpoint</code>)<a href="#section-10.3-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-10.3-3">
       Further, if dynamic discovery is used, then this practice also applies
       to the discovery-related endpoints.<a href="#section-10.3-3" class="pilcrow">¶</a></p>
<p id="section-10.3-4">
       In <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>, 
       while the redirection URI is included in the authorization request, others
       are not. As a result, the same applies to the Authorization
       Request Object.<a href="#section-10.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="request_uri_threats">
<section id="section-10.4">
        <h3 id="name-risks-associated-with-reque">
<a href="#section-10.4" class="section-number selfRef">10.4. </a><a href="#name-risks-associated-with-reque" class="section-name selfRef">Risks Associated with request_uri</a>
        </h3>
<p id="section-10.4-1">
         The introduction of <code>request_uri</code>
         introduces several attack possibilities. 
         Consult the security considerations in
         <span><a href="https://www.rfc-editor.org/rfc/rfc3986#section-7" class="relref">Section 7</a> of [<a href="#RFC3986" class="xref">RFC3986</a>]</span> for more information
 regarding
         risks associated with URIs.<a href="#section-10.4-1" class="pilcrow">¶</a></p>
<div id="ddos_on_authz_server">
<section id="section-10.4.1">
          <h4 id="name-ddos-attack-on-the-authoriz">
<a href="#section-10.4.1" class="section-number selfRef">10.4.1. </a><a href="#name-ddos-attack-on-the-authoriz" class="section-name selfRef">DDoS Attack on the Authorization Server</a>
          </h4>
<p id="section-10.4.1-1">
         A set of malicious clients can launch a DoS attack 
         to the authorization server by pointing the 
         <code>request_uri</code> to a URI
         that returns extremely large content or is extremely slow to respond. 
         Under such an attack, the server may use up its resource 
         and start failing.<a href="#section-10.4.1-1" class="pilcrow">¶</a></p>
<p id="section-10.4.1-2">
         Similarly, a malicious client can specify a 
 <code>request_uri</code> value 
 that itself points to an authorization request URI 
 that uses <code>request_uri</code> to 
 cause the recursive lookup.<a href="#section-10.4.1-2" class="pilcrow">¶</a></p>
<p id="section-10.4.1-3">
         To prevent such an attack from succeeding, the server should 
         a) check that the value of the <code>request_uri</code> 
         parameter does not point to an unexpected location, 
         b) check that the media type of the response is 
         <code>application/oauth-authz-req+jwt</code>,
         c) implement a timeout for obtaining the content of 
         <code>request_uri</code>, and 
 d) not perform recursive GET on the
 <code>request_uri</code>.<a href="#section-10.4.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="request_uri_rewrite">
<section id="section-10.4.2">
          <h4 id="name-request-uri-rewrite">
<a href="#section-10.4.2" class="section-number selfRef">10.4.2. </a><a href="#name-request-uri-rewrite" class="section-name selfRef">Request URI Rewrite</a>
          </h4>
<p id="section-10.4.2-1">
         The value of <code>request_uri</code> is not signed; 
         thus, it can be tampered with by a man-in-the-browser attacker. 
         Several attack possibilities arise because of this. For
 example, 
         a) an attacker may create another file that the rewritten 
         URI points to, making it possible to request extra scope, or 
         b) an attacker may launch a DoS attack on a victim site 
         by setting the value of <code>request_uri</code> 
         to be that of the victim.<a href="#section-10.4.2-1" class="pilcrow">¶</a></p>
<p id="section-10.4.2-2">
         To prevent such an attack from succeeding, the server should 
         a) check that the value of the <code>request_uri</code> 
         parameter does not point to an unexpected location, 
         b) check that the media type of the response is 
         <code>application/oauth-authz-req+jwt</code>, and
         c) implement a timeout for obtaining the content of 
         <code>request_uri</code>.<a href="#section-10.4.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="require_signed_request_object">
<section id="section-10.5">
        <h3 id="name-downgrade-attack">
<a href="#section-10.5" class="section-number selfRef">10.5. </a><a href="#name-downgrade-attack" class="section-name selfRef">Downgrade Attack</a>
        </h3>
<p id="section-10.5-1">
            Unless the protocol used by the client and the server is locked down to 
            use an OAuth JWT-Secured Authorization Request (JAR), it is possible
     for an attacker to use RFC 6749 requests 
            to bypass all the protection provided by this specification.<a href="#section-10.5-1" class="pilcrow">¶</a></p>
<p id="section-10.5-2">
   To prevent this kind of attack, this specification defines new
   client metadata and server metadata values, both named
   <code>require_signed_request_object</code>, whose values are both
   booleans.<a href="#section-10.5-2" class="pilcrow">¶</a></p>
<p id="section-10.5-3">
            When the value of it as client metadata is <code>true</code>, then the
            server <span class="bcp14">MUST</span> reject the authorization request from
            the client that does not conform to this specification.  It
            <span class="bcp14">MUST</span> also reject the request if the Request Object
            uses an <code>alg</code> value of <code>none</code> when this server
            metadata value is <code>true</code>.  If omitted, the default value is
            <code>false</code>.<a href="#section-10.5-3" class="pilcrow">¶</a></p>
<p id="section-10.5-4">
            When the value of it as server metadata is <code>true</code>, then the
            server <span class="bcp14">MUST</span> reject the authorization request from
            any client that does not conform to this specification.  It
            <span class="bcp14">MUST</span> also reject the request if the Request Object
            uses an <code>alg</code> value of <code>none</code>. If omitted, the
            default value is <code>false</code>.<a href="#section-10.5-4" class="pilcrow">¶</a></p>
<p id="section-10.5-5">Note that even if <code>require_signed_request_object</code> metadata
 values are not present, the client <span class="bcp14">MAY</span> use signed Request Objects,
 provided that there are signing algorithms mutually supported by the
 client and the server.  Use of signing algorithm metadata is described
 in <a href="#authorization_request_object" class="xref">Section 4</a>.<a href="#section-10.5-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tls_sec">
<section id="section-10.6">
        <h3 id="name-tls-security-considerations">
<a href="#section-10.6" class="section-number selfRef">10.6. </a><a href="#name-tls-security-considerations" class="section-name selfRef">TLS Security Considerations</a>
        </h3>
<p id="section-10.6-1">Current security
      considerations can be found in "<a href="#RFC7525" class="xref">Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</a>" <span>[<a href="#RFC7525" class="xref">RFC7525</a>]</span>.  This 
      supersedes the TLS version recommendations in <span><a href="#RFC6749" class="xref">OAuth
        2.0</a> [<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-10.6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ParameterMismatches">
<section id="section-10.7">
        <h3 id="name-parameter-mismatches">
<a href="#section-10.7" class="section-number selfRef">10.7. </a><a href="#name-parameter-mismatches" class="section-name selfRef">Parameter Mismatches</a>
        </h3>
<p id="section-10.7-1">
   Given that OAuth parameter values are being sent in two different places,
   as normal OAuth parameters and as Request Object claims,
   implementations must guard against attacks that could use mismatching
   parameter values to obtain unintended outcomes.
   That is the reason that the two client ID values <span class="bcp14">MUST</span> match,
   the reason that only the parameter values from the Request Object are to be used,
   and the reason that neither <code>request</code> nor
   <code>request_uri</code> can appear in a Request Object.<a href="#section-10.7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="CrossJWT">
<section id="section-10.8">
        <h3 id="name-cross-jwt-confusion">
<a href="#section-10.8" class="section-number selfRef">10.8. </a><a href="#name-cross-jwt-confusion" class="section-name selfRef">Cross-JWT Confusion</a>
        </h3>
<p id="section-10.8-1">
   As described in <span><a href="https://www.rfc-editor.org/rfc/rfc8725#section-2.8" class="relref">Section 2.8</a> of [<a href="#RFC8725" class="xref">RFC8725</a>]</span>,
   attackers may attempt to use a JWT issued for one purpose in a context that it was not intended for.
   The mitigations described for these attacks can be applied to Request Objects.<a href="#section-10.8-1" class="pilcrow">¶</a></p>
<p id="section-10.8-2">
   One way that an attacker might attempt to repurpose a Request Object
   is to try to use it as a client authentication JWT,
   as described in <span><a href="https://www.rfc-editor.org/rfc/rfc7523#section-2.2" class="relref">Section 2.2</a> of [<a href="#RFC7523" class="xref">RFC7523</a>]</span>.
   A simple way to prevent this is to never use the client ID
   as the <code>sub</code> value in a Request Object.<a href="#section-10.8-2" class="pilcrow">¶</a></p>
<p id="section-10.8-3">
   Another way to prevent cross-JWT confusion is to use explicit typing,
   as described in <span><a href="https://www.rfc-editor.org/rfc/rfc8725#section-3.11" class="relref">Section 3.11</a> of [<a href="#RFC8725" class="xref">RFC8725</a>]</span>.
   One would explicitly type a Request Object by including a
   <code>typ</code> Header Parameter with the value
   <code>oauth-authz-req+jwt</code>
   (which is registered in <a href="#MediaContents" class="xref">Section 9.4.1</a>).
   Note, however, that requiring explicitly typed Request Objects
   at existing authorization servers will break most existing deployments,
   as existing clients are already commonly using untyped Request Objects,
   especially with OpenID Connect <span>[<a href="#OpenID.Core" class="xref">OpenID.Core</a>]</span>.
   However, requiring explicit typing would be a good idea
   for new OAuth deployment profiles where compatibility with existing deployments
   is not a consideration.<a href="#section-10.8-3" class="pilcrow">¶</a></p>
<p id="section-10.8-4">
  Finally, yet another way to prevent cross-JWT confusion is to use a key
  management regime in which keys used to sign Request Objects are
  identifiably distinct from those used for other purposes.  Then, if an
  adversary attempts to repurpose the Request Object in another context, a key
  mismatch will occur, thwarting the attack.<a href="#section-10.8-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="Privacy">
<section id="section-11">
      <h2 id="name-privacy-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
      </h2>
<p id="section-11-1">
 When the client is being granted access to a protected resource 
 containing personal data, both the client 
 and the authorization server need to adhere to 
 Privacy Principles. 
 "<a href="#RFC6973" class="xref">Privacy Considerations for Internet Protocols</a>"
 <span>[<a href="#RFC6973" class="xref">RFC6973</a>]</span>
 gives excellent guidance on the
 enhancement of protocol design and implementation.  
 The provisions listed in it should be followed.<a href="#section-11-1" class="pilcrow">¶</a></p>
<p id="section-11-2">
 Most of the provisions would apply to 
 "<a href="#RFC6749" class="xref">The OAuth 2.0 Authorization Framework</a>" <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>
 and "<a href="#RFC6750" class="xref">The OAuth 2.0 Authorization Framework: Bearer Token Usage</a>" <span>[<a href="#RFC6750" class="xref">RFC6750</a>]</span>
 and are not specific to this specification.
 In what follows, only the provisions specific
 to this specification are noted.<a href="#section-11-2" class="pilcrow">¶</a></p>
<div id="collection_limitation">
<section id="section-11.1">
        <h3 id="name-collection-limitation">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-collection-limitation" class="section-name selfRef">Collection Limitation</a>
        </h3>
<p id="section-11.1-1">
 When the client is being granted access to a protected resource
 containing personal data, the client <span class="bcp14">SHOULD</span> limit the
 collection of personal data to that which is within the bounds of
 applicable law and strictly necessary for the specified purpose(s).<a href="#section-11.1-1" class="pilcrow">¶</a></p>
<p id="section-11.1-2">
 It is often hard for the user to find out if the personal data asked
 for is strictly necessary.  A trusted third-party service can help the
 user by examining the client request, comparing it to the proposed
 processing by the client, and certifying the request. After the
 certification, the client, when making an authorization request, can
 submit an authorization request to the trusted third-party service to
 obtain the Request Object URI.  This process has two steps:<a href="#section-11.1-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-11.1-3">
          <dt>(1)</dt>
<dd id="section-11.1-3.1">(Certification Process) The trusted third-party service examines
          the business process of the client and determines what claims they
          need; this is the certification process. Once the client is
          certified, they are issued a client credential to authenticate
          against to push Request Objects to the trusted third-party service
          to get the <code>request_uri</code>.<a href="#section-11.1-3.1" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt>(2)</dt>
<dd id="section-11.1-3.2">(Translation Process) The client uses the client credential that
          it got to push the Request Object to the trusted third-party service
          to get the <code>request_uri</code>.  The trusted third-party service
          also verifies that the Request Object is consistent with the claims
          that the client is eligible for, per the prior step.<a href="#section-11.1-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-11.1-4">
 Upon receiving such a Request Object URI in the authorization request,
 the authorization server first verifies that the authority portion of
 the Request Object URI is a legitimate one for the trusted third-party
 service.  Then, the authorization server issues an HTTP GET request to
 the Request Object URI.  Upon connecting, the authorization server
 <span class="bcp14">MUST</span> verify that the server identity represented in the
 TLS certificate is legitimate for the Request Object URI.  Then, the
 authorization server can obtain the Request Object, which includes the
 <code>client_id</code> representing the client.<a href="#section-11.1-4" class="pilcrow">¶</a></p>
<p id="section-11.1-5">
 The Consent screen <span class="bcp14">MUST</span> indicate the client and
 <span class="bcp14">SHOULD</span> indicate that the request has been vetted by the
 trusted third-party service for the adherence to the collection
 limitation principle.<a href="#section-11.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="disclosure_limitation">
<section id="section-11.2">
        <h3 id="name-disclosure-limitation">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-disclosure-limitation" class="section-name selfRef">Disclosure Limitation</a>
        </h3>
<div id="request_disclosure">
<section id="section-11.2.1">
          <h4 id="name-request-disclosure">
<a href="#section-11.2.1" class="section-number selfRef">11.2.1. </a><a href="#name-request-disclosure" class="section-name selfRef">Request Disclosure</a>
          </h4>
<p id="section-11.2.1-1">
     This specification allows extension parameters. 
     These may include potentially sensitive information. 
     Since URI query parameters may leak through various 
     means but most notably through referrer and browser history, 
     if the authorization request contains a potentially sensitive 
     parameter, the client <span class="bcp14">SHOULD</span> encrypt
     the Request Object using <span><a href="#RFC7516" class="xref">JWE</a> [<a href="#RFC7516" class="xref">RFC7516</a>]</span>.<a href="#section-11.2.1-1" class="pilcrow">¶</a></p>
<p id="section-11.2.1-2">
     Where the Request Object URI method is being used, if the Request
     Object contains personally identifiable or sensitive information,
     the <code>request_uri</code> <span class="bcp14">SHOULD</span> be used only once
     and have a short validity period, and it <span class="bcp14">MUST</span> have
     sufficient entropy for the applicable security policies unless the
     Request Object itself is encrypted using <span><a href="#RFC7516" class="xref">JWE</a> [<a href="#RFC7516" class="xref">RFC7516</a>]</span>. The adequate shortness of the
     validity and the entropy of the Request Object URI depends on the
     risk calculation based on the value of the resource being
     protected. A general guidance for the validity time would be less
     than a minute, and the Request Object URI is to include a
     cryptographic random value of 128 bits or more at the time of the
     writing of this specification.<a href="#section-11.2.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tracking">
<section id="section-11.2.2">
          <h4 id="name-tracking-using-request-obje">
<a href="#section-11.2.2" class="section-number selfRef">11.2.2. </a><a href="#name-tracking-using-request-obje" class="section-name selfRef">Tracking Using Request Object URI</a>
          </h4>
<p id="section-11.2.2-1">
     Even if the protected resource does not include
     personally identifiable information, 
     it is sometimes possible to identify the user 
     through the Request Object URI if persistent static per-user
     Request Object URIs are used. A third party may observe
     it through browser history, etc. and start correlating 
     the user's activity using it. 
     In a way, it is a data disclosure as well and
     should be avoided.<a href="#section-11.2.2-1" class="pilcrow">¶</a></p>
<p id="section-11.2.2-2">
     Therefore, per-user persistent Request Object URIs should be avoided.
     Single-use Request Object URIs are one alternative.<a href="#section-11.2.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<section id="section-12">
      <h2 id="name-references">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-12.1">
        <h3 id="name-normative-references">
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3629">[RFC3629]</dt>
        <dd>
<span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a transformation format of ISO 10646"</span>, <span class="seriesInfo">STD 63</span>, <span class="seriesInfo">RFC 3629</span>, <span class="seriesInfo">DOI 10.17487/RFC3629</span>, <time datetime="2003-11" class="refDate">November 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3629">https://www.rfc-editor.org/info/rfc3629</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3986">[RFC3986]</dt>
        <dd>
<span class="refAuthor">Berners-Lee, T.</span>, <span class="refAuthor">Fielding, R.</span>, and <span class="refAuthor">L. Masinter</span>, <span class="refTitle">"Uniform Resource Identifier (URI): Generic Syntax"</span>, <span class="seriesInfo">STD 66</span>, <span class="seriesInfo">RFC 3986</span>, <span class="seriesInfo">DOI 10.17487/RFC3986</span>, <time datetime="2005-01" class="refDate">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3986">https://www.rfc-editor.org/info/rfc3986</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6125">[RFC6125]</dt>
        <dd>
<span class="refAuthor">Saint-Andre, P.</span> and <span class="refAuthor">J. Hodges</span>, <span class="refTitle">"Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"</span>, <span class="seriesInfo">RFC 6125</span>, <span class="seriesInfo">DOI 10.17487/RFC6125</span>, <time datetime="2011-03" class="refDate">March 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6125">https://www.rfc-editor.org/info/rfc6125</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6749">[RFC6749]</dt>
        <dd>
<span class="refAuthor">Hardt, D., Ed.</span>, <span class="refTitle">"The OAuth 2.0 Authorization Framework"</span>, <span class="seriesInfo">RFC 6749</span>, <span class="seriesInfo">DOI 10.17487/RFC6749</span>, <time datetime="2012-10" class="refDate">October 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6749">https://www.rfc-editor.org/info/rfc6749</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6750">[RFC6750]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span> and <span class="refAuthor">D. Hardt</span>, <span class="refTitle">"The OAuth 2.0 Authorization Framework: Bearer Token Usage"</span>, <span class="seriesInfo">RFC 6750</span>, <span class="seriesInfo">DOI 10.17487/RFC6750</span>, <time datetime="2012-10" class="refDate">October 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6750">https://www.rfc-editor.org/info/rfc6750</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7230">[RFC7230]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span> and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"</span>, <span class="seriesInfo">RFC 7230</span>, <span class="seriesInfo">DOI 10.17487/RFC7230</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7230">https://www.rfc-editor.org/info/rfc7230</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7515">[RFC7515]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">N. Sakimura</span>, <span class="refTitle">"JSON Web Signature (JWS)"</span>, <span class="seriesInfo">RFC 7515</span>, <span class="seriesInfo">DOI 10.17487/RFC7515</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7515">https://www.rfc-editor.org/info/rfc7515</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7516">[RFC7516]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span> and <span class="refAuthor">J. Hildebrand</span>, <span class="refTitle">"JSON Web Encryption (JWE)"</span>, <span class="seriesInfo">RFC 7516</span>, <span class="seriesInfo">DOI 10.17487/RFC7516</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7516">https://www.rfc-editor.org/info/rfc7516</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7518">[RFC7518]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refTitle">"JSON Web Algorithms (JWA)"</span>, <span class="seriesInfo">RFC 7518</span>, <span class="seriesInfo">DOI 10.17487/RFC7518</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7518">https://www.rfc-editor.org/info/rfc7518</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7519">[RFC7519]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">N. Sakimura</span>, <span class="refTitle">"JSON Web Token (JWT)"</span>, <span class="seriesInfo">RFC 7519</span>, <span class="seriesInfo">DOI 10.17487/RFC7519</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7519">https://www.rfc-editor.org/info/rfc7519</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7525">[RFC7525]</dt>
        <dd>
<span class="refAuthor">Sheffer, Y.</span>, <span class="refAuthor">Holz, R.</span>, and <span class="refAuthor">P. Saint-Andre</span>, <span class="refTitle">"Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">BCP 195</span>, <span class="seriesInfo">RFC 7525</span>, <span class="seriesInfo">DOI 10.17487/RFC7525</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7525">https://www.rfc-editor.org/info/rfc7525</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8141">[RFC8141]</dt>
        <dd>
<span class="refAuthor">Saint-Andre, P.</span> and <span class="refAuthor">J. Klensin</span>, <span class="refTitle">"Uniform Resource Names (URNs)"</span>, <span class="seriesInfo">RFC 8141</span>, <span class="seriesInfo">DOI 10.17487/RFC8141</span>, <time datetime="2017-04" class="refDate">April 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8141">https://www.rfc-editor.org/info/rfc8141</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8259">[RFC8259]</dt>
        <dd>
<span class="refAuthor">Bray, T., Ed.</span>, <span class="refTitle">"The JavaScript Object Notation (JSON) Data Interchange Format"</span>, <span class="seriesInfo">STD 90</span>, <span class="seriesInfo">RFC 8259</span>, <span class="seriesInfo">DOI 10.17487/RFC8259</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8259">https://www.rfc-editor.org/info/rfc8259</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8414">[RFC8414]</dt>
      <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Sakimura, N.</span>, and <span class="refAuthor">J. Bradley</span>, <span class="refTitle">"OAuth 2.0 Authorization Server Metadata"</span>, <span class="seriesInfo">RFC 8414</span>, <span class="seriesInfo">DOI 10.17487/RFC8414</span>, <time datetime="2018-06" class="refDate">June 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8414">https://www.rfc-editor.org/info/rfc8414</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-12.2">
        <h3 id="name-informative-references">
<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="BASIN">[BASIN]</dt>
        <dd>
<span class="refAuthor">Basin, D.</span>, <span class="refAuthor">Cremers, C.</span>, and <span class="refAuthor">S. Meier</span>, <span class="refTitle">"Provably Repairing the ISO/IEC 9798 Standard for Entity Authentication"</span>, <span class="refContent">Journal of Computer Security - Security and Trust Principles, Volume 21, Issue 6, pp. 817-846</span>, <time datetime="2013-11" class="refDate">November 2013</time>, <span>&lt;<a href="https://www.cs.ox.ac.uk/people/cas.cremers/downloads/papers/BCM2012-iso9798.pdf">https://www.cs.ox.ac.uk/people/cas.cremers/downloads/papers/BCM2012-iso9798.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CapURLs">[CapURLs]</dt>
        <dd>
<span class="refAuthor">Tennison, J., Ed.</span>, <span class="refTitle">"Good Practices for Capability URLs"</span>, <span class="refContent">W3C First Public Working Draft</span>, <time datetime="2014-02-18" class="refDate">18 February 2014</time>, <span>&lt;<a href="https://www.w3.org/TR/capability-urls/">https://www.w3.org/TR/capability-urls/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA.JWT.Claims">[IANA.JWT.Claims]</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>
<dd class="break"></dd>
<dt id="IANA.MediaTypes">[IANA.MediaTypes]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Media Types"</span>, <span>&lt;<a href="https://www.iana.org/assignments/media-types">https://www.iana.org/assignments/media-types</a>&gt;</span>. </dd>
<dd class="break"></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>
<dd class="break"></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.B.</span>, <span class="refAuthor">de Medeiros, B.</span>, and <span class="refAuthor">C. Mortimore</span>, <span class="refTitle">"OpenID Connect Core 1.0 incorporating errata set 1"</span>, <span class="refContent">OpenID Foundation Standards</span>, <time datetime="2014-11-08" class="refDate">8 November 2014</time>, <span>&lt;<a href="http://openid.net/specs/openid-connect-core-1_0.html">http://openid.net/specs/openid-connect-core-1_0.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2046">[RFC2046]</dt>
        <dd>
<span class="refAuthor">Freed, N.</span> and <span class="refAuthor">N. Borenstein</span>, <span class="refTitle">"Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"</span>, <span class="seriesInfo">RFC 2046</span>, <span class="seriesInfo">DOI 10.17487/RFC2046</span>, <time datetime="1996-11" class="refDate">November 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2046">https://www.rfc-editor.org/info/rfc2046</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6819">[RFC6819]</dt>
        <dd>
<span class="refAuthor">Lodderstedt, T., Ed.</span>, <span class="refAuthor">McGloin, M.</span>, and <span class="refAuthor">P. Hunt</span>, <span class="refTitle">"OAuth 2.0 Threat Model and Security Considerations"</span>, <span class="seriesInfo">RFC 6819</span>, <span class="seriesInfo">DOI 10.17487/RFC6819</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6819">https://www.rfc-editor.org/info/rfc6819</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6838">[RFC6838]</dt>
        <dd>
<span class="refAuthor">Freed, N.</span>, <span class="refAuthor">Klensin, J.</span>, and <span class="refAuthor">T. Hansen</span>, <span class="refTitle">"Media Type Specifications and Registration Procedures"</span>, <span class="seriesInfo">BCP 13</span>, <span class="seriesInfo">RFC 6838</span>, <span class="seriesInfo">DOI 10.17487/RFC6838</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6838">https://www.rfc-editor.org/info/rfc6838</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6973">[RFC6973]</dt>
        <dd>
<span class="refAuthor">Cooper, A.</span>, <span class="refAuthor">Tschofenig, H.</span>, <span class="refAuthor">Aboba, B.</span>, <span class="refAuthor">Peterson, J.</span>, <span class="refAuthor">Morris, J.</span>, <span class="refAuthor">Hansen, M.</span>, and <span class="refAuthor">R. Smith</span>, <span class="refTitle">"Privacy Considerations for Internet Protocols"</span>, <span class="seriesInfo">RFC 6973</span>, <span class="seriesInfo">DOI 10.17487/RFC6973</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6973">https://www.rfc-editor.org/info/rfc6973</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7523">[RFC7523]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Campbell, B.</span>, and <span class="refAuthor">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" class="refDate">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>
<dd class="break"></dd>
<dt id="RFC7591">[RFC7591]</dt>
        <dd>
<span class="refAuthor">Richer, J., Ed.</span>, <span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Bradley, J.</span>, <span class="refAuthor">Machulak, M.</span>, and <span class="refAuthor">P. Hunt</span>, <span class="refTitle">"OAuth 2.0 Dynamic Client Registration Protocol"</span>, <span class="seriesInfo">RFC 7591</span>, <span class="seriesInfo">DOI 10.17487/RFC7591</span>, <time datetime="2015-07" class="refDate">July 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7591">https://www.rfc-editor.org/info/rfc7591</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8725">[RFC8725]</dt>
      <dd>
<span class="refAuthor">Sheffer, Y.</span>, <span class="refAuthor">Hardt, D.</span>, and <span class="refAuthor">M. Jones</span>, <span class="refTitle">"JSON Web Token Best Current Practices"</span>, <span class="seriesInfo">BCP 225</span>, <span class="seriesInfo">RFC 8725</span>, <span class="seriesInfo">DOI 10.17487/RFC8725</span>, <time datetime="2020-02" class="refDate">February 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8725">https://www.rfc-editor.org/info/rfc8725</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="Acknowledgements">
<section id="appendix-A">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-A-1">
     The following people contributed to the creation of this document
     in the OAuth Working Group and other IETF roles.
     (Affiliations at the time of the contribution are used.)<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">
     <span class="contact-name">Annabelle Backman</span> (Amazon),
     <span class="contact-name">Dirk Balfanz</span> (Google),
     <span class="contact-name">Sergey Beryozkin</span>, 
     <span class="contact-name">Ben Campbell</span> (as AD),
     <span class="contact-name">Brian Campbell</span> (Ping Identity),
     <span class="contact-name">Roman Danyliw</span> (as AD),
     <span class="contact-name">Martin Duke</span> (as AD),
     <span class="contact-name">Vladimir Dzhuvinov</span> (Connect2id),
     <span class="contact-name">Lars Eggert</span> (as AD),
     <span class="contact-name">Joel Halpern</span> (as GENART),
     <span class="contact-name">Benjamin Kaduk</span> (as AD),
     <span class="contact-name">Stephen Kent</span> (as SECDIR),
     <span class="contact-name">Murray Kucherawy</span> (as AD),
     <span class="contact-name">Warren Kumari</span> (as OPSDIR),
     <span class="contact-name">Watson Ladd</span> (as SECDIR),
     <span class="contact-name">Torsten Lodderstedt</span> (yes.com),
     <span class="contact-name">Jim Manico</span>,
     <span class="contact-name">James H. Manger</span> (Telstra),
     <span class="contact-name">Kathleen Moriarty</span> (as AD),
     <span class="contact-name">Axel Nennker</span> (Deutsche Telecom),
     <span class="contact-name">John Panzer</span> (Google),
     <span class="contact-name">Francesca Palombini</span> (as AD),
     <span class="contact-name">David Recordon</span> (Facebook),
     <span class="contact-name">Marius Scurtescu</span> (Google),
     <span class="contact-name">Luke Shepard</span> (Facebook),
     <span class="contact-name">Filip Skokan</span> (Auth0),
     <span class="contact-name">Hannes Tschofenig</span> (ARM),
     <span class="contact-name">Éric Vyncke</span> (as AD),
     and
     <span class="contact-name">Robert Wilton</span> (as AD).<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<p id="appendix-A-3">The following people contributed to creating this document through
      the <span><a href="#OpenID.Core" class="xref">OpenID Connect Core 1.0</a> [<a href="#OpenID.Core" class="xref">OpenID.Core</a>]</span>.<a href="#appendix-A-3" class="pilcrow">¶</a></p>
<p id="appendix-A-4">
   <span class="contact-name">Brian Campbell</span> (Ping Identity), <span class="contact-name">George Fletcher</span> (AOL), <span class="contact-name">Ryo Itou</span>
   (Mixi), <span class="contact-name">Edmund Jay</span> (Illumila), <span class="contact-name">Breno de Medeiros</span> (Google), <span class="contact-name">Hideki    Nara</span> (TACT), and <span class="contact-name">Justin Richer</span> (MITRE).<a href="#appendix-A-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <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">Nat Sakimura</span></div>
<div dir="auto" class="left"><span class="org">NAT.Consulting</span></div>
<div dir="auto" class="left"><span class="extended-address">2-22-17 Naka</span></div>
<div dir="auto" class="left">
<span class="street-address">Kunitachi</span>, <span class="region">Tokyo 186-0004</span>
</div>
<div dir="auto" class="left"><span class="country-name">Japan</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+81-42-580-7401" class="tel">+81-42-580-7401</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:nat@nat.consulting" class="email">nat@nat.consulting</a>
</div>
<div class="url">
<span>URI:</span>
<a href="https://nat.sakimura.org/" class="url">https://nat.sakimura.org/</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 dir="auto" class="left"><span class="extended-address">Sucursal Talagante</span></div>
<div dir="auto" class="left"><span class="street-address">Casilla 177</span></div>
<div dir="auto" class="left"><span class="locality">Talagante</span></div>
<div dir="auto" class="left"><span class="region">RM</span></div>
<div dir="auto" class="left"><span class="country-name">Chile</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1.202.630.5272" class="tel">+1.202.630.5272</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:rfc9101@ve7jtb.com" class="email">rfc9101@ve7jtb.com</a>
</div>
<div class="url">
<span>URI:</span>
<a href="http://www.thread-safe.com/" class="url">http://www.thread-safe.com/</a>
</div>
</address>
<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 dir="auto" class="left"><span class="street-address">One Microsoft Way</span></div>
<div dir="auto" class="left">
<span class="locality">Redmond</span>, <span class="region">Washington</span> <span class="postal-code">98052</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</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>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>