File: rfc8898.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 (2197 lines) | stat: -rw-r--r-- 94,963 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8898: Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP)</title>
<meta content="Rifaat Shekh-Yusef" name="author">
<meta content="Christer Holmberg" name="author">
<meta content="Victor Pascual" name="author">
<meta content='
       
    This document defines the "Bearer" authentication scheme for
    the Session Initiation Protocol (SIP) and a mechanism by
    which user authentication and SIP registration authorization
    is delegated to a third party, using the OAuth 2.0 framework
    and OpenID Connect Core 1.0.  This document updates RFC 3261
    to provide guidance on how a SIP User Agent Client (UAC)
    responds to a SIP 401/407 response that contains multiple
    WWW-Authenticate/Proxy-Authenticate header fields.        
       
    ' name="description">
<meta content="xml2rfc 3.0.0" name="generator">
<meta content="SIP OAuth" name="keyword">
<meta content="3rd party authentication" name="keyword">
<meta content="Third party authentication" name="keyword">
<meta content="8898" name="rfc.number">
<link href="rfc8898.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.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;
}</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8898" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz-17" 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 8898</td>
<td class="center">3rd-Party Token-Based SIP Authentication</td>
<td class="right">September 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Shekh-Yusef, 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/rfc8898" class="eref">8898</a></dd>
<dt class="label-updates">Updates:</dt>
<dd class="updates">
<a href="https://www.rfc-editor.org/rfc/rfc3261" class="eref">3261</a> </dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-09" class="published">September 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">R. Shekh-Yusef</div>
<div class="org">Auth0</div>
</div>
<div class="author">
      <div class="author-name">C. Holmberg</div>
<div class="org">Ericsson</div>
</div>
<div class="author">
      <div class="author-name">V. Pascual</div>
<div class="org">Nokia</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8898</h1>
<h1 id="title">Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
    This document defines the "Bearer" authentication scheme for
    the Session Initiation Protocol (SIP) and a mechanism by
    which user authentication and SIP registration authorization
    is delegated to a third party, using the OAuth 2.0 framework
    and OpenID Connect Core 1.0.  This document updates RFC 3261
    to provide guidance on how a SIP User Agent Client (UAC)
    responds to a SIP 401/407 response that contains multiple
    WWW-Authenticate/Proxy-Authenticate header fields.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8898">https://www.rfc-editor.org/info/rfc8898</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" 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-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-applicability" class="xref">Applicability</a><a href="#section-toc.1-1.1.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.1.2.3">
                <p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="xref">1.3</a>.  <a href="#name-token-types-and-formats" class="xref">Token Types and Formats</a><a href="#section-toc.1-1.1.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.1.2.4">
                <p id="section-toc.1-1.1.2.4.1"><a href="#section-1.4" class="xref">1.4</a>.  <a href="#name-example-flows" class="xref">Example Flows</a><a href="#section-toc.1-1.1.2.4.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1.2.4.2.1">
                    <p id="section-toc.1-1.1.2.4.2.1.1"><a href="#section-1.4.1" class="xref">1.4.1</a>.  <a href="#name-registration" class="xref">Registration</a><a href="#section-toc.1-1.1.2.4.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.1.2.4.2.2">
                    <p id="section-toc.1-1.1.2.4.2.2.1"><a href="#section-1.4.2" class="xref">1.4.2</a>.  <a href="#name-registration-with-preconfig" class="xref">Registration with Preconfigured AS</a><a href="#section-toc.1-1.1.2.4.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-sip-procedures" class="xref">SIP Procedures</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-uac-behavior" class="xref">UAC Behavior</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.2.2.1.2.1">
                    <p id="section-toc.1-1.2.2.1.2.1.1"><a href="#section-2.1.1" class="xref">2.1.1</a>.  <a href="#name-obtaining-tokens-and-respon" class="xref">Obtaining Tokens and Responding to Challenges</a><a href="#section-toc.1-1.2.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.2.2.1.2.2">
                    <p id="section-toc.1-1.2.2.1.2.2.1"><a href="#section-2.1.2" class="xref">2.1.2</a>.  <a href="#name-protecting-the-access-token" class="xref">Protecting the Access Token</a><a href="#section-toc.1-1.2.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.2.2.1.2.3">
                    <p id="section-toc.1-1.2.2.1.2.3.1"><a href="#section-2.1.3" class="xref">2.1.3</a>.  <a href="#name-register-request" class="xref">REGISTER Request</a><a href="#section-toc.1-1.2.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.2.2.1.2.4">
                    <p id="section-toc.1-1.2.2.1.2.4.1"><a href="#section-2.1.4" class="xref">2.1.4</a>.  <a href="#name-non-register-request" class="xref">Non-REGISTER Request</a><a href="#section-toc.1-1.2.2.1.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-user-agent-server-uas-and-r" class="xref">User Agent Server (UAS) and Registrar Behavior</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-proxy-behavior" class="xref">Proxy Behavior</a><a href="#section-toc.1-1.2.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-access-token-claims" class="xref">Access Token Claims</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-www-authenticate-response-h" class="xref">WWW-Authenticate Response Header Field</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-new-proxy-authenticate-head" class="xref">New Proxy-Authenticate Header Field Parameters</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-new-www-authenticate-header" class="xref">New WWW-Authenticate Header Field Parameters</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
      The Session Initiation Protocol (SIP) <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span> uses the same framework
      as HTTP <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span> to authenticate users: a simple
      challenge-response authentication mechanism that allows a SIP User Agent Server (UAS), proxy, or
      registrar to challenge a SIP User Agent Client (UAC) request and allows
      the UAC to provide authentication information in response to that
      challenge.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
      OAuth 2.0 <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span> defines a token-based authorization
      framework to allow an OAuth client to access resources on behalf of its user.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
      The OpenID Connect Core 1.0 specification <span>[<a href="#OPENID" class="xref">OPENID</a>]</span> defines
      a simple identity layer on top of the OAuth 2.0 protocol, which enables
      OAuth/OpenID clients to verify the identity of the user based on the authentication
      performed by a dedicated authorization server (AS), referred to as
      OpenID Provider (OP), as well as to obtain basic profile information about the user.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
      This document defines the "Bearer" authentication scheme for 
      SIP and a mechanism by which user
      authentication and SIP registration authorization is delegated to a
      third party, using the OAuth 2.0 framework and OpenID Connect Core
      1.0. This kind of user authentication enables single sign-on,
      which allows the user to authenticate once and gain access to both SIP
      and non-SIP services.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
      This document also updates <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span> by defining the UAC procedures 
      when a UAC receives a 401/407 response with multiple WWW-Authenticate/Proxy-Authenticate 
      header fields, providing challenges using different authentication schemes 
      for the same realm.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6"></p>
<div id="terminology">
<section id="section-1.1">
        <h3 id="name-terminology">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-terminology" class="section-name selfRef">Terminology</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>
</div>
<div id="section.this">
<section id="section-1.2">
        <h3 id="name-applicability">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-applicability" class="section-name selfRef">Applicability</a>
        </h3>
<p id="section-1.2-1">
        This document covers cases where grants that allow the UAC to obtain an
        access token from the AS are used. Cases where the UAC is not able to obtain
        an access token (e.g., in the case of an authorization code grant) are not covered.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<p id="section-1.2-2"></p>
</section>
</div>
<div id="tokens">
<section id="section-1.3">
        <h3 id="name-token-types-and-formats">
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-token-types-and-formats" class="section-name selfRef">Token Types and Formats</a>
        </h3>
<p id="section-1.3-1">
      The tokens used in third-party authorization depend on the type of 
      AS.<a href="#section-1.3-1" class="pilcrow">¶</a></p>
<p id="section-1.3-2">
      An OAuth AS provides the following tokens to a successfully 
      authorized UAC:<a href="#section-1.3-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-1.3-3">
          <dt id="section-1.3-3.1">Access Token:</dt>
          <dd style="margin-left: 1.5em" id="section-1.3-3.2">The UAC will use this token to gain access to services by 
      providing the token to a SIP server.<a href="#section-1.3-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-3.3">Refresh Token:</dt>
          <dd style="margin-left: 1.5em" id="section-1.3-3.4">The UAC will present this token to the AS
      to refresh a stale access token.<a href="#section-1.3-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-1.3-4">An OP returns an additional token:<a href="#section-1.3-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-1.3-5">
          <dt id="section-1.3-5.1">ID Token:</dt>
          <dd style="margin-left: 1.5em" id="section-1.3-5.2">This token contains a SIP URI associated with the user and other
      user-specific details that will be consumed by the UAC.<a href="#section-1.3-5.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-1.3-6">Tokens can be represented in two different formats:<a href="#section-1.3-6" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-1.3-7">
          <dt id="section-1.3-7.1">Structured Token:</dt>
          <dd style="margin-left: 1.5em" id="section-1.3-7.2">A token that consists of a structured object that contains the
      claims associated with the token, e.g., JSON Web Token (JWT), as defined
      in <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-1.3-7.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-7.3">Reference Token:</dt>
          <dd style="margin-left: 1.5em" id="section-1.3-7.4">A token that consists of an opaque string that is used to obtain the
      details of the token and its associated claims, as defined in <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-1.3-7.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-1.3-8">
      Access tokens are represented in one of the above two formats. Refresh tokens 
      usually are represented in a reference format, as this token is consumed
      only by the AS that 
      issued the token.  The ID token is defined as a structured token in the form of a JWT.<a href="#section-1.3-8" class="pilcrow">¶</a></p>
<p id="section-1.3-9"></p>
</section>
</div>
<div id="sec.authnz.flow">
<section id="section-1.4">
        <h3 id="name-example-flows">
<a href="#section-1.4" class="section-number selfRef">1.4. </a><a href="#name-example-flows" class="section-name selfRef">Example Flows</a>
        </h3>
<div id="sec.reg.discovered.as">
<section id="section-1.4.1">
          <h4 id="name-registration">
<a href="#section-1.4.1" class="section-number selfRef">1.4.1. </a><a href="#name-registration" class="section-name selfRef">Registration</a>
          </h4>
<p id="section-1.4.1-1">
        <a href="#fig-register-flow" class="xref">Figure 1</a> below shows an example of a SIP registration where
        the registrar informs the UAC about the AS from which the UAC can
        obtain an access token.<a href="#section-1.4.1-1" class="pilcrow">¶</a></p>
<span id="name-example-registration-flow"></span><div id="fig-register-flow">
<figure id="figure-1">
            <div class="artwork art-text alignLeft" id="section-1.4.1-2.1">
<pre>
  UAC                         Registrar                         AS/OP
---------------------------------------------------------------------
  |                               |                               |
  | [1] REGISTER                  |                               |
  |------------------------------&gt;|                               |
  |                               |                               |
  | [2] 401 Unauthorized          |                               |
  |     WWW-Authenticate: Bearer "authz_server"="&lt;authz_server&gt;"  |
  |&lt;------------------------------|                               |
  |                               |                               |
  | [3] The UAC interacts with the AS and obtains tokens using    |
  |     some out-of-scope mechanism.                              |
  |&lt;=============================================================&gt;|
  |                               |                               |
  | [4] REGISTER                  |                               |
  |     Authorization: Bearer &lt;access_token&gt;                      |
  |------------------------------&gt;|                               |
  |                               | [5] HTTP POST /introspect     |
  |                               |     {access_token}            |
  |                               |       (OPTIONAL)              |
  |                               |------------------------------&gt;|
  |                               |                               |
  |                               | [6] 200 OK {metadata}         |
  |                               |       (OPTIONAL)              |
  |                               |&lt;------------------------------|
  |                               |                               |
  | [7] 200 OK                    |                               |
  |&lt;------------------------------|                               |
  |                               |                               |
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-example-registration-flow" class="selfRef">Example Registration Flow</a>
            </figcaption></figure>
</div>
<p id="section-1.4.1-3"> 
        In step [1], the UAC starts the registration process by sending a 
        SIP REGISTER request to the registrar without any credentials.<a href="#section-1.4.1-3" class="pilcrow">¶</a></p>
<p id="section-1.4.1-4">
        In step [2], the registrar challenges the UA by sending a SIP 
        401 (Unauthorized) response to the REGISTER request. In the response,
        the registrar includes information about the AS to contact in order
        to obtain a token.<a href="#section-1.4.1-4" class="pilcrow">¶</a></p>
<p id="section-1.4.1-5">
        In step [3], the UAC interacts with the AS via an out-of-scope mechanism, potentially using the OAuth Native 
        App mechanism defined in <span>[<a href="#RFC8252" class="xref">RFC8252</a>]</span>. The AS authenticates the user and provides the UAC with the 
        tokens needed to access the SIP service.<a href="#section-1.4.1-5" class="pilcrow">¶</a></p>
<p id="section-1.4.1-6">
        In step [4], the UAC retries the registration process by sending a new
        REGISTER request that includes the access token that the UAC 
        obtained in the step above.<a href="#section-1.4.1-6" class="pilcrow">¶</a></p>
<p id="section-1.4.1-7">
        The registrar validates the access token. If the access token is a
        reference token, the registrar <span class="bcp14">MAY</span> perform an introspection
        <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>, as in steps [5] and [6], in order to obtain more
        information about the access token and its scope, per <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>.
        Otherwise, after the registrar validates the token, it inspects its
        claims and acts upon it.<a href="#section-1.4.1-7" class="pilcrow">¶</a></p>
<p id="section-1.4.1-8">
        In step [7], once the registrar has successfully verified and accepted the 
        access token, it sends a 200 (OK) response to the REGISTER request.<a href="#section-1.4.1-8" class="pilcrow">¶</a></p>
<p id="section-1.4.1-9"></p>
</section>
</div>
<div id="sec.reg.preconfigured.as">
<section id="section-1.4.2">
          <h4 id="name-registration-with-preconfig">
<a href="#section-1.4.2" class="section-number selfRef">1.4.2. </a><a href="#name-registration-with-preconfig" class="section-name selfRef">Registration with Preconfigured AS</a>
          </h4>
<p id="section-1.4.2-1">
        <a href="#fig-config-ua" class="xref">Figure 2</a> shows an example of a SIP registration where
        the UAC has been preconfigured with information about the AS
        from which to obtain the access token.<a href="#section-1.4.2-1" class="pilcrow">¶</a></p>
<span id="name-example-registration-flow-a"></span><div id="fig-config-ua">
<figure id="figure-2">
            <div class="artwork art-text alignLeft" id="section-1.4.2-2.1">
<pre>
  UAC                         Registrar                         AS/OP
---------------------------------------------------------------------
  |                               |                               |
  | [1] The UAC interacts with the AS and obtains tokens using    |
  |     some out-of-scope mechanism.                              |
  |&lt;=============================================================&gt;|
  |                               |                               |
  | [2] REGISTER                  |                               |
  |     Authorization: Bearer &lt;access_token&gt;                      |
  |------------------------------&gt;|                               |
  |                               | [3] HTTP POST /introspect     |
  |                               |     {access_token}            |
  |                               |       (OPTIONAL)              |
  |                               |------------------------------&gt;|
  |                               |                               |
  |                               | [4] 200 OK {metadata}         |
  |                               |       (OPTIONAL)              |
  |                               |&lt;------------------------------|
  |                               |                               |
  | [5] 200 OK                    |                               |
  |&lt;------------------------------|                               |
  |                               |                               |
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-example-registration-flow-a" class="selfRef">Example Registration Flow - AS Information Preconfigured</a>
            </figcaption></figure>
</div>
<p id="section-1.4.2-3">
        In step [1], the UAC interacts with the AS using an out-of-scope mechanism, potentially using the OAuth Native 
        App mechanism defined in <span>[<a href="#RFC8252" class="xref">RFC8252</a>]</span>. The AS authenticates the user and provides the UAC with the 
        tokens needed to access the SIP service.<a href="#section-1.4.2-3" class="pilcrow">¶</a></p>
<p id="section-1.4.2-4">
        In step [2], the UAC initiates the registration process by sending a new
        REGISTER request that includes the access token that the UAC 
        obtained in the step above.<a href="#section-1.4.2-4" class="pilcrow">¶</a></p>
<p id="section-1.4.2-5">
        The registrar validates the access token. If the access token is a
        reference token, the registrar <span class="bcp14">MAY</span> perform an introspection
        <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>, as in steps [4] and [5], in order to obtain more
        information about the access token and its scope, per <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span>.
        Otherwise, after the registrar validates the token, it inspects its
        claims and acts upon it.<a href="#section-1.4.2-5" class="pilcrow">¶</a></p>
<p id="section-1.4.2-6">
        In step [5], once the registrar has successfully verified and accepted the 
        access token, it sends a 200 (OK) response to the REGISTER request.<a href="#section-1.4.2-6" class="pilcrow">¶</a></p>
<p id="section-1.4.2-7"></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="sec.sip">
<section id="section-2">
      <h2 id="name-sip-procedures">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-sip-procedures" class="section-name selfRef">SIP Procedures</a>
      </h2>
<p id="section-2-1"><span><a href="https://www.rfc-editor.org/rfc/rfc3261#section-22" class="relref">Section 22</a> of [<a href="#RFC3261" class="xref">RFC3261</a>]</span> defines the
      SIP procedures for the Digest authentication mechanism. The same
      procedures apply to the "Bearer" authentication mechanism, with the
      changes described in this section.<a href="#section-2-1" class="pilcrow">¶</a></p>
<div id="sec.sip.uac">
<section id="section-2.1">
        <h3 id="name-uac-behavior">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-uac-behavior" class="section-name selfRef">UAC Behavior</a>
        </h3>
<div id="sec.sip.uac.obtain">
<section id="section-2.1.1">
          <h4 id="name-obtaining-tokens-and-respon">
<a href="#section-2.1.1" class="section-number selfRef">2.1.1. </a><a href="#name-obtaining-tokens-and-respon" class="section-name selfRef">Obtaining Tokens and Responding to Challenges</a>
          </h4>
<p id="section-2.1.1-1">
          When a UAC sends a request without credentials (or with invalid credentials), 
          it could receive either a 401 (Unauthorized) response with a WWW-Authenticate header field or a 407 (Proxy 
          Authentication Required) response with a Proxy-Authenticate header field.
          If the WWW-Authenticate or Proxy-Authenticate header field indicates "Bearer" scheme authentication 
          and contains an address to an AS, the UAC contacts the 
          AS in order to obtain tokens and includes the requested 
          scopes, based on a local configuration (<a href="#fig-register-flow" class="xref">Figure 1</a>). 
          The UAC <span class="bcp14">MUST</span> check the AS URL received in the 401/407 response
          against a list of trusted ASs configured on the UAC in order
          to prevent several classes of possible vulnerabilities when a client blindly
          attempts to use any provided AS.<a href="#section-2.1.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1.1-2">
          The detailed OAuth2 procedure to authenticate the user and obtain
          these tokens is out of scope of this document. 
          The address of the AS might already be known to the UAC via configuration. 
          In such cases, the UAC can contact the AS for tokens 
          before it sends a SIP request (<a href="#fig-config-ua" class="xref">Figure 2</a>). 
          Procedures for native applications are defined in <span>[<a href="#RFC8252" class="xref">RFC8252</a>]</span>.
          When using the mechanism defined
          in <span>[<a href="#RFC8252" class="xref">RFC8252</a>]</span>, the user of the UAC will be directed to interact
          with the AS using a web browser, which allows the AS
          to prompt the user for multi-factor authentication, to redirect the user to
          third-party identity providers, and to enable the use of single sign-on sessions.<a href="#section-2.1.1-2" class="pilcrow">¶</a></p>
<p id="section-2.1.1-3">
          The tokens returned to the UAC depend on the type of AS; an OAuth AS provides an 
          access token and, optionally, a refresh token <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>. The refresh
          token is only used between the UAC and the AS. If the AS provides a refresh token
          to the UAC, the UAC uses it to request a new access token from
          the AS before the currently used access token expires (<span>[<a href="#RFC6749" class="xref">RFC6749</a>], <a href="https://www.rfc-editor.org/rfc/rfc6749#section-1.5" class="relref">Section 1.5</a></span>).
          If the AS does not provide a refresh token, the UAC needs to reauthenticate the user
          in order to get a new access token before the currently used access token expires.
          An OP returns an additional ID token that contains claims about 
          the authentication of the user by an authorization server. The ID token can potentially 
          include other optional claims about the user, e.g., the SIP URI, that will be consumed by 
          the UAC and later used to register with the registrar.<a href="#section-2.1.1-3" class="pilcrow">¶</a></p>
<p id="section-2.1.1-4">
          If the UAC receives a 401/407 response with multiple WWW-
          Authenticate/Proxy-Authenticate header fields, providing challenges
          using different authentication schemes for the same realm, the UAC
          provides credentials for one of the schemes that it supports,
          based on local policy.<a href="#section-2.1.1-4" class="pilcrow">¶</a></p>
<aside id="section-2.1.1-5">
            <p id="section-2.1.1-5.1">
          NOTE: At the time of writing, detailed
          procedures for the cases where a UAC receives multiple
          different authentication schemes had not been defined. A
          future specification might define such procedures.<a href="#section-2.1.1-5.1" class="pilcrow">¶</a></p>
</aside>
<aside id="section-2.1.1-6">
            <p id="section-2.1.1-6.1">
          NOTE: The address of the AS might be known to the   
          UAC, e.g., using means of configuration, in which case the UAC can   
          contact the AS in order to obtain the access token   
          before it sends SIP request without credentials.<a href="#section-2.1.1-6.1" class="pilcrow">¶</a></p>
</aside>
</section>
</div>
<div id="sec.sip.uac.protect">
<section id="section-2.1.2">
          <h4 id="name-protecting-the-access-token">
<a href="#section-2.1.2" class="section-number selfRef">2.1.2. </a><a href="#name-protecting-the-access-token" class="section-name selfRef">Protecting the Access Token</a>
          </h4>
<p id="section-2.1.2-1">
          <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span> mandates that access tokens are protected with 
          TLS when in transit. However, SIP makes use of intermediary SIP proxies,
          and TLS only guarantees hop-to-hop protection when used to protect SIP signaling.
          Therefore, the access token <span class="bcp14">MUST</span> be protected in a way so that only authorized SIP
          servers will have access to it. SIP endpoints that support this document <span class="bcp14">MUST</span>
          use encrypted JWTs <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span> for encoding and protecting 
          access tokens when they are included in SIP requests, unless some other mechanism 
          is used to guarantee that only authorized SIP endpoints have access to 
          the access token. TLS can still be used for protecting traffic between
          SIP endpoints and the AS, as defined in <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-2.1.2-1" class="pilcrow">¶</a></p>
<p id="section-2.1.2-2"></p>
</section>
</div>
<div id="sec.sip.uac.req.reg">
<section id="section-2.1.3">
          <h4 id="name-register-request">
<a href="#section-2.1.3" class="section-number selfRef">2.1.3. </a><a href="#name-register-request" class="section-name selfRef">REGISTER Request</a>
          </h4>
<p id="section-2.1.3-1">The procedures in this section apply when the UAC has received a
   challenge that contains a "Bearer" scheme and the UAC has obtained
   a token, as specified in <a href="#sec.sip.uac.obtain" class="xref">Section 2.1.1</a>.<a href="#section-2.1.3-1" class="pilcrow">¶</a></p>
<p id="section-2.1.3-2">The UAC sends a REGISTER request with an Authorization header
   field containing the response to the challenge, including the "Bearer"
   scheme carrying a valid access token in the request, as specified in
   <span>[<a href="#RFC6750" class="xref">RFC6750</a>]</span>.<a href="#section-2.1.3-2" class="pilcrow">¶</a></p>
<p id="section-2.1.3-3">
        Note that if there were multiple challenges with different schemes, then the UAC may be 
        able to successfully retry the request using non-"Bearer" credentials.<a href="#section-2.1.3-3" class="pilcrow">¶</a></p>
<p id="section-2.1.3-4">Typically, a UAC will obtain a new access token for each new
   binding. However, based on local policy, a UAC <span class="bcp14">MAY</span>
   include an access token that has been used for another binding
   associated with the same Address Of Record (AOR) in the request.<a href="#section-2.1.3-4" class="pilcrow">¶</a></p>
<p id="section-2.1.3-5">
        If the access token included in a REGISTER request is not accepted
        and the UAC receives a 401 response or a 407 response, the UAC
        follows the procedures in <a href="#sec.sip.uac.obtain" class="xref">Section 2.1.1</a>.<a href="#section-2.1.3-5" class="pilcrow">¶</a></p>
<p id="section-2.1.3-6"></p>
</section>
</div>
<div id="sec.sip.uac.req.nonreg">
<section id="section-2.1.4">
          <h4 id="name-non-register-request">
<a href="#section-2.1.4" class="section-number selfRef">2.1.4. </a><a href="#name-non-register-request" class="section-name selfRef">Non-REGISTER Request</a>
          </h4>
<p id="section-2.1.4-1">The procedures in this section apply when the UAC has received a
   challenge that contains a "Bearer" scheme and the UAC has obtained a
   token, as specified in <a href="#sec.sip.uac.obtain" class="xref">Section 2.1.1</a>.<a href="#section-2.1.4-1" class="pilcrow">¶</a></p>
<p id="section-2.1.4-2">
          When the UAC sends a request, it <span class="bcp14">MUST</span> include an Authorization header field 
          with a "Bearer" scheme carrying a valid access token obtained from the AS indicated
          in the challenge in the request, as specified in <span>[<a href="#RFC6750" class="xref">RFC6750</a>]</span>.
          Based on local policy, the UAC <span class="bcp14">MAY</span> include an access token that has been used
          for another dialog, or for another stand-alone request, if the target of the
          new request is the same.<a href="#section-2.1.4-2" class="pilcrow">¶</a></p>
<p id="section-2.1.4-3">
          If the access token included in a request is not accepted and the UAC receives 
          a 401 response or a 407 response, the UAC follows the procedures in 
          <a href="#sec.sip.uac.obtain" class="xref">Section 2.1.1</a>.<a href="#section-2.1.4-3" class="pilcrow">¶</a></p>
<p id="section-2.1.4-4"></p>
</section>
</div>
</section>
</div>
<div id="sec.sip.uas">
<section id="section-2.2">
        <h3 id="name-user-agent-server-uas-and-r">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-user-agent-server-uas-and-r" class="section-name selfRef">User Agent Server (UAS) and Registrar Behavior</a>
        </h3>
<p id="section-2.2-1">
        When a UAS or registrar receives a request that fails to contain
        authorization credentials acceptable to it, the UAS/registrar <span class="bcp14">SHOULD</span> challenge the
        request by sending a 401 (Unauthorized) response. If the UAS/registrar
        chooses to challenge the request and is willing to accept an access token
        as a credential, it <span class="bcp14">MUST</span> include a WWW-Authenticate header
        field in the response that indicates a "Bearer" scheme and includes an AS address, 
        encoded as an https URI <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>, from which the UAC can obtain
        an access token.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">
        When a UAS or registrar receives a SIP request that contains an Authorization 
        header field with an access token, the UAS/registrar <span class="bcp14">MUST</span> validate the access 
        token using the procedures associated with the type of access token (structured 
        or reference) used, e.g., <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span>.
        If the token provided is an expired access token, then the UAS/registrar <span class="bcp14">MUST</span> reply with 
        a 401 (Unauthorized) response, as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc6750#section-3" class="relref">Section 3</a> of [<a href="#RFC6750" class="xref">RFC6750</a>]</span>.
        If the validation is successful, the UAS/registrar can continue to process 
        the request using normal SIP procedures. If the validation fails, the UAS/registrar 
        <span class="bcp14">MUST</span> reply with a 401 (Unauthorized) response.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.2-3"></p>
</section>
</div>
<div id="sec.sip.proxy">
<section id="section-2.3">
        <h3 id="name-proxy-behavior">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-proxy-behavior" class="section-name selfRef">Proxy Behavior</a>
        </h3>
<p id="section-2.3-1">
        When a proxy receives a request that fails to contain
        authorization credentials acceptable to it, it <span class="bcp14">SHOULD</span> challenge the
        request by sending a 407 (Proxy Authentication Required) response.
        If the proxy chooses to challenge the request and is willing to accept an access token
        as a credential, it <span class="bcp14">MUST</span> include a Proxy-Authenticate
        header field in the response that indicates a "Bearer" scheme and includes an AS address, 
        encoded as an https URI <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>, from which the UAC can obtain
        an access token.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.3-2">
        When a proxy wishes to authenticate a received request, it <span class="bcp14">MUST</span>
        search the request for Proxy-Authorization header fields with 'realm'
        parameters that match its realm. It then <span class="bcp14">MUST</span> successfully validate
        the credentials from at least one Proxy-Authorization header field
        for its realm. When the scheme is "Bearer", the proxy <span class="bcp14">MUST</span> validate the
        access token using the procedures associated with the type of access 
        token (structured or reference) used, e.g., <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-2.3-2" class="pilcrow">¶</a></p>
<p id="section-2.3-3"></p>
</section>
</div>
</section>
</div>
<div id="at.claims">
<section id="section-3">
      <h2 id="name-access-token-claims">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-access-token-claims" class="section-name selfRef">Access Token Claims</a>
      </h2>
<p id="section-3-1">
    The type of services to which an access token grants access can be determined 
    using different methods. The methods used and the access provided by the token
    are based on local policy agreed between the AS and the registrar.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
    If an access token is encoded as a JWT, it will contain a list of claims 
    <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span>, including both registered and application-specific claims. The 
    registrar can grant access to services based on such claims,  
    some other mechanism, or a combination of claims and some other mechanism.
    If an access token is a reference token, the registrar will grant access 
    based on some other mechanism. Examples of such other mechanisms are 
    introspection <span>[<a href="#RFC7662" class="xref">RFC7662</a>]</span> and user profile lookups.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3"></p>
</section>
</div>
<div id="www-authenticate.response.header">
<section id="section-4">
      <h2 id="name-www-authenticate-response-h">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-www-authenticate-response-h" class="section-name selfRef">WWW-Authenticate Response Header Field</a>
      </h2>
<p id="section-4-1">This section uses ABNF <span>[<a href="#RFC5234" class="xref">RFC5234</a>]</span> to describe the
      syntax of the WWW-Authenticate header  field when used with the "Bearer"
      scheme to challenge the UAC for credentials by extending the
      'challenge' parameter defined by <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span>.<a href="#section-4-1" class="pilcrow">¶</a></p>
<span id="name-bearer-scheme-syntax"></span><div id="bearer-syntax">
<figure id="figure-3">
        <div id="section-4-2.1">
<pre class="sourcecode lang-abnf">
challenge  =/  ("Bearer" LWS bearer-cln *(COMMA bearer-cln))
bearer-cln = realm / scope-param / authz-server-param / error-param /
             auth-param
realm = &lt;defined in RFC 3261&gt;
scope-param = "scope" EQUAL DQUOTE scope DQUOTE
scope = &lt;defined in RFC 6749&gt;
authz-server-param = "authz_server" EQUAL DQUOTE authz-server DQUOTE
authz-server = https-URI
https-URI = &lt;defined in RFC 7230&gt;
error-param = "error" EQUAL DQUOTE error DQUOTE
error = &lt;defined in RFC 6749&gt;
auth-param = &lt;defined in RFC 3261&gt;
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-bearer-scheme-syntax" class="selfRef">"Bearer" Scheme Syntax</a>
        </figcaption></figure>
</div>
<p id="section-4-3">
  The authz_server parameter contains the HTTPS URI, as defined in 
  <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span>, of the AS. The UAC can discover 
  metadata about the AS using a mechanism like the one defined in <span>[<a href="#RFC8414" class="xref">RFC8414</a>]</span>.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">
  The realm and auth-param parameters are defined in <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span>.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">
  Per <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span>, "the realm string alone defines the protection 
  domain". <span>[<a href="#RFC3261" class="xref">RFC3261</a>]</span> states that the realm string must be 
  globally unique and recommends that the realm string contain a hostname or 
  domain name. It also states that the realm string should be a human-readable identifier
  that can be rendered to the user.<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="section-4-6">  
  The scope and error parameters are defined in <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-4-6" class="pilcrow">¶</a></p>
<p id="section-4-7">
  The scope parameter can be used by the registrar/proxy to indicate to the UAC 
  the minimum scope that must be associated with the access token to be able to get 
  service. As defined in <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>, the value of the scope parameter 
  is expressed as a list of space-delimited, case-sensitive strings. The strings are 
  defined by the AS. The values of the scope parameter are out of 
  scope of this document. The UAC will use the scope provided by the registrar to 
  contact the AS and obtain a proper token with the requested scope.<a href="#section-4-7" class="pilcrow">¶</a></p>
<p id="section-4-8">
  The error parameter could be used by the registrar/proxy to indicate to the UAC 
  the reason for the error, with possible values of "invalid_token" or "invalid_scope".<a href="#section-4-8" class="pilcrow">¶</a></p>
<p id="section-4-9"></p>
</section>
</div>
<div id="security.considerations">
<section id="section-5">
      <h2 id="name-security-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-5-1">
      The security considerations for OAuth are defined in <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>.
      The security considerations for "Bearer" tokens are defined in <span>[<a href="#RFC6750" class="xref">RFC6750</a>]</span>.
      The security considerations for JWTs are defined in <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span>.
      These security considerations also apply to SIP usage of access tokens, as defined in this
      document.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
      <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span> mandates that access tokens are protected with 
      TLS when in transit. However, SIP makes use of intermediary SIP proxies,
      and TLS only guarantees hop-to-hop protection when used to protect SIP signaling.
      Therefore, the access token <span class="bcp14">MUST</span> be protected in a way so that only authorized SIP
      servers will have access to it. SIP endpoints that support this document <span class="bcp14">MUST</span>
      use encrypted JWTs <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span> for encoding and protecting 
      access tokens when they are included in SIP requests, unless some other mechanism 
      is used to guarantee that only authorized SIP endpoints have access to 
      the access token. TLS can still be used for protecting traffic between
      SIP endpoints and the AS, as defined in <span>[<a href="#RFC6749" class="xref">RFC6749</a>]</span>.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">
      Single Sign-On (SSO) enables the user to use one set of credentials to
      authenticate once and gain access to multiple SIP and non-SIP services
      using access token(s). If the SSO login is compromised, that single
      point of compromise has a much broader effect than is the case without
      SSO. Further, an attacker can often use a compromised account to set
      up Single Sign-On for other services that the victim has not
      established an account with and sometimes can even switch a dedicated
      account into SSO mode, creating a still broader attack.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">
      Because of that, it is critical to make sure that extra security
      measures be taken to safeguard credentials used for Single Sign-On.
      Examples of such measures include a long passphrase instead of a
      password, enabling multi-factor authentication, and the use of
      the native platform browser when possible, as defined in <span>[<a href="#RFC8252" class="xref">RFC8252</a>]</span>.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">
      Although this is out of scope for this document, it is important to
      carefully consider the claims provided in the tokens used to access
      these services to make sure of the privacy of the user accessing these
      services. As mentioned above, this document calls for encrypting JWTs
      representing the access token.<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">
      It is important that both parties participating in SSO provide
      mechanisms for users to sever the SSO relationship so that it is
      possible without undue difficulty to mitigate a compromise that has
      already happened.<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7">
      The operator of an SSO authentication system has access to
      private information about sites and services that their users log
      into and even, to some extent, their usage patterns.  It's
      important to call these out in privacy disclosures and policies and
      to make sure that users can be aware of the trade-offs between
      convenience and privacy when they choose to use SSO.<a href="#section-5-7" class="pilcrow">¶</a></p>
<p id="section-5-8">
      When a registrar chooses to challenge a REGISTER request, if the registrar
      can provide access to different levels of services, it is <span class="bcp14">RECOMMENDED</span> that
      the registrar include a scope in the response in order to indicate the minimum
      scope needed to register and access basic services. The access token might
      include an extended scope that gives the user access to more advanced features
      beyond basic services. In SIP, the AS administrator will typically decide what level
      of access is provided for a given user.<a href="#section-5-8" class="pilcrow">¶</a></p>
<p id="section-5-9">
      The UAC <span class="bcp14">MUST</span> check the AS URL received in the 401/407 response
      against a list of trusted ASs configured on the UAC in order
      to prevent several classes of possible vulnerabilities when a client blindly
      attempts to use any provided AS.<a href="#section-5-9" class="pilcrow">¶</a></p>
<p id="section-5-10"></p>
</section>
</div>
<div id="iana.considerations">
<section id="section-6">
      <h2 id="name-iana-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<div id="iana.considerations.proxy-authenticate.param">
<section id="section-6.1">
        <h3 id="name-new-proxy-authenticate-head">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-new-proxy-authenticate-head" class="section-name selfRef">New Proxy-Authenticate Header Field Parameters</a>
        </h3>
<p id="section-6.1-1">
        This section defines new SIP header field parameters in the "Header Field
        Parameters and Parameter Values" subregistry of the "Session
        Initiation Protocol (SIP) Parameters" registry: <span>&lt;<a href="https://www.iana.org/assignments/sip-parameters">https://www.iana.org/assignments/sip-parameters</a>&gt;</span><a href="#section-6.1-1" class="pilcrow">¶</a></p>
<span id="name-header-field-proxy-authenti"></span><div id="proxy-authenticate">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-header-field-proxy-authenti" class="selfRef">Header Field: Proxy-Authenticate</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Parameter Name</th>
              <th class="text-left" rowspan="1" colspan="1">Predefined Values</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">authz_server</td>
              <td class="text-left" rowspan="1" colspan="1">No</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8898</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">error</td>
              <td class="text-left" rowspan="1" colspan="1">No</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8898</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">scope</td>
              <td class="text-left" rowspan="1" colspan="1">No</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8898</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<div id="iana.considerations.www-authenticate.param">
<section id="section-6.2">
        <h3 id="name-new-www-authenticate-header">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-new-www-authenticate-header" class="section-name selfRef">New WWW-Authenticate Header Field Parameters</a>
        </h3>
<p id="section-6.2-1">
        This section defines new SIP header field parameters in the "Header Field
        Parameters and Parameter Values" subregistry of the "Session
        Initiation Protocol (SIP) Parameters" registry: <span>&lt;<a href="https://www.iana.org/assignments/sip-parameters">https://www.iana.org/assignments/sip-parameters</a>&gt;</span><a href="#section-6.2-1" class="pilcrow">¶</a></p>
<span id="name-header-field-www-authentica"></span><div id="www-authenticate">
<table class="center" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-header-field-www-authentica" class="selfRef">Header Field: WWW-Authenticate</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Parameter Name</th>
              <th class="text-left" rowspan="1" colspan="1">Predefined Values</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">authz_server</td>
              <td class="text-left" rowspan="1" colspan="1">No</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8898</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">error</td>
              <td class="text-left" rowspan="1" colspan="1">No</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8898</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">scope</td>
              <td class="text-left" rowspan="1" colspan="1">No</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8898</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
</section>
</div>
<section id="section-7">
      <h2 id="name-normative-references">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
      </h2>
<dl class="references">
<dt id="OPENID">[OPENID]</dt>
      <dd>
<span class="refAuthor">Sakimura, N.</span><span class="refAuthor">, Bradley, J.</span><span class="refAuthor">, Jones, M.</span><span class="refAuthor">, de Medeiros, B.</span><span class="refAuthor">, and C. Mortimore</span>, <span class="refTitle">"OpenID Connect Core 1.0"</span>, <time datetime="2014-02" class="refDate">February 2014</time>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
      <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3261">[RFC3261]</dt>
      <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor">, Schulzrinne, H.</span><span class="refAuthor">, Camarillo, G.</span><span class="refAuthor">, Johnston, A.</span><span class="refAuthor">, Peterson, J.</span><span class="refAuthor">, Sparks, R.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, and E. Schooler</span>, <span class="refTitle">"SIP: Session Initiation Protocol"</span>, <span class="seriesInfo">RFC 3261</span>, <span class="seriesInfo">DOI 10.17487/RFC3261</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3261">https://www.rfc-editor.org/info/rfc3261</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5234">[RFC5234]</dt>
      <dd>
<span class="refAuthor">Crocker, D., Ed.</span><span class="refAuthor"> and P. Overell</span>, <span class="refTitle">"Augmented BNF for Syntax Specifications: ABNF"</span>, <span class="seriesInfo">STD 68</span>, <span class="seriesInfo">RFC 5234</span>, <span class="seriesInfo">DOI 10.17487/RFC5234</span>, <time datetime="2008-01" class="refDate">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</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><span class="refAuthor"> and D. Hardt</span>, <span class="refTitle">"The OAuth 2.0 Authorization Framework: Bearer Token Usage"</span>, <span class="seriesInfo">RFC 6750</span>, <span class="seriesInfo">DOI 10.17487/RFC6750</span>, <time datetime="2012-10" 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><span class="refAuthor"> and 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="RFC7519">[RFC7519]</dt>
      <dd>
<span class="refAuthor">Jones, M.</span><span class="refAuthor">, Bradley, J.</span><span class="refAuthor">, and N. Sakimura</span>, <span class="refTitle">"JSON Web Token (JWT)"</span>, <span class="seriesInfo">RFC 7519</span>, <span class="seriesInfo">DOI 10.17487/RFC7519</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7519">https://www.rfc-editor.org/info/rfc7519</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7662">[RFC7662]</dt>
      <dd>
<span class="refAuthor">Richer, J., Ed.</span>, <span class="refTitle">"OAuth 2.0 Token Introspection"</span>, <span class="seriesInfo">RFC 7662</span>, <span class="seriesInfo">DOI 10.17487/RFC7662</span>, <time datetime="2015-10" class="refDate">October 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7662">https://www.rfc-editor.org/info/rfc7662</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="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>
</dl>
</section>
<section id="section-8">
      <h2 id="name-informative-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
      </h2>
<dl class="references">
<dt id="RFC8252">[RFC8252]</dt>
      <dd>
<span class="refAuthor">Denniss, W.</span><span class="refAuthor"> and J. Bradley</span>, <span class="refTitle">"OAuth 2.0 for Native Apps"</span>, <span class="seriesInfo">BCP 212</span>, <span class="seriesInfo">RFC 8252</span>, <span class="seriesInfo">DOI 10.17487/RFC8252</span>, <time datetime="2017-10" class="refDate">October 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8252">https://www.rfc-editor.org/info/rfc8252</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8414">[RFC8414]</dt>
    <dd>
<span class="refAuthor">Jones, M.</span><span class="refAuthor">, Sakimura, N.</span><span class="refAuthor">, and 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>
<div id="acknowledgments">
<section id="section-appendix.a">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.a-1">The authors would like to specially thank <span class="contact-name">Paul       Kyzivat</span> for his multiple detailed reviews and suggested text that
      significantly improved the quality of the document.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">The authors would also like to thank the following for their review
      and feedback on this document:<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3"><span class="contact-name">Olle Johansson</span>, <span class="contact-name">Roman       Shpount</span>, <span class="contact-name">Dale Worley</span>, and <span class="contact-name">Jorgen Axell</span>.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
<p id="section-appendix.a-4">The authors would also like to thank the following for their review
      and feedback of the original document that was replaced with this
      document:<a href="#section-appendix.a-4" class="pilcrow">¶</a></p>
<p id="section-appendix.a-5"><span class="contact-name">Andrew Allen</span>, <span class="contact-name">Martin       Dolly</span>, <span class="contact-name">Keith Drage</span>, <span class="contact-name">Paul       Kyzivat</span>, <span class="contact-name">Jon Peterson</span>, <span class="contact-name">Michael Procter</span>, <span class="contact-name">Roy Radhika</span>,
      <span class="contact-name">Matt Ryan</span>, <span class="contact-name">Ivo Sedlacek</span>,
      <span class="contact-name">Roman Shpount</span>, <span class="contact-name">Robert       Sparks</span>, <span class="contact-name">Asveren Tolga</span>, <span class="contact-name">Dale       Worley</span>, and <span class="contact-name">Yehoshua Gev</span>.<a href="#section-appendix.a-5" class="pilcrow">¶</a></p>
<p id="section-appendix.a-6"><span class="contact-name">Roman Danyliw</span>, <span class="contact-name">Benjamin       Kaduk</span>, <span class="contact-name">Erik Kline</span>, <span class="contact-name">Barry       Leiba</span>, <span class="contact-name">Eric Vyncke</span>, and <span class="contact-name">Magnus Westerlund</span>  provided feedback and suggestions for
      improvements as part of the IESG evaluation of the document. Special
      thanks to <span class="contact-name">Benjamin Kaduk</span> for his detailed and
      comprehensive reviews and comments.<a href="#section-appendix.a-6" class="pilcrow">¶</a></p>
<p id="section-appendix.a-7">The authors would also like to specially thank <span class="contact-name">Jean Mahoney</span> for her multiple reviews, editorial help, and
      the conversion of the XML source file from v2 to v3.<a href="#section-appendix.a-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-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">Rifaat Shekh-Yusef</span></div>
<div dir="auto" class="left"><span class="org">Auth0</span></div>
<div dir="auto" class="left">
<span class="locality">Ottawa</span> <span class="region">Ontario</span> </div>
<div dir="auto" class="left"><span class="country-name">Canada</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:rifaat.s.ietf@gmail.com" class="email">rifaat.s.ietf@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Christer Holmberg</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left"><span class="street-address">Hirsalantie 11</span></div>
<div dir="auto" class="left">FI-<span class="postal-code">02420</span> <span class="locality">Jorvas</span>
</div>
<div dir="auto" class="left"><span class="country-name">Finland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:christer.holmberg@ericsson.com" class="email">christer.holmberg@ericsson.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Victor Pascual</span></div>
<div dir="auto" class="left"><span class="org">Nokia</span></div>
<div dir="auto" class="left">
<span class="locality">Barcelona</span> </div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:victor.pascual_avila@nokia.com" class="email">victor.pascual_avila@nokia.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>