File: rfc9246.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 (3892 lines) | stat: -rw-r--r-- 208,042 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9246: URI Signing for Content Delivery Network Interconnection (CDNI)</title>
<meta content="Ray van Brandenburg" name="author">
<meta content="Kent Leung" name="author">
<meta content="Phil Sorber" name="author">
<meta content="
       This document describes how the concept of URI Signing supports the
      content access control requirements of Content Delivery Network Interconnection (CDNI) and proposes a URI Signing
      method as a JSON Web Token (JWT) profile. 
       The proposed URI Signing method specifies the information needed to
      be included in the URI to transmit the signed JWT, as well as the claims needed
      by the signed JWT to authorize a User Agent (UA). The
      mechanism described can be used both in CDNI and single Content Delivery Network (CDN)
      scenarios. 
    " name="description">
<meta content="xml2rfc 3.12.10" name="generator">
<meta content="jwt, json, token, cdn, url, http, hls, dash" name="keyword">
<meta content="9246" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.10
    Python 3.6.15
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.7.1
    MarkupSafe 2.0.1
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9246.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;
  margin: 0 auto;
}

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9246" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing-26" 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 9246</td>
<td class="center">CDNI URI Signing</td>
<td class="right">June 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">van Brandenburg, 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/rfc9246" class="eref">9246</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-06" class="published">June 2022</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">R. van Brandenburg</div>
<div class="org">Tiledmedia</div>
</div>
<div class="author">
      <div class="author-name">K. Leung</div>
</div>
<div class="author">
      <div class="author-name">P. Sorber</div>
<div class="org">Apple, Inc.</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9246</h1>
<h1 id="title">URI Signing for Content Delivery Network Interconnection (CDNI)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document describes how the concept of URI Signing supports the
      content access control requirements of Content Delivery Network Interconnection (CDNI) and proposes a URI Signing
      method as a JSON Web Token (JWT) profile.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">The proposed URI Signing method specifies the information needed to
      be included in the URI to transmit the signed JWT, as well as the claims needed
      by the signed JWT to authorize a User Agent (UA). The
      mechanism described can be used both in CDNI and single Content Delivery Network (CDN)
      scenarios.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9246">https://www.rfc-editor.org/info/rfc9246</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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></p>
</li>
              <li class="compact toc ulBare 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-background-and-overview-on-" class="xref">Background and Overview on URI Signing</a></p>
</li>
              <li class="compact toc ulBare 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-cdni-uri-signing-overview" class="xref">CDNI URI Signing Overview</a></p>
</li>
              <li class="compact toc ulBare 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-uri-signing-in-a-non-cdni-c" class="xref">URI Signing in a Non-CDNI Context</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-jwt-format-and-processing-r" class="xref">JWT Format and Processing Requirements</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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-jwt-claims" class="xref">JWT Claims</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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-issuer-iss-claim" class="xref">Issuer (iss) Claim</a></p>
</li>
                  <li class="compact toc ulBare 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-subject-sub-claim" class="xref">Subject (sub) Claim</a></p>
</li>
                  <li class="compact toc ulBare 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-audience-aud-claim" class="xref">Audience (aud) Claim</a></p>
</li>
                  <li class="compact toc ulBare 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-expiry-time-exp-claim" class="xref">Expiry Time (exp) Claim</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.5">
                    <p id="section-toc.1-1.2.2.1.2.5.1"><a href="#section-2.1.5" class="xref">2.1.5</a>.  <a href="#name-not-before-nbf-claim" class="xref">Not Before (nbf) Claim</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.6">
                    <p id="section-toc.1-1.2.2.1.2.6.1"><a href="#section-2.1.6" class="xref">2.1.6</a>.  <a href="#name-issued-at-iat-claim" class="xref">Issued At (iat) Claim</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.7">
                    <p id="section-toc.1-1.2.2.1.2.7.1"><a href="#section-2.1.7" class="xref">2.1.7</a>.  <a href="#name-jwt-id-jti-claim" class="xref">JWT ID (jti) Claim</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.8">
                    <p id="section-toc.1-1.2.2.1.2.8.1"><a href="#section-2.1.8" class="xref">2.1.8</a>.  <a href="#name-cdni-claim-set-version-cdni" class="xref">CDNI Claim Set Version (cdniv) Claim</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.9">
                    <p id="section-toc.1-1.2.2.1.2.9.1"><a href="#section-2.1.9" class="xref">2.1.9</a>.  <a href="#name-cdni-critical-claims-set-cd" class="xref">CDNI Critical Claims Set (cdnicrit) Claim</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.10">
                    <p id="section-toc.1-1.2.2.1.2.10.1"><a href="#section-2.1.10" class="xref">2.1.10</a>. <a href="#name-client-ip-address-cdniip-cl" class="xref">Client IP Address (cdniip) Claim</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.11">
                    <p id="section-toc.1-1.2.2.1.2.11.1"><a href="#section-2.1.11" class="xref">2.1.11</a>. <a href="#name-cdni-uri-container-cdniuc-c" class="xref">CDNI URI Container (cdniuc) Claim</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.12">
                    <p id="section-toc.1-1.2.2.1.2.12.1"><a href="#section-2.1.12" class="xref">2.1.12</a>. <a href="#name-cdni-expiration-time-settin" class="xref">CDNI Expiration Time Setting (cdniets) Claim</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.13">
                    <p id="section-toc.1-1.2.2.1.2.13.1"><a href="#section-2.1.13" class="xref">2.1.13</a>. <a href="#name-cdni-signed-token-transport" class="xref">CDNI Signed Token Transport (cdnistt) Claim</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.14">
                    <p id="section-toc.1-1.2.2.1.2.14.1"><a href="#section-2.1.14" class="xref">2.1.14</a>. <a href="#name-cdni-signed-token-depth-cdn" class="xref">CDNI Signed Token Depth (cdnistd) Claim</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.15">
                    <p id="section-toc.1-1.2.2.1.2.15.1"><a href="#section-2.1.15" class="xref">2.1.15</a>. <a href="#name-uri-container-forms" class="xref">URI Container Forms</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.15.2.1">
                        <p id="section-toc.1-1.2.2.1.2.15.2.1.1"><a href="#section-2.1.15.1" class="xref">2.1.15.1</a>.  <a href="#name-uri-hash-container-hash" class="xref">URI Hash Container (hash:)</a></p>
</li>
                      <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.15.2.2">
                        <p id="section-toc.1-1.2.2.1.2.15.2.2.1"><a href="#section-2.1.15.2" class="xref">2.1.15.2</a>.  <a href="#name-uri-regular-expression-cont" class="xref">URI Regular Expression Container (regex:)</a></p>
</li>
                    </ul>
</li>
                </ul>
</li>
              <li class="compact toc ulBare 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-jwt-header" class="xref">JWT Header</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-uri-signing-token-renewal" class="xref">URI Signing Token Renewal</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-overview" class="xref">Overview</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-signed-token-renewal-mechan" class="xref">Signed Token Renewal Mechanism</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.1">
                    <p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="xref">3.2.1</a>.  <a href="#name-required-claims" class="xref">Required Claims</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-communicating-a-signed-jwt-" class="xref">Communicating a Signed JWT in Signed Token Renewal</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3.2.1">
                    <p id="section-toc.1-1.3.2.3.2.1.1"><a href="#section-3.3.1" class="xref">3.3.1</a>.  <a href="#name-support-for-cross-domain-re" class="xref">Support for Cross-Domain Redirection</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-relationship-with-cdni-inte" class="xref">Relationship with CDNI Interfaces</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-cdni-control-interface" class="xref">CDNI Control Interface</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-cdni-footprint-capabilities" class="xref">CDNI Footprint &amp; Capabilities Advertisement Interface</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-cdni-request-routing-redire" class="xref">CDNI Request Routing Redirection Interface</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-cdni-metadata-interface" class="xref">CDNI Metadata Interface</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-cdni-logging-interface" class="xref">CDNI Logging Interface</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-uri-signing-message-flow" class="xref">URI Signing Message Flow</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-http-redirection" class="xref">HTTP Redirection</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-dns-redirection" class="xref">DNS Redirection</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.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-cdni-payload-type" class="xref">CDNI Payload Type</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1.2.1">
                    <p id="section-toc.1-1.6.2.1.2.1.1"><a href="#section-6.1.1" class="xref">6.1.1</a>.  <a href="#name-cdni-urisigning-payload-typ" class="xref">CDNI UriSigning Payload Type</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-cdni-logging-record-type" class="xref">CDNI Logging Record Type</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2.2.1">
                    <p id="section-toc.1-1.6.2.2.2.1.1"><a href="#section-6.2.1" class="xref">6.2.1</a>.  <a href="#name-cdni-logging-record-version" class="xref">CDNI Logging Record Version 2 for HTTP</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-cdni-logging-field-names" class="xref">CDNI Logging Field Names</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.4">
                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-cdni-uri-signing-verificati" class="xref">CDNI URI Signing Verification Code</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.5">
                <p id="section-toc.1-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-cdni-uri-signing-signed-tok" class="xref">CDNI URI Signing Signed Token Transport</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.6">
                <p id="section-toc.1-1.6.2.6.1"><a href="#section-6.6" class="xref">6.6</a>.  <a href="#name-json-web-token-claims-regis" class="xref">JSON Web Token Claims Registration</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.6.2.1">
                    <p id="section-toc.1-1.6.2.6.2.1.1"><a href="#section-6.6.1" class="xref">6.6.1</a>.  <a href="#name-registry-contents" class="xref">Registry Contents</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.7">
                <p id="section-toc.1-1.6.2.7.1"><a href="#section-6.7" class="xref">6.7</a>.  <a href="#name-expert-review-guidance" class="xref">Expert Review Guidance</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-privacy" class="xref">Privacy</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-signed-uri-package-example" class="xref">Signed URI Package Example</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#appendix-A.1" class="xref">A.1</a>.  <a href="#name-simple-example" class="xref">Simple Example</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#appendix-A.2" class="xref">A.2</a>.  <a href="#name-complex-example" class="xref">Complex Example</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#appendix-A.3" class="xref">A.3</a>.  <a href="#name-signed-token-renewal-exampl" class="xref">Signed Token Renewal Example</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-B" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-C" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#appendix-D" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">This document describes the concept of URI Signing and how it can be
      used to provide access authorization in the case of redirection between
      cooperating CDNs and between a Content Service Provider (CSP)
      and a CDN. The primary goal of URI Signing is to make sure that only
      authorized UAs are able to access the content, with a CSP
      being able to authorize every individual request. It should be noted
      that URI Signing is not a content protection scheme; if a CSP wants to
      protect the content itself, other mechanisms, such as Digital Rights Management (DRM), are more
      appropriate. In addition to access control, URI Signing also has
      benefits in reducing the impact of denial-of-service attacks.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">The overall problem space for CDN Interconnection (CDNI) is described
      in the CDNI Problem Statement <span>[<a href="#RFC6707" class="xref">RFC6707</a>]</span>
      specification. This document, along with the <span><a href="#RFC7337" class="xref">Content Distribution Network Interconnection (CDNI) Requirements</a> [<a href="#RFC7337" class="xref">RFC7337</a>]</span> document and the <span><a href="#RFC7336" class="xref">Framework for Content Distribution Network Interconnection (CDNI)</a> [<a href="#RFC7336" class="xref">RFC7336</a>]</span>, describes the
      need for interconnected CDNs to be able to implement an access control
      mechanism that enforces a CSP's distribution policies.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">Specifically, the <span><a href="#RFC7336" class="xref">CDNI Framework</a> [<a href="#RFC7336" class="xref">RFC7336</a>]</span>
      states:<a href="#section-1-3" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-1-4.1">The CSP may also trust the CDN operator to perform actions such as
        delegating traffic to additional downstream CDNs, and to enforce per-request authorization performed by the CSP using
        techniques such as URI Signing.<a href="#section-1-4.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-5">In particular, the following requirement is listed in the <span><a href="#RFC7337" class="xref">CDNI Requirements</a> [<a href="#RFC7337" class="xref">RFC7337</a>]</span>:<a href="#section-1-5" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-1-6.1">
          <blockquote id="section-1-6.1.1">
            <span class="break"></span><dl class="dlParallel" id="section-1-6.1.1.1">
              <dt id="section-1-6.1.1.1.1">MI-16</dt>
              <dd style="margin-left: 1.5em" id="section-1-6.1.1.1.2">{HIGH} The CDNI Metadata interface shall allow signaling of
          authorization checks and validation that are to be performed
          by the Surrogate before delivery.  For example, this could
          potentially include the need to validate information (e.g.,
          Expiry time, Client IP address) required for access
          authorization.<a href="#section-1-6.1.1.1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</blockquote>
</li>
      </ul>
<p id="section-1-7">This document defines a method of signing URIs that allows Surrogates in
      interconnected CDNs to enforce a per-request authorization initiated by
      the CSP. Splitting the role of initiating per-request authorization by
      the CSP and the role of verifying this authorization by the CDN allows
      any arbitrary distribution policy to be enforced across CDNs without the
      need of CDNs to have any awareness of the specific CSP distribution
      policies.<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">The method is implemented using signed JSON Web Tokens (JWTs) <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-1-8" class="pilcrow">¶</a></p>
<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>
<p id="section-1.1-2">This document uses the terminology defined in the <span><a href="#RFC6707" class="xref">CDNI Problem Statement</a> [<a href="#RFC6707" class="xref">RFC6707</a>]</span>.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">This document also uses the terminology of the <span><a href="#RFC7519" class="xref">JSON Web Token (JWT)</a> [<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
<p id="section-1.1-4">In addition, the following terms are used throughout this
        document:<a href="#section-1.1-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-1.1-5">
          <dt id="section-1.1-5.1">FCI:
</dt>
          <dd style="margin-left: 1.5em" id="section-1.1-5.2">Footprint &amp; Capabilities Advertisement interface<a href="#section-1.1-5.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.1-5.3">Signed URI:
          </dt>
          <dd style="margin-left: 1.5em" id="section-1.1-5.4">A URI for which a signed JWT is provided.<a href="#section-1.1-5.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.1-5.5">Target CDN URI:
          </dt>
          <dd style="margin-left: 1.5em" id="section-1.1-5.6">A URI created by the CSP to direct a UA towards the upstream CDN (uCDN). The Target CDN URI can be signed by the CSP and verified by the uCDN and possibly further downstream CDNs (dCDNs).<a href="#section-1.1-5.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.1-5.7">Redirection URI:
          </dt>
          <dd style="margin-left: 1.5em" id="section-1.1-5.8">A URI created by the uCDN to redirect a UA towards the dCDN. The Redirection URI can be signed by the uCDN and verified by the dCDN. In a cascaded CDNI scenario, there can be more than one Redirection URI.<a href="#section-1.1-5.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.1-5.9">Signed Token Renewal: 
          </dt>
          <dd style="margin-left: 1.5em" id="section-1.1-5.10">A series of signed JWTs that are used for subsequent access to a
   set of related resources in a CDN, such as a set of HTTP Adaptive
   Streaming files. Every time a signed JWT is used to access a
   particular resource, a new signed JWT is sent along with the
   resource that can be used to request the next resource in the
   set. When generating a new signed JWT in Signed Token Renewal,
   parameters are carried over from one signed JWT to the next.<a href="#section-1.1-5.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
<div id="background">
<section id="section-1.2">
        <h3 id="name-background-and-overview-on-">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-background-and-overview-on-" class="section-name selfRef">Background and Overview on URI Signing</a>
        </h3>
<p id="section-1.2-1">A CSP and CDN are assumed to have a trust relationship that enables
        the CSP to authorize access to a content item, which is
        realized in practice by including a set of claims in a signed JWT
        in the URI before redirecting a UA to the CDN. Using these
        attributes, it is possible for a CDN to check an incoming content
        request to see whether it was authorized by the CSP (e.g., based on
        a time window or pattern matching the URI). To prevent the UA from altering the claims,
        the JWT <span class="bcp14">MUST</span> be signed.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<p id="section-1.2-2"><a href="#fig_single_cdn" class="xref">Figure 1</a> presents an overview of the URI Signing
        mechanism in the case of a CSP with a single CDN. When the UA browses
        for content on CSP's website (1), it receives HTML web pages with
        embedded content URIs. Upon requesting these URIs, the CSP redirects
        to a CDN, creating a Target CDN URI (2) (alternatively, the Target
        CDN URI itself is embedded in the HTML). The Target CDN URI is the
        Signed URI, which may include the IP address of the UA and/or a time
        window. The Signed URI always contains a signed JWT generated by the
        CSP using a shared secret or private key. Once the UA receives the
        response with the Signed URI, it sends a new HTTP request using the
        Signed URI to the CDN (3). Upon receiving the request, the CDN
        authenticates the Signed URI by verifying the signed JWT.
        If applicable, the CDN checks whether the time window is still valid
        in the Signed URI and the pattern matches the URI of the request.
        After these claims are verified, the CDN delivers the content (4).<a href="#section-1.2-2" class="pilcrow">¶</a></p>
<p id="section-1.2-3">Note: While using a symmetric shared key is supported, it is <span class="bcp14">NOT RECOMMENDED</span>.
        See the <span><a href="#security" class="xref">Security Considerations</a> (<a href="#security" class="xref">Section 7</a>)</span> about the
        limitations of shared keys.<a href="#section-1.2-3" class="pilcrow">¶</a></p>
<span id="name-uri-signing-in-a-cdn-enviro"></span><div id="fig_single_cdn">
<figure id="figure-1">
          <div class="alignLeft art-text artwork" id="section-1.2-4.1">
<pre>
                --------
               /        \
               |   CSP  |&lt; * * * * * * * * * * *
               \        /        Trust         *
                --------      relationship     *
                  ^  |                         *
                  |  |                         *
       1. Browse  |  | 2. Signed               *
            for   |  |    URI                  *
          content |  |                         *
                  |  v                         v
                +------+ 3. Signed URI     --------
                | User |-----------------&gt;/        \
                | Agent|                  |  CDN   |
                |      |&lt;-----------------\        /
                +------+ 4. Content        --------
                            Delivery
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-uri-signing-in-a-cdn-enviro" class="selfRef">URI Signing in a CDN Environment</a>
          </figcaption></figure>
</div>
</section>
</div>
<section id="section-1.3">
        <h3 id="name-cdni-uri-signing-overview">
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-cdni-uri-signing-overview" class="section-name selfRef">CDNI URI Signing Overview</a>
        </h3>
<p id="section-1.3-1">In a CDNI environment, as shown in <a href="#fig_cdni_env" class="xref">Figure 2</a> below, URI Signing operates the same way in the
        initial steps 1 and 2, but the later steps involve multiple CDNs
        delivering the content. The main difference from the
        single CDN case is a redirection step between the uCDN and the
        dCDN. In step 3, the UA may send an HTTP request or a DNS request,
        depending on whether HTTP-based or DNS-based request routing is used.
        The uCDN responds by directing the UA towards the
        dCDN using either a Redirection URI (i.e., a Signed URI generated by
        the uCDN) or a DNS reply, respectively (4). Once the UA
        receives the response, it sends the Redirection URI/Target CDN URI to
        the dCDN (5). The received URI is verified by the
        dCDN before delivering the content (6).<a href="#section-1.3-1" class="pilcrow">¶</a></p>
<p id="section-1.3-2">Note: The CDNI call flows are covered in <span><a href="#operation" class="xref">URI Signing Message Flow</a> (<a href="#operation" class="xref">Section 5</a>)</span>.<a href="#section-1.3-2" class="pilcrow">¶</a></p>
<span id="name-uri-signing-in-a-cdni-envir"></span><div id="fig_cdni_env">
<figure id="figure-2">
          <div class="alignLeft art-text artwork" id="section-1.3-3.1">
<pre>
                                   +-------------------------+
                                   |Request Redirection Modes|
                                   +-------------------------+
                                   | a) HTTP                 |
                                   | b) DNS                  |
                                   +-------------------------+
                --------
               /        \&lt; * * * * * * * * * * * * * *
               |   CSP  |&lt; * * * * * * * * * * *     *
               \        /        Trust         *     *
                --------      relationship     *     *
                  ^  |                         *     *
                  |  | 2. Signed               *     *
       1. Browse  |  |    URI in               *     *
            for   |  |    HTML                 *     *
          content |  |                         *     *
                  |  v   3.a)Signed URI        v     *
                +------+   b)DNS request   --------  * Trust
                | User |-----------------&gt;/        \ * relationship
                | Agent|                  |  uCDN  | * (optional)
                |      |&lt;-----------------\        / *
                +------+ 4.a)Redirection URI-------  *
                  ^  |     b)DNS Reply         ^     *
                  |  |                         *     *
                  |  |      Trust relationship *     *
                  |  |                         *     *
      6. Content  |  | 5.a)Redirection URI     *     *
         delivery |  |   b)Signed URI(after    v     v
                  |  |     DNS exchange)      --------
                  |  +----------------------&gt;/        \ [May be
                  |                          |  dCDN  |  cascaded
                  +--------------------------\        /  CDNs]
                                              --------
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-uri-signing-in-a-cdni-envir" class="selfRef">URI Signing in a CDNI Environment</a>
          </figcaption></figure>
</div>
<p id="section-1.3-4">The trust relationships between CSP, uCDN, and
        dCDN have direct implications for URI Signing. In the case shown in
        <a href="#fig_cdni_env" class="xref">Figure 2</a>, the CSP has a trust relationship with the
        uCDN. The delivery of the content may be delegated to a
        dCDN, which has a relationship with the uCDN but may
        have no relationship with the CSP.<a href="#section-1.3-4" class="pilcrow">¶</a></p>
<p id="section-1.3-5">In CDNI, there are two methods for request routing: DNS-based and
        HTTP-based. For DNS-based request routing, the Signed URI (i.e., the Target
        CDN URI) provided by the CSP reaches the CDN directly. In
        the case where the dCDN does not have a trust relationship
        with the CSP, this means that either an asymmetric public/private key
        method needs to be used for computing the signed JWT (because the CSP and
        dCDN are not able to exchange symmetric shared secret keys). Shared keys <span class="bcp14">MUST NOT</span>
        be redistributed.<a href="#section-1.3-5" class="pilcrow">¶</a></p>
<p id="section-1.3-6">For HTTP-based request routing, the Signed URI (i.e., the Target CDN
        URI) provided by the CSP reaches the uCDN. After this URI has
        been verified by the uCDN, the uCDN
        creates and signs a new Redirection URI, redirecting the UA to the
        dCDN. Since this new URI can have a new signed JWT, the relationship between the
        dCDN and CSP is not relevant. Because a
        relationship between uCDN and dCDN always exists,
        either asymmetric public/private keys or symmetric shared secret keys
        can be used for URI Signing with HTTP-based request routing. Note that the signed Redirection URI <span class="bcp14">MUST</span>
        maintain HTTPS as the scheme if it was present in the original, and it <span class="bcp14">MAY</span> be upgraded from "http:" to "https:".<a href="#section-1.3-6" class="pilcrow">¶</a></p>
<p id="section-1.3-7">Two types of keys can be used for URI Signing: asymmetric keys and
        symmetric shared keys. Asymmetric keys are based on a public/private key pair
        mechanism and always contain a private key known only to the entity
        signing the URI (either CSP or uCDN) and a public key for the
        verification of the Signed URI. With symmetric keys, the same key is
        used by both the signing entity for signing the URI and the
        verifying entity for verifying the Signed URI. Regardless of the type
        of keys used, the verifying entity has to obtain the key in a manner that allows trust to
        be placed in the assertions made using that key (either the
        public or the symmetric key). There are very different requirements
        (outside the scope of this document) for distributing asymmetric keys
        and symmetric keys. Key distribution for symmetric keys requires
        confidentiality to prevent third parties from getting access to the key,
        since they could then generate valid Signed URIs for unauthorized
        requests. Key distribution for asymmetric keys does not require
        confidentiality since public keys can typically be distributed openly
        (because they cannot be used to sign URIs) and the corresponding private keys are kept
        secret by the URI signer.<a href="#section-1.3-7" class="pilcrow">¶</a></p>
<p id="section-1.3-8">Note: While using a symmetric shared key is supported, it is <span class="bcp14">NOT RECOMMENDED</span>.
        See the <span><a href="#security" class="xref">Security Considerations</a> (<a href="#security" class="xref">Section 7</a>)</span> about the
        limitations of shared keys.<a href="#section-1.3-8" class="pilcrow">¶</a></p>
</section>
<section id="section-1.4">
        <h3 id="name-uri-signing-in-a-non-cdni-c">
<a href="#section-1.4" class="section-number selfRef">1.4. </a><a href="#name-uri-signing-in-a-non-cdni-c" class="section-name selfRef">URI Signing in a Non-CDNI Context</a>
        </h3>
<p id="section-1.4-1">While the URI Signing method defined in this document was primarily
        created for the purpose of allowing URI Signing in CDNI scenarios,
        i.e., between a uCDN and a dCDN, there is
        nothing in the defined URI Signing method that precludes it from being
        used in a non-CDNI context. As such, the described mechanism could be
        used in a single-CDN scenario such as shown in <a href="#fig_single_cdn" class="xref">Figure 1</a>
        in <a href="#background" class="xref">Section 1.2</a> for example
        to allow a CSP that uses different CDNs to only have to implement a
        single URI Signing mechanism.<a href="#section-1.4-1" class="pilcrow">¶</a></p>
</section>
</section>
<div id="jwt_profile">
<section id="section-2">
      <h2 id="name-jwt-format-and-processing-r">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-jwt-format-and-processing-r" class="section-name selfRef">JWT Format and Processing Requirements</a>
      </h2>
<p id="section-2-1">The concept behind URI Signing is based on embedding a signed <span><a href="#RFC7519" class="xref">JSON Web Token (JWT)</a> [<a href="#RFC7519" class="xref">RFC7519</a>]</span>
      in an <span><a href="#RFC7230" class="xref">HTTP or HTTPS URI</a> [<a href="#RFC7230" class="xref">RFC7230</a>]</span> (see <span><a href="https://www.rfc-editor.org/rfc/rfc7230#section-2.7" class="relref">Section 2.7</a> of [<a href="#RFC7230" class="xref">RFC7230</a>]</span>). The signed JWT contains a number of
      claims that can be verified to ensure the UA has legitimate access to the content.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">This document specifies the following attribute for embedding a signed JWT in a Target CDN URI or Redirection URI:<a href="#section-2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2-3">
        <dt id="section-2-3.1">URI Signing Package (URISigningPackage): 
        </dt>
        <dd style="margin-left: 1.5em" id="section-2-3.2">The URI attribute that encapsulates all the URI Signing claims in
 a signed JWT encoded format. This attribute is exposed in the Signed
 URI as a path-style parameter or a form-style parameter.<a href="#section-2-3.2" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-2-4">The parameter name of the URI Signing Package Attribute is
      defined in the <span><a href="#metadata" class="xref">CDNI Metadata</a> (<a href="#metadata" class="xref">Section 4.4</a>)</span>. If the CDNI Metadata interface
      is not used, or does not include a parameter name for the URI Signing
      Package Attribute, the parameter name can be set by configuration (out of
      scope of this document).<a href="#section-2-4" class="pilcrow">¶</a></p>
<p id="section-2-5">The URI Signing Package will be found by parsing any path-style parameters and
      form-style parameters looking for a key name matching the URI Signing Package Attribute.
      Both parameter styles <span class="bcp14">MUST</span> be supported to allow flexibility of operation.
      The first matching parameter <span class="bcp14">SHOULD</span> be taken to provide the signed JWT, though providing
      more than one matching key is undefined behavior. Path-style parameters generated in the
      form indicated by <span><a href="https://www.rfc-editor.org/rfc/rfc6570#section-3.2.7" class="relref">Section 3.2.7</a> of [<a href="#RFC6570" class="xref">RFC6570</a>]</span> and
      Form-style parameters generated in the form indicated by Sections <a href="https://www.rfc-editor.org/rfc/rfc6570#section-3.2.8" class="relref">3.2.8</a> and <a href="https://www.rfc-editor.org/rfc/rfc6570#section-3.2.9" class="relref">3.2.9</a> of
      <span>[<a href="#RFC6570" class="xref">RFC6570</a>]</span> <span class="bcp14">MUST</span> be supported.<a href="#section-2-5" class="pilcrow">¶</a></p>
<p id="section-2-6">The following is an example where the URI Signing Package Attribute name is "token" and the signed JWT is "SIGNEDJWT":<a href="#section-2-6" class="pilcrow">¶</a></p>
<div id="section-2-7">
<pre class="sourcecode">http://example.com/media/path?come=data&amp;token=SIGNEDJWT&amp;other=data</pre><a href="#section-2-7" class="pilcrow">¶</a>
</div>
<div id="jwt_claims">
<section id="section-2.1">
        <h3 id="name-jwt-claims">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-jwt-claims" class="section-name selfRef">JWT Claims</a>
        </h3>
<p id="section-2.1-1">This section identifies the set of claims that can be
        used to enforce the CSP distribution policy. New claims can be introduced in the future to extend the
        distribution policy capabilities.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">In order to provide distribution policy flexibility,
        the exact subset of claims used in a given signed JWT is a runtime decision.
        Claim requirements are defined in the <span><a href="#metadata" class="xref">CDNI Metadata</a> (<a href="#metadata" class="xref">Section 4.4</a>)</span>.
        If the CDNI Metadata interface is not used, or
        does not include claim requirements, the claim requirements
        can be set by configuration (out of scope of this document).<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<p id="section-2.1-3">The following claims (where the "JSON Web Token Claims" registry
        claim name is specified in parentheses below) are used to enforce the
        distribution policies.  All of the listed claims are mandatory
        to implement in a URI Signing implementation but are not necessarily
        mandatory to use in a given signed JWT. (The "optional" and
        "mandatory" identifiers in square brackets refer to whether or
        not a given claim <span class="bcp14">MUST</span> be present in a URI Signing JWT.)<a href="#section-2.1-3" class="pilcrow">¶</a></p>
<p id="section-2.1-4">Note: The time on the entities that generate and
        verify the Signed URI <span class="bcp14">MUST</span> be in sync. In the CDNI case, this
        means that CSP, uCDN, and dCDN servers need to be
        time synchronized. It is <span class="bcp14">RECOMMENDED</span> to use
        <span><a href="#RFC5905" class="xref">NTP</a> [<a href="#RFC5905" class="xref">RFC5905</a>]</span> for time synchronization.<a href="#section-2.1-4" class="pilcrow">¶</a></p>
<p id="section-2.1-5">Note: See the <span><a href="#security" class="xref">Security
        Considerations</a> (<a href="#security" class="xref">Section 7</a>)</span> on the limitations of using an
        expiration time and Client IP address for distribution policy
        enforcement.<a href="#section-2.1-5" class="pilcrow">¶</a></p>
<div id="iss_claim">
<section id="section-2.1.1">
          <h4 id="name-issuer-iss-claim">
<a href="#section-2.1.1" class="section-number selfRef">2.1.1. </a><a href="#name-issuer-iss-claim" class="section-name selfRef">Issuer (iss) Claim</a>
          </h4>
<p id="section-2.1.1-1">Issuer (iss) [optional] - The semantics in
            <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.1" class="relref">Section 4.1.1</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span> <span class="bcp14">MUST</span> be followed.
            If this claim is used, it <span class="bcp14">MUST</span> be used to identify the
            Issuer (signer) of the JWT.  In particular, the recipient will have already
            received, in trusted configuration, a mapping of Issuer name to one or more
            keys used to sign JWTs and must verify that the JWT was signed by one of
            those keys. If this claim is used and the CDN verifying the
            signed JWT does not support Issuer verification, or if the
            Issuer in the signed JWT does not match the list of known
            acceptable Issuers, or if the Issuer claim does not
            match the key used to sign the JWT, the CDN <span class="bcp14">MUST</span> reject the request. If the
            received signed JWT contains an Issuer claim, then any
            JWT subsequently generated for CDNI redirection <span class="bcp14">MUST</span> also contain an Issuer
            claim, and the Issuer value <span class="bcp14">MUST</span> be updated to identify the
            redirecting CDN.  If the received signed JWT does not
            contain an Issuer claim, an Issuer claim <span class="bcp14">MAY</span> be added to
            a signed JWT generated for CDNI redirection.<a href="#section-2.1.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sub_claim">
<section id="section-2.1.2">
          <h4 id="name-subject-sub-claim">
<a href="#section-2.1.2" class="section-number selfRef">2.1.2. </a><a href="#name-subject-sub-claim" class="section-name selfRef">Subject (sub) Claim</a>
          </h4>
<p id="section-2.1.2-1">Subject (sub) [optional] - The semantics in <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.2" class="relref">Section 4.1.2</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span> <span class="bcp14">MUST</span> be followed.
            If this claim is used, it <span class="bcp14">MUST</span> be a JSON Web Encryption (<span><a href="#RFC7516" class="xref">JWE</a> [<a href="#RFC7516" class="xref">RFC7516</a>]</span>)
            Object in compact serialization form, because it contains
            personally identifiable information. This claim contains
            information about the Subject (for example, a user or an agent)
            that <span class="bcp14">MAY</span> be used to verify the signed JWT.
            If the received signed JWT contains a Subject claim, then any
            JWT subsequently generated for CDNI redirection <span class="bcp14">MUST</span> also
            contain a Subject claim, and the Subject value <span class="bcp14">MUST</span> be the same
            as in the received signed JWT. A signed JWT generated for CDNI
            redirection <span class="bcp14">MUST NOT</span> add a Subject claim if no Subject claim
            existed in the received signed JWT.<a href="#section-2.1.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="aud_claim">
<section id="section-2.1.3">
          <h4 id="name-audience-aud-claim">
<a href="#section-2.1.3" class="section-number selfRef">2.1.3. </a><a href="#name-audience-aud-claim" class="section-name selfRef">Audience (aud) Claim</a>
          </h4>
<p id="section-2.1.3-1">Audience (aud) [optional] - The semantics in <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3" class="relref">Section 4.1.3</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span> <span class="bcp14">MUST</span> be followed.
            This claim is used to ensure that the CDN verifying the JWT is an intended recipient
            of the request. The claim <span class="bcp14">MUST</span>
            contain an identity belonging to the chain of entities involved in
            processing the request (e.g., identifying the CSP or any CDN in the chain)
            that the recipient is configured to use for the processing of this request.
            A CDN <span class="bcp14">MAY</span> modify the claim as long it can generate a valid signature.<a href="#section-2.1.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="exp_claim">
<section id="section-2.1.4">
          <h4 id="name-expiry-time-exp-claim">
<a href="#section-2.1.4" class="section-number selfRef">2.1.4. </a><a href="#name-expiry-time-exp-claim" class="section-name selfRef">Expiry Time (exp) Claim</a>
          </h4>
<p id="section-2.1.4-1">Expiry Time (exp) [optional] - The semantics in <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.4" class="relref">Section 4.1.4</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span> <span class="bcp14">MUST</span> be followed,
          though URI Signing implementations <span class="bcp14">MUST NOT</span> allow for
          any time-synchronization "leeway".  If this claim is used and the
          CDN verifying the signed JWT does not support Expiry Time
          verification, or if the Expiry Time in the signed JWT corresponds to
          a time equal to or earlier than the time of the content request, the
          CDN <span class="bcp14">MUST</span> reject the request.  If the received signed
          JWT contains an Expiry Time claim, then any JWT subsequently
          generated for CDNI redirection <span class="bcp14">MUST</span> also contain an
          Expiry Time claim, and the Expiry Time value <span class="bcp14">MUST</span> be
          the same as in the received signed JWT.  A signed JWT generated for
          CDNI redirection <span class="bcp14">MUST NOT</span> add an Expiry Time claim if
          no Expiry Time claim existed in the received signed JWT.<a href="#section-2.1.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="nbf_claim">
<section id="section-2.1.5">
          <h4 id="name-not-before-nbf-claim">
<a href="#section-2.1.5" class="section-number selfRef">2.1.5. </a><a href="#name-not-before-nbf-claim" class="section-name selfRef">Not Before (nbf) Claim</a>
          </h4>
<p id="section-2.1.5-1">Not Before (nbf) [optional] - The semantics in <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.5" class="relref">Section 4.1.5</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span> <span class="bcp14">MUST</span> be followed,
            though URI Signing implementations <span class="bcp14">MUST NOT</span> allow for any time-synchronization "leeway".
            If this claim is used and the CDN verifying the signed JWT does not support
            Not Before time verification, or if the Not Before time in the
            signed JWT corresponds to a time later than the time of
            the content request, the CDN <span class="bcp14">MUST</span> reject the
            request.
            If the received signed JWT contains a Not Before time claim, then any
            JWT subsequently generated for CDNI redirection <span class="bcp14">MUST</span> also
            contain a Not Before time claim, and the Not Before time value <span class="bcp14">MUST</span> be
            the same as in the received signed JWT.  A signed JWT
            generated for CDNI redirection <span class="bcp14">MUST NOT</span> add a Not Before time
            claim if no Not Before time claim existed in the received
            signed JWT.<a href="#section-2.1.5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iat_claim">
<section id="section-2.1.6">
          <h4 id="name-issued-at-iat-claim">
<a href="#section-2.1.6" class="section-number selfRef">2.1.6. </a><a href="#name-issued-at-iat-claim" class="section-name selfRef">Issued At (iat) Claim</a>
          </h4>
<p id="section-2.1.6-1">Issued At (iat) [optional] - The semantics in <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.6" class="relref">Section 4.1.6</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span> <span class="bcp14">MUST</span> be followed.
            If the received signed JWT contains an Issued At claim, then any
            JWT subsequently generated for CDNI redirection <span class="bcp14">MUST</span> also contain an Issued At
            claim, and the Issued At value <span class="bcp14">MUST</span> be updated to identify the
            time the new JWT was generated.  If the received signed
            JWT does not contain an Issued At claim, an Issued At
            claim <span class="bcp14">MAY</span> be added to a signed JWT generated for CDNI redirection.<a href="#section-2.1.6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="jti_claim">
<section id="section-2.1.7">
          <h4 id="name-jwt-id-jti-claim">
<a href="#section-2.1.7" class="section-number selfRef">2.1.7. </a><a href="#name-jwt-id-jti-claim" class="section-name selfRef">JWT ID (jti) Claim</a>
          </h4>
<p id="section-2.1.7-1">JWT ID (jti) [optional] - The semantics in <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1.7" class="relref">Section 4.1.7</a> of [<a href="#RFC7519" class="xref">RFC7519</a>]</span> <span class="bcp14">MUST</span> be followed.
            A JWT ID can be used to prevent replay attacks if the CDN stores a
            list of all previously used values and verifies
            that the value in the current JWT has never been used
            before.  If the signed JWT contains a JWT ID claim and the
            CDN verifying the signed JWT either does not support JWT ID
            storage or has previously seen the value used in a request for the same content, then the CDN <span class="bcp14">MUST</span> reject the request.
            If the received signed JWT contains a JWT ID claim, then any
            JWT subsequently generated for CDNI redirection <span class="bcp14">MUST</span> also
            contain a JWT ID claim, and the value <span class="bcp14">MUST</span> be the
            same as in the received signed JWT.
            If the received signed JWT does not contain a
            JWT ID claim, a JWT ID claim <span class="bcp14">MUST NOT</span> be added to a signed JWT
            generated for CDNI redirection. Sizing of the JWT ID is application
            dependent given the desired security constraints.<a href="#section-2.1.7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cdniv_claim">
<section id="section-2.1.8">
          <h4 id="name-cdni-claim-set-version-cdni">
<a href="#section-2.1.8" class="section-number selfRef">2.1.8. </a><a href="#name-cdni-claim-set-version-cdni" class="section-name selfRef">CDNI Claim Set Version (cdniv) Claim</a>
          </h4>
<p id="section-2.1.8-1">CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set Version (cdniv)
            claim provides a means within a signed JWT to tie the claim set to a specific version
            of this specification. The cdniv claim is intended to allow changes in and facilitate
            upgrades across specifications. The type is a JSON integer and the value <span class="bcp14">MUST</span> be set to "1"
            for this version of the specification. In the absence of this claim, the value is assumed
            to be "1". For future versions, this claim will be mandatory. Implementations <span class="bcp14">MUST</span> reject
            signed JWTs with unsupported CDNI Claim Set versions.<a href="#section-2.1.8-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cdnicrit_claim">
<section id="section-2.1.9">
          <h4 id="name-cdni-critical-claims-set-cd">
<a href="#section-2.1.9" class="section-number selfRef">2.1.9. </a><a href="#name-cdni-critical-claims-set-cd" class="section-name selfRef">CDNI Critical Claims Set (cdnicrit) Claim</a>
          </h4>
<p id="section-2.1.9-1">CDNI Critical Claims Set (cdnicrit) [optional] - The CDNI Critical Claims Set (cdnicrit) claim
            indicates that extensions to this specification are being used that
            <span class="bcp14">MUST</span> be understood and processed.  Its value is a comma-separated listing
            of claims in the Signed JWT that use those extensions.
            If any of the listed extension claims are not understood
            and supported by the recipient, then the Signed JWT <span class="bcp14">MUST</span> be rejected.  Producers
            <span class="bcp14">MUST NOT</span> include claim names defined by this specification, duplicate names, or names that do not
            occur as claim names within the Signed JWT in the cdnicrit
            list.  Producers <span class="bcp14">MUST NOT</span> use the empty list "" as the cdnicrit
            value.  Recipients <span class="bcp14">MAY</span> consider the Signed JWT to be invalid if the cdnicrit
            list contains any claim names defined by this
            specification or if any other constraints
            on its use are violated.  This claim <span class="bcp14">MUST</span> be understood and processed by all implementations.<a href="#section-2.1.9-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cdniip_claim">
<section id="section-2.1.10">
          <h4 id="name-client-ip-address-cdniip-cl">
<a href="#section-2.1.10" class="section-number selfRef">2.1.10. </a><a href="#name-client-ip-address-cdniip-cl" class="section-name selfRef">Client IP Address (cdniip) Claim</a>
          </h4>
<p id="section-2.1.10-1">Client IP Address (cdniip) [optional] - The Client IP Address (cdniip) claim holds an IP address or IP prefix for
            which the Signed URI is valid. This is represented in CIDR
            notation with dotted decimal format for <span><a href="#RFC0791" class="xref">IPv4 addresses</a> [<a href="#RFC0791" class="xref">RFC0791</a>]</span> or canonical text
            representation for <span><a href="#RFC5952" class="xref">IPv6 addresses</a> [<a href="#RFC5952" class="xref">RFC5952</a>]</span>.
            The request <span class="bcp14">MUST</span> be rejected if sourced from a client outside the
            specified IP range. Since the Client IP is considered
            personally identifiable information, this field
            <span class="bcp14">MUST</span> be a JSON Web Encryption (<span><a href="#RFC7516" class="xref">JWE</a> [<a href="#RFC7516" class="xref">RFC7516</a>]</span>)
            Object in compact serialization form.  If the CDN verifying the
            signed JWT does not support Client IP verification, or if the
            Client IP in the signed JWT does not match the source IP
            address in the content request, the CDN <span class="bcp14">MUST</span>
            reject the request. The type of this claim is a JSON string that
            contains the JWE.
            If the received signed JWT contains a Client IP claim, then any
            JWT subsequently generated for CDNI redirection <span class="bcp14">MUST</span> also
            contain a Client IP claim, and the Client IP value <span class="bcp14">MUST</span> be
            the same as in the received signed JWT.  A signed JWT
            generated for CDNI redirection <span class="bcp14">MUST NOT</span> add a Client IP
            claim if no Client IP claim existed in the received
            signed JWT.<a href="#section-2.1.10-1" class="pilcrow">¶</a></p>
<p id="section-2.1.10-2">It should be noted that use of this claim can cause issues, for example,
            in situations with dual-stack IPv4 and IPv6 networks, MPTCP, QUIC, and
            mobile clients switching from Wi-Fi to Cellular networks where the client's
            source address can change, even between address families. This claim exists
            mainly for legacy feature parity reasons; therefore, use of this claim should
            be done judiciously. An example of a reasonable use case would be making a
            signed JWT for an internal preview of an asset where the end consumer understands
            that they must be originated from the same IP for the entirety of the session.
            Using this claim at large is <span class="bcp14">NOT RECOMMENDED</span>.<a href="#section-2.1.10-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cdniuc_claim">
<section id="section-2.1.11">
          <h4 id="name-cdni-uri-container-cdniuc-c">
<a href="#section-2.1.11" class="section-number selfRef">2.1.11. </a><a href="#name-cdni-uri-container-cdniuc-c" class="section-name selfRef">CDNI URI Container (cdniuc) Claim</a>
          </h4>
<p id="section-2.1.11-1">URI Container (cdniuc) [mandatory] - The URI Container (cdniuc)
            holds the URI representation before a URI Signing Package is
            added. This representation can take one of several forms detailed in
            <a href="#uri_container_forms" class="xref">Section 2.1.15</a>. If the URI Container used in the signed
            JWT does not match the URI of the content request,  the CDN verifying the
            signed JWT <span class="bcp14">MUST</span> reject the request. When comparing the URI, the percent encoded
            form as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc3986#section-2.1" class="relref">Section 2.1</a> of [<a href="#RFC3986" class="xref">RFC3986</a>]</span> <span class="bcp14">MUST</span> be used. When
            redirecting a URI, the CDN generating the new signed JWT <span class="bcp14">MAY</span> change the URI
            Container to comport with the URI being used in the redirection.<a href="#section-2.1.11-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cdniets_claim">
<section id="section-2.1.12">
          <h4 id="name-cdni-expiration-time-settin">
<a href="#section-2.1.12" class="section-number selfRef">2.1.12. </a><a href="#name-cdni-expiration-time-settin" class="section-name selfRef">CDNI Expiration Time Setting (cdniets) Claim</a>
          </h4>
<p id="section-2.1.12-1">CDNI Expiration Time Setting (cdniets) [optional] - The CDNI Expiration
            Time Setting (cdniets) claim provides a means for setting the value
            of the Expiry Time (exp) claim when generating a subsequent signed JWT
            in Signed Token Renewal. Its type is a JSON numeric value. It
            denotes the number of seconds to be added to the time at which the JWT is verified
            that gives the value of the Expiry Time (exp) claim of the next signed JWT.
            The CDNI Expiration Time Setting (cdniets) <span class="bcp14">SHOULD NOT</span> be used when not using Signed Token Renewal
            and <span class="bcp14">MUST</span> be present when using Signed Token Renewal.<a href="#section-2.1.12-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cdnistt_claim">
<section id="section-2.1.13">
          <h4 id="name-cdni-signed-token-transport">
<a href="#section-2.1.13" class="section-number selfRef">2.1.13. </a><a href="#name-cdni-signed-token-transport" class="section-name selfRef">CDNI Signed Token Transport (cdnistt) Claim</a>
          </h4>
<p id="section-2.1.13-1">CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed Token Transport (cdnistt) claim
          provides a means of signaling the method through which a new signed JWT
          is transported from the CDN to the UA and vice versa for the purpose of Signed Token Renewal. Its type is a JSON integer.
          Values for this claim are defined in <a href="#sec.IANA.cdnistt" class="xref">Section 6.5</a>. If using
          this claim, you <span class="bcp14">MUST</span> also specify a CDNI Expiration Time Setting (cdniets) as noted above.<a href="#section-2.1.13-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cdnistd_claim">
<section id="section-2.1.14">
          <h4 id="name-cdni-signed-token-depth-cdn">
<a href="#section-2.1.14" class="section-number selfRef">2.1.14. </a><a href="#name-cdni-signed-token-depth-cdn" class="section-name selfRef">CDNI Signed Token Depth (cdnistd) Claim</a>
          </h4>
<p id="section-2.1.14-1">CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token Depth (cdnistd) claim is used to
          associate a subsequent signed JWT, generated as the result of a CDNI Signed Token Transport claim,
          with a specific URI subset. Its type is a JSON integer. Signed JWTs <span class="bcp14">MUST NOT</span> use a negative
          value for the CDNI Signed Token Depth claim.<a href="#section-2.1.14-1" class="pilcrow">¶</a></p>
<p id="section-2.1.14-2">If the transport used for Signed Token Transport allows the CDN to associate the path component of a
          URI with tokens (e.g., an HTTP Cookie Path as described in <span><a href="https://www.rfc-editor.org/rfc/rfc6265#section-4.1.2.4" class="relref">Section 4.1.2.4</a> of [<a href="#RFC6265" class="xref">RFC6265</a>]</span>),
          the CDNI Signed Token Depth value is the number of path segments that should be
          considered significant for this association. A CDNI Signed Token Depth of zero means that the
          client <span class="bcp14">SHOULD</span> be directed to return the token with requests for any path. If the CDNI Signed
          Token Depth is greater than zero, then the CDN <span class="bcp14">SHOULD</span> send the client a token to return for
          future requests wherein the first CDNI Signed Token Depth segments of the path match the first
          CDNI Signed Token Depth segments of the Signed URI path. This matching <span class="bcp14">MUST</span> use the URI with the
          token removed, as specified in <a href="#uri_container_forms" class="xref">Section 2.1.15</a>.<a href="#section-2.1.14-2" class="pilcrow">¶</a></p>
<p id="section-2.1.14-3">If the URI path to match contains fewer segments than the CDNI Signed Token Depth claim, a signed JWT
          <span class="bcp14">MUST NOT</span> be generated for the purposes of Signed Token Renewal. If the CDNI Signed Token Depth
          claim is omitted, it means the same thing as if its value were zero. If the received signed JWT
          contains a CDNI Signed Token Depth claim, then any JWT subsequently generated for CDNI
          redirection or Signed Token Transport <span class="bcp14">MUST</span> also contain a CDNI Signed Token Depth claim, and the
          value <span class="bcp14">MUST</span> be the same as in the received signed JWT.<a href="#section-2.1.14-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="uri_container_forms">
<section id="section-2.1.15">
          <h4 id="name-uri-container-forms">
<a href="#section-2.1.15" class="section-number selfRef">2.1.15. </a><a href="#name-uri-container-forms" class="section-name selfRef">URI Container Forms</a>
          </h4>
<p id="section-2.1.15-1">The URI Container (cdniuc) claim takes one of the following forms: 'hash:' or 'regex:'. More forms may be added in the future to extend the capabilities.<a href="#section-2.1.15-1" class="pilcrow">¶</a></p>
<p id="section-2.1.15-2">Before comparing a URI with contents of this container, the following steps <span class="bcp14">MUST</span> be performed:<a href="#section-2.1.15-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.1.15-3.1">Prior to verification, remove the signed JWT from the
            URI. This removal is only for the purpose of determining if the
            URI matches; all other purposes will use the original URI. If the
            signed JWT is terminated by anything other than a sub-delimiter
            (as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc3986#section-2.2" class="relref">Section 2.2</a> of [<a href="#RFC3986" class="xref">RFC3986</a>]</span>), everything from the
            reserved character (as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc3986#section-2.2" class="relref">Section 2.2</a> of [<a href="#RFC3986" class="xref">RFC3986</a>]</span>) that precedes the URI Signing Package Attribute to the last character of the signed
              JWT will be removed, inclusive. Otherwise, everything from the first character of the
              URI Signing Package Attribute to the sub-delimiter that terminates the signed
              JWT will be removed, inclusive.<a href="#section-2.1.15-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-2.1.15-3.2">Normalize the URI according to <span><a href="https://www.rfc-editor.org/rfc/rfc7230#section-2.7.3" class="relref">Section 2.7.3</a> of [<a href="#RFC7230" class="xref">RFC7230</a>]</span> and Sections
       <a href="https://www.rfc-editor.org/rfc/rfc3986#section-6.2.2" class="relref">6.2.2</a> and <a href="https://www.rfc-editor.org/rfc/rfc3986#section-6.2.3" class="relref">6.2.3</a> of 
              <span>[<a href="#RFC3986" class="xref">RFC3986</a>]</span>. This applies to both generation
              and verification of the signed JWT.<a href="#section-2.1.15-3.2" class="pilcrow">¶</a>
</li>
          </ul>
<div id="uri_container_forms_hash">
<section id="section-2.1.15.1">
            <h5 id="name-uri-hash-container-hash">
<a href="#section-2.1.15.1" class="section-number selfRef">2.1.15.1. </a><a href="#name-uri-hash-container-hash" class="section-name selfRef">URI Hash Container (hash:)</a>
            </h5>
<p id="section-2.1.15.1-1">Prefixed with 'hash:', this string is a URL Segment form (<span><a href="https://www.rfc-editor.org/rfc/rfc6920#section-5" class="relref">Section 5</a> of [<a href="#RFC6920" class="xref">RFC6920</a>]</span>) of the URI.<a href="#section-2.1.15.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="uri_container_forms_regex">
<section id="section-2.1.15.2">
            <h5 id="name-uri-regular-expression-cont">
<a href="#section-2.1.15.2" class="section-number selfRef">2.1.15.2. </a><a href="#name-uri-regular-expression-cont" class="section-name selfRef">URI Regular Expression Container (regex:)</a>
            </h5>
<p id="section-2.1.15.2-1">Prefixed with 'regex:', this string is any regular expression compatible with POSIX (Section 9 of <span>[<a href="#POSIX.1" class="xref">POSIX.1</a>]</span>) Extended Regular
            Expression used to match against the
            requested URI.  These regular expressions <span class="bcp14">MUST</span> be
            evaluated in the POSIX locale (Section 7.2 of <span>[<a href="#POSIX.1" class="xref">POSIX.1</a>]</span>).<a href="#section-2.1.15.2-1" class="pilcrow">¶</a></p>
<p id="section-2.1.15.2-2">Note: Because '\' has special meaning in JSON <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span> as the escape character within JSON strings, the regular expression character '\' <span class="bcp14">MUST</span> be escaped as '\\'.<a href="#section-2.1.15.2-2" class="pilcrow">¶</a></p>
<p id="section-2.1.15.2-3">An example of a 'regex:' is the following:<a href="#section-2.1.15.2-3" class="pilcrow">¶</a></p>
<div id="section-2.1.15.2-4">
<pre class="sourcecode">
[^:]*\\://[^/]*/dir/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)?
</pre><a href="#section-2.1.15.2-4" class="pilcrow">¶</a>
</div>
<p id="section-2.1.15.2-5">Note: Due to computational complexity of executing arbitrary regular expressions, it is <span class="bcp14">RECOMMENDED</span> to only execute after verifying the JWT to ensure its authenticity.<a href="#section-2.1.15.2-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="jwt_header">
<section id="section-2.2">
        <h3 id="name-jwt-header">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-jwt-header" class="section-name selfRef">JWT Header</a>
        </h3>
<p id="section-2.2-1">The header of the JWT <span class="bcp14">MAY</span> be passed via the CDNI Metadata interface instead of
      being included in the URISigningPackage. The header value <span class="bcp14">MUST</span> be transmitted in
      the serialized encoded form and prepended to the JWT payload and signature passed in
      the URISigningPackage prior to verification. This reduces the size of the signed JWT
      token.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="uri_signing_token_renewal">
<section id="section-3">
      <h2 id="name-uri-signing-token-renewal">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-uri-signing-token-renewal" class="section-name selfRef">URI Signing Token Renewal</a>
      </h2>
<div id="token_renewal_intro">
<section id="section-3.1">
        <h3 id="name-overview">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-overview" class="section-name selfRef">Overview</a>
        </h3>
<p id="section-3.1-1">For content that is delivered via HTTP in a segmented fashion,
        such as <span><a href="#MPEG-DASH" class="xref">MPEG-DASH</a> [<a href="#MPEG-DASH" class="xref">MPEG-DASH</a>]</span> or <span><a href="#RFC8216" class="xref">HTTP Live Streaming (HLS)</a> [<a href="#RFC8216" class="xref">RFC8216</a>]</span>,
        special provisions need to be made in order to ensure URI Signing can be
        applied. In general, segmented protocols work by breaking large objects
        (e.g., videos) into a sequence of small independent segments. Such segments
        are then referenced by a separate manifest file, which either includes
        a list of URLs to the segments or specifies an algorithm through which
        a User Agent can construct the URLs to the segments. Requests for segments
        therefore originate from the manifest file and, unless the URLs in the
        manifest file point to the CSP, are not subjected to redirection and URI Signing.
        This opens up a vulnerability to malicious User Agents sharing the
        manifest file and deep linking to the segments.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">One method for dealing with this vulnerability would be to include, in
        the manifest itself, Signed URIs that point to the individual segments.
        There exist a number of issues with that approach. First, it requires the
        CDN delivering the manifest to rewrite the manifest file for each User Agent,
        which would require the CDN to be aware of the exact segmentation protocol
        used. Secondly, it could also require the expiration time of the
        Signed URIs to be valid for an extended duration if the content
        described by the manifest is meant to be consumed in real time. For instance, if the manifest file were
        to contain a segmented video stream of more than 30 minutes in length,
        Signed URIs would require to be valid for at least 30 minutes, thereby reducing
        their effectiveness and that of the URI Signing mechanism in general.
        For a more detailed analysis of how segmented protocols such as HTTP Adaptive Streaming protocols affect CDNI,
        see <span><a href="#RFC6983" class="xref">Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)</a> [<a href="#RFC6983" class="xref">RFC6983</a>]</span>.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">The method described in this section allows CDNs to use URI Signing
        for segmented content without
        having to include the Signed URIs in the manifest files themselves.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="uri_signing_mechanism">
<section id="section-3.2">
        <h3 id="name-signed-token-renewal-mechan">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-signed-token-renewal-mechan" class="section-name selfRef">Signed Token Renewal Mechanism</a>
        </h3>
<p id="section-3.2-1">In order to allow for effective access control of segmented content, the
        URI Signing mechanism defined in this section is based on a method
        through which subsequent segment requests can be linked together.
        As part of the JWT verification procedure, the CDN can generate a new
        signed JWT that the UA can use to do a subsequent request. More specifically,
        whenever a UA successfully retrieves a segment, it receives, in the
        HTTP 2xx Successful message, a signed JWT that it can use whenever it
        requests the next segment. As long as each successive signed JWT
        is correctly verified before a new one is generated, the model is not
        broken, and the User Agent can successfully retrieve additional segments.
        Given the fact that with segmented protocols it is usually not possible to
        determine a priori which segment will be requested next (i.e., to allow for
        seeking within the content and for switching to a different representation),
        the Signed Token Renewal uses the
        URI Regular Expression Container scoping mechanisms in the URI Container
        (cdniuc) claim to allow a signed JWT to be valid for more than one URL.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">In order for this renewal of signed JWTs to work, it is necessary for
        a UA to extract the signed JWT from the HTTP 2xx Successful message of an
        earlier request and use it to retrieve the next segment. The exact mechanism
        by which the client does this is outside the scope of this document.
        However, in order to also support legacy UAs that do not include any
        specific provisions for the handling of signed JWTs, <a href="#communicating_token" class="xref">Section 3.3</a>
        defines a mechanism using HTTP Cookies <span>[<a href="#RFC6265" class="xref">RFC6265</a>]</span> that allows such UAs to support
        the concept of renewing signed JWTs without requiring any additional UA support.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<section id="section-3.2.1">
          <h4 id="name-required-claims">
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-required-claims" class="section-name selfRef">Required Claims</a>
          </h4>
<p id="section-3.2.1-1">The <span><a href="#cdnistt_claim" class="xref">cdnistt claim</a> (<a href="#cdnistt_claim" class="xref">Section 2.1.13</a>)</span> and <span><a href="#cdniets_claim" class="xref">cdniets claim</a> (<a href="#cdniets_claim" class="xref">Section 2.1.12</a>)</span>
            <span class="bcp14">MUST</span> both be present for Signed Token Renewal. cdnistt <span class="bcp14">MAY</span> be set to
          a value of '0' to mean no Signed Token Renewal, but there still <span class="bcp14">MUST</span> be a corresponding cdniets that verifies as
          a JSON number. However, if use of Signed Token Renewal is not desired, it is <span class="bcp14">RECOMMENDED</span> to simply omit both.<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="communicating_token">
<section id="section-3.3">
        <h3 id="name-communicating-a-signed-jwt-">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-communicating-a-signed-jwt-" class="section-name selfRef">Communicating a Signed JWT in Signed Token Renewal</a>
        </h3>
<p id="section-3.3-1">This section assumes the value of the CDNI Signed Token Transport (cdnistt) claim
        has been set to 1.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">When using the Signed Token Renewal mechanism, the signed JWT is
        transported to the UA via a 'URISigningPackage' cookie added to the
        HTTP 2xx Successful message along with the content being returned to
        the UA, or to the HTTP 3xx Redirection message in case the UA is
        redirected to a different server.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<section id="section-3.3.1">
          <h4 id="name-support-for-cross-domain-re">
<a href="#section-3.3.1" class="section-number selfRef">3.3.1. </a><a href="#name-support-for-cross-domain-re" class="section-name selfRef">Support for Cross-Domain Redirection</a>
          </h4>
<p id="section-3.3.1-1">For security purposes, the use of cross-domain cookies is not supported
          in some application environments. As a result, the Cookie-based
          method for transport of the Signed Token described in <a href="#communicating_token" class="xref">Section 3.3</a>
          might break if used in combination with an HTTP 3xx Redirection
          response where the target URL is in a different domain. In such
          scenarios, Signed Token Renewal of a signed JWT <span class="bcp14">SHOULD</span> be communicated
          via the query string instead, in a similar fashion to how regular
          signed JWTs (outside of Signed Token Renewal) are communicated. Note
          the value of the CDNI Signed Token Transport (cdnistt) claim
          <span class="bcp14">MUST</span> be set to 2.<a href="#section-3.3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.3.1-2">Note that the process described herein only works in cases where both the manifest
          file and segments constituting the segmented content are delivered from
          the same domain. In other words, any redirection between different domains needs to be
          carried out while retrieving the manifest file.<a href="#section-3.3.1-2" class="pilcrow">¶</a></p>
</section>
</section>
</div>
</section>
</div>
<div id="cdni_interfaces">
<section id="section-4">
      <h2 id="name-relationship-with-cdni-inte">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-relationship-with-cdni-inte" class="section-name selfRef">Relationship with CDNI Interfaces</a>
      </h2>
<p id="section-4-1">Some of the CDNI Interfaces need enhancements to support URI Signing.
      A dCDN that supports URI Signing needs to be
      able to advertise this capability to the uCDN. The uCDN
      needs to select a dCDN based on such capability when the CSP
      requires access control to enforce its distribution policy via URI
      Signing. Also, the uCDN needs to be able to distribute via the
      CDNI Metadata interface the information necessary to allow the
      dCDN to verify a Signed URI. Events that pertain to URI
      Signing (e.g., request denial or delivery after an access authorization decision has been made)
      need to be included in the logs communicated through the CDNI Logging
      interface.<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="control">
<section id="section-4.1">
        <h3 id="name-cdni-control-interface">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-cdni-control-interface" class="section-name selfRef">CDNI Control Interface</a>
        </h3>
<p id="section-4.1-1">URI Signing has no impact on this interface.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="advertisement">
<section id="section-4.2">
        <h3 id="name-cdni-footprint-capabilities">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-cdni-footprint-capabilities" class="section-name selfRef">CDNI Footprint &amp; Capabilities Advertisement Interface</a>
        </h3>
<p id="section-4.2-1">The CDNI Request Routing: Footprint and Capabilities
        Semantics document <span>[<a href="#RFC8008" class="xref">RFC8008</a>]</span> defines support for
        advertising CDNI Metadata capabilities via CDNI Payload
        Type. The CDNI Payload Type registered in <a href="#sec.IANA.payload" class="xref">Section 6.1</a>
        can be used for capability advertisement.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="redirection">
<section id="section-4.3">
        <h3 id="name-cdni-request-routing-redire">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-cdni-request-routing-redire" class="section-name selfRef">CDNI Request Routing Redirection Interface</a>
        </h3>
<p id="section-4.3-1">The <span><a href="#RFC7975" class="xref">CDNI Request Routing
        Redirection Interface</a> [<a href="#RFC7975" class="xref">RFC7975</a>]</span> describes the recursive request
        redirection method. For URI Signing, the uCDN signs the URI
        provided by the dCDN. URI Signing therefore has no impact
        on this interface.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="metadata">
<section id="section-4.4">
        <h3 id="name-cdni-metadata-interface">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-cdni-metadata-interface" class="section-name selfRef">CDNI Metadata Interface</a>
        </h3>
<p id="section-4.4-1">The <span><a href="#RFC8006" class="xref">CDNI Metadata
        Interface</a> [<a href="#RFC8006" class="xref">RFC8006</a>]</span> describes the CDNI Metadata distribution needed to
        enable content acquisition and delivery. For URI Signing, a new
        CDNI Metadata object is specified.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">The UriSigning Metadata object contains information to enable URI
        Signing and verification by a dCDN. The UriSigning properties are
        defined below.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-4.4-3.1">
            <p id="section-4.4-3.1.1">Property: enforce<a href="#section-4.4-3.1.1" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-4.4-3.1.2.1">
                <span class="break"></span><dl class="dlParallel" id="section-4.4-3.1.2.1.1">
                  <dt id="section-4.4-3.1.2.1.1.1">Description: 
                  </dt>
                  <dd style="margin-left: 1.5em" id="section-4.4-3.1.2.1.1.2">URI Signing enforcement flag. Specifically, this flag indicates if the access to content is subject to URI Signing. URI Signing requires the dCDN to ensure that the URI is signed and verified before delivering content. Otherwise, the dCDN does not perform verification, regardless of whether or not the URI is signed.<a href="#section-4.4-3.1.2.1.1.2" class="pilcrow">¶</a>
</dd>
                  <dd class="break"></dd>
<dt id="section-4.4-3.1.2.1.1.3">Type:
</dt>
                  <dd style="margin-left: 1.5em" id="section-4.4-3.1.2.1.1.4">Boolean<a href="#section-4.4-3.1.2.1.1.4" class="pilcrow">¶</a>
</dd>
                  <dd class="break"></dd>
<dt id="section-4.4-3.1.2.1.1.5">Mandatory-to-Specify:
</dt>
                  <dd style="margin-left: 1.5em" id="section-4.4-3.1.2.1.1.6">No. The default is true.<a href="#section-4.4-3.1.2.1.1.6" class="pilcrow">¶</a>
</dd>
                <dd class="break"></dd>
</dl>
</li>
            </ul>
</li>
          <li class="normal ulEmpty" id="section-4.4-3.2">
            <p id="section-4.4-3.2.1">Property: issuers<a href="#section-4.4-3.2.1" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-4.4-3.2.2.1">
                <span class="break"></span><dl class="dlParallel" id="section-4.4-3.2.2.1.1">
                  <dt id="section-4.4-3.2.2.1.1.1">Description:
</dt>
                  <dd style="margin-left: 1.5em" id="section-4.4-3.2.2.1.1.2">A list of valid Issuers against which                            
                the Issuer claim in the signed JWT may be cross-referenced.<a href="#section-4.4-3.2.2.1.1.2" class="pilcrow">¶</a>
</dd>
                  <dd class="break"></dd>
<dt id="section-4.4-3.2.2.1.1.3">Type:
</dt>
                  <dd style="margin-left: 1.5em" id="section-4.4-3.2.2.1.1.4">Array of Strings<a href="#section-4.4-3.2.2.1.1.4" class="pilcrow">¶</a>
</dd>
                  <dd class="break"></dd>
<dt id="section-4.4-3.2.2.1.1.5">Mandatory-to-Specify:
</dt>
                  <dd style="margin-left: 1.5em" id="section-4.4-3.2.2.1.1.6">No. The default is an empty list.  An empty list means that any Issuer in
the trusted key store of Issuers is acceptable.<a href="#section-4.4-3.2.2.1.1.6" class="pilcrow">¶</a>
</dd>
                <dd class="break"></dd>
</dl>
</li>
            </ul>
</li>
          <li class="normal ulEmpty" id="section-4.4-3.3">
            <p id="section-4.4-3.3.1">Property: package-attribute<a href="#section-4.4-3.3.1" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-4.4-3.3.2.1">
                <span class="break"></span><dl class="dlParallel" id="section-4.4-3.3.2.1.1">
                  <dt id="section-4.4-3.3.2.1.1.1">Description:
                  </dt>
                  <dd style="margin-left: 1.5em" id="section-4.4-3.3.2.1.1.2">The attribute name to use for the URI Signing                    
                Package.<a href="#section-4.4-3.3.2.1.1.2" class="pilcrow">¶</a>
</dd>
                  <dd class="break"></dd>
<dt id="section-4.4-3.3.2.1.1.3">
 Type:
                  </dt>
                  <dd style="margin-left: 1.5em" id="section-4.4-3.3.2.1.1.4">String<a href="#section-4.4-3.3.2.1.1.4" class="pilcrow">¶</a>
</dd>
                  <dd class="break"></dd>
<dt id="section-4.4-3.3.2.1.1.5">Mandatory-to-Specify:</dt>
                  <dd style="margin-left: 1.5em" id="section-4.4-3.3.2.1.1.6">No. The default is
                "URISigningPackage".<a href="#section-4.4-3.3.2.1.1.6" class="pilcrow">¶</a>
</dd>
                <dd class="break"></dd>
</dl>
</li>
            </ul>
</li>
          <li class="normal ulEmpty" id="section-4.4-3.4">
            <p id="section-4.4-3.4.1">Property: jwt-header<a href="#section-4.4-3.4.1" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-4.4-3.4.2.1">
                <span class="break"></span><dl class="dlParallel" id="section-4.4-3.4.2.1.1">
                  <dt id="section-4.4-3.4.2.1.1.1">Description:
                  </dt>
                  <dd style="margin-left: 1.5em" id="section-4.4-3.4.2.1.1.2">The header part of JWT that is used for verifying a signed
 JWT when the JWT token in the URI Signing Package does not
 contain a header part.<a href="#section-4.4-3.4.2.1.1.2" class="pilcrow">¶</a>
</dd>
                  <dd class="break"></dd>
<dt id="section-4.4-3.4.2.1.1.3">Type:    
                  </dt>
                  <dd style="margin-left: 1.5em" id="section-4.4-3.4.2.1.1.4">String<a href="#section-4.4-3.4.2.1.1.4" class="pilcrow">¶</a>
</dd>
                  <dd class="break"></dd>
<dt id="section-4.4-3.4.2.1.1.5">Mandatory-to-Specify:
                  </dt>
                  <dd style="margin-left: 1.5em" id="section-4.4-3.4.2.1.1.6">No. By default, the header is assumed to be included 
in the JWT token.<a href="#section-4.4-3.4.2.1.1.6" class="pilcrow">¶</a>
</dd>
                <dd class="break"></dd>
</dl>
</li>
            </ul>
</li>
        </ul>
<p id="section-4.4-4">The following is an example of a URI Signing metadata payload with all default values:<a href="#section-4.4-4" class="pilcrow">¶</a></p>
<div id="section-4.4-5">
<pre class="lang-json sourcecode">
{
  "generic-metadata-type": "MI.UriSigning"
  "generic-metadata-value": {}
}
</pre><a href="#section-4.4-5" class="pilcrow">¶</a>
</div>
<p id="section-4.4-6">The following is an example of a URI Signing metadata payload with explicit values:<a href="#section-4.4-6" class="pilcrow">¶</a></p>
<div id="section-4.4-7">
<pre class="lang-json sourcecode">
{
  "generic-metadata-type": "MI.UriSigning"
  "generic-metadata-value":
    {
      "enforce": true,
      "issuers": ["csp", "ucdn1", "ucdn2"],
      "package-attribute": "usp",
      "jwt-header":
        {
            "alg": "ES256",
            "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0"
        }
    }
}
</pre><a href="#section-4.4-7" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="logging">
<section id="section-4.5">
        <h3 id="name-cdni-logging-interface">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-cdni-logging-interface" class="section-name selfRef">CDNI Logging Interface</a>
        </h3>
<p id="section-4.5-1">For URI Signing, the dCDN reports that enforcement of the
        access control was applied to the request for content delivery. When
        the request is denied due to enforcement of URI Signing, the reason is
        logged.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<p id="section-4.5-2">The following CDNI Logging field for URI Signing <span class="bcp14">SHOULD</span> be
        supported in the HTTP Request Logging Record as specified in "<a href="#RFC7937" class="xref">Content Distribution Network Interconnection (CDNI) Logging Interface</a>" <span>[<a href="#RFC7937" class="xref">RFC7937</a>]</span>
        using the new "cdni_http_request_v2" record-type registered in
        <a href="#sec.IANA.record_type.cdni_http_request_v2" class="xref">Section 6.2.1</a>.<a href="#section-4.5-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.5-3.1">
            <p id="section-4.5-3.1.1">s-uri-signing (mandatory):<a href="#section-4.5-3.1.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.5-3.1.2">
              <dt id="section-4.5-3.1.2.1">Format:
              </dt>
              <dd style="margin-left: 1.5em" id="section-4.5-3.1.2.2">3DIGIT<a href="#section-4.5-3.1.2.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.5-3.1.2.3">Field value:
              </dt>
              <dd style="margin-left: 1.5em" id="section-4.5-3.1.2.4">this characterizes the URI Signing verification performed by
       the Surrogate on the request. The allowed values are registered
       in <a href="#sec.IANA.field.s-uri-signing.values" class="xref">Section 6.4</a>.<a href="#section-4.5-3.1.2.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.5-3.1.2.5">Occurrence:
              </dt>
              <dd style="margin-left: 1.5em" id="section-4.5-3.1.2.6">there <span class="bcp14">MUST</span> be zero or exactly one instance of    
                this field.<a href="#section-4.5-3.1.2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</li>
          <li class="normal" id="section-4.5-3.2">
            <p id="section-4.5-3.2.1">s-uri-signing-deny-reason (optional):<a href="#section-4.5-3.2.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.5-3.2.2">
              <dt id="section-4.5-3.2.2.1">Format:
              </dt>
              <dd style="margin-left: 1.5em" id="section-4.5-3.2.2.2">QSTRING<a href="#section-4.5-3.2.2.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.5-3.2.2.3">Field value:
              </dt>
              <dd style="margin-left: 1.5em" id="section-4.5-3.2.2.4">a string for providing further information in case the signed JWT was rejected, e.g., for debugging purposes.<a href="#section-4.5-3.2.2.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.5-3.2.2.5">Occurrence: 
              </dt>
              <dd style="margin-left: 1.5em" id="section-4.5-3.2.2.6">there <span class="bcp14">MUST</span> be zero or exactly one instance of    
                this field.<a href="#section-4.5-3.2.2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="operation">
<section id="section-5">
      <h2 id="name-uri-signing-message-flow">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-uri-signing-message-flow" class="section-name selfRef">URI Signing Message Flow</a>
      </h2>
<p id="section-5-1">URI Signing supports both HTTP-based and DNS-based request routing.
      <span><a href="#RFC7519" class="xref">JSON Web Token (JWT)</a> [<a href="#RFC7519" class="xref">RFC7519</a>]</span> defines a
      compact, URL-safe means of representing
      claims to be transferred between two parties.  The claims in a Signed JWT
      are encoded as a JSON object that is used as the payload of a JSON
      Web Signature (JWS) structure enabling the claims to be digitally
      signed or integrity protected with a Message Authentication Code
      (MAC).<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="http">
<section id="section-5.1">
        <h3 id="name-http-redirection">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-http-redirection" class="section-name selfRef">HTTP Redirection</a>
        </h3>
<p id="section-5.1-1">For HTTP-based request routing, a set of
        information that is unique to a given end user content request
        is included in a Signed JWT, using
        key information that is specific to a pair of adjacent CDNI hops (e.g.,
        between the CSP and the uCDN or between the
        uCDN and a dCDN). This allows a CDNI hop to ascertain the
        authenticity of a given request received from a previous CDNI hop.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">The URI Signing method
        (assuming HTTP redirection, iterative request routing, and a CDN
        path with two CDNs) includes the following steps:<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<span id="name-http-based-request-routing-"></span><div id="fig_http_routing">
<figure id="figure-3">
          <div class="alignLeft art-text artwork" id="section-5.1-3.1">
<pre>
     End-User           dCDN                 uCDN                 CSP
     |                    |                    |                    |
     |               1.CDNI FCI used to        |                    |
     |        advertise URI Signing capability |                    |
     |                    |-------------------&gt;|                    |
     |                    |                    |                    |
     |              2.Provides information to verify Signed JWT     |
     |                    |                    |&lt;-------------------|
     |                    |                    |                    |
     |        3.CDNI Metadata interface used to|                    |
     |           provide URI Signing attributes|                    |
     |                    |&lt;-------------------|                    |
     :                    :                    :                    :
     :   (Later in time)  :                    :                    :
     |4.Authorization request                  |                    |
     |-------------------------------------------------------------&gt;|
     |                    |                    |  [Apply distribution
     |                    |                    |   policy]          |
     |                    |                    |                    |
     |                    |             (ALT: Authorization decision)
     |5.Request is denied |                    |      &lt;Negative&gt;    |
     |&lt;-------------------------------------------------------------|
     |                    |                    |                    |
     |6.CSP provides Signed URI                |      &lt;Positive&gt;    |
     |&lt;-------------------------------------------------------------|
     |                    |                    |                    |
     |7.Content request   |                    |                    |
     |----------------------------------------&gt;| [Verify URI        |
     |                    |                    |  signature]        |
     |                    |                    |                    |
     |                    |    (ALT: Verification result)           |
     |8.Request is denied |          &lt;Negative&gt;|                    |
     |&lt;----------------------------------------|                    |
     |                    |                    |                    |
     |9.Re-sign URI and redirect to  &lt;Positive&gt;|                    |
     |  dCDN (newly Signed URI)                |                    |
     |&lt;----------------------------------------|                    |
     |                    |                    |                    |
     |10.Content request  |                    |                    |
     |-------------------&gt;| [Verify URI        |                    |
     |                    |  signature]        |                    |
     |                    |                    |                    |
     |    (ALT: Verification result)           |                    |
     |11.Request is denied| &lt;Negative&gt;         |                    |
     |&lt;-------------------|                    |                    |
     |                    |                    |                    |
     |12.Content delivery | &lt;Positive&gt;         |                    |
     |&lt;-------------------|                    |                    |
     :                    :                    :                    :
     :   (Later in time)  :                    :                    :
     |13.CDNI Logging interface to include URI Signing information  |
     |                    |-------------------&gt;|                    |</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-http-based-request-routing-" class="selfRef">HTTP-Based Request Routing with URI Signing</a>
          </figcaption></figure>
</div>
<ol start="1" type="1" class="normal type-1" id="section-5.1-4">
<li id="section-5.1-4.1">Using the CDNI Footprint &amp; Capabilities Advertisement
            interface, the dCDN advertises its capabilities
            including URI Signing support to the uCDN.<a href="#section-5.1-4.1" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-4.2">CSP provides to the uCDN the information needed to
            verify Signed URIs from that CSP. For example, this
            information will include one or more keys used for validation.<a href="#section-5.1-4.2" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-4.3">Using the CDNI Metadata interface, the uCDN
            communicates to a dCDN the information needed to
            verify Signed URIs from the uCDN for the given
            CSP. For example, this information may include the URI query
            string parameter name for the URI Signing Package Attribute
            in addition to keys used for validation.<a href="#section-5.1-4.3" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-4.4">When a UA requests a piece of protected content from the CSP,
            the CSP makes a specific authorization decision for this unique
            request based on its local distribution policy.<a href="#section-5.1-4.4" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-4.5">If the authorization decision is negative, the CSP rejects the
            request and sends an error code (e.g., 403 Forbidden) in the HTTP
            response.<a href="#section-5.1-4.5" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-4.6">If the authorization decision is positive, the CSP computes a
            Signed JWT that is based on unique parameters of that request and
            conveys it to the end user as the URI to use to request the
            content.<a href="#section-5.1-4.6" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-4.7">On receipt of the corresponding content request, the
            uCDN verifies the Signed JWT in the URI using the
            information provided by the CSP.<a href="#section-5.1-4.7" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-4.8">If the verification result is negative, the uCDN rejects
            the request and sends an error code 403 Forbidden in the HTTP
            response.<a href="#section-5.1-4.8" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-4.9">If the verification result is positive, the uCDN computes a
            Signed JWT that is based on unique parameters of that request and
            provides it to the end user as the URI to use to further request the
            content from the dCDN.<a href="#section-5.1-4.9" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-4.10">On receipt of the corresponding content request, the
            dCDN verifies the Signed JWT in the Signed URI using the
            information provided by the uCDN in the CDNI
            Metadata.<a href="#section-5.1-4.10" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-4.11">If the verification result is negative, the dCDN rejects the
            request and sends an error code 403 Forbidden in the HTTP
            response.<a href="#section-5.1-4.11" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-4.12">If the verification result is positive, the dCDN serves the
            request and delivers the content.<a href="#section-5.1-4.12" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-4.13">At a later time, the dCDN reports logging events that
            include URI Signing information.<a href="#section-5.1-4.13" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-5.1-5">With HTTP-based request routing, URI Signing matches well the
        general chain of trust model of CDNI both with symmetric and
        asymmetric keys because the key information only needs to be specific
        to a pair of adjacent CDNI hops.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
<p id="section-5.1-6">Note: While using a symmetric shared key is supported, it is <span class="bcp14">NOT RECOMMENDED</span>.
        See the <span><a href="#security" class="xref">Security Considerations</a> (<a href="#security" class="xref">Section 7</a>)</span> about the
        limitations of shared keys.<a href="#section-5.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dns">
<section id="section-5.2">
        <h3 id="name-dns-redirection">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-dns-redirection" class="section-name selfRef">DNS Redirection</a>
        </h3>
<p id="section-5.2-1">For DNS-based request routing, the CSP and uCDN must
        agree on a trust model appropriate to the security requirements of the
        CSP's particular content. Use of asymmetric public/private keys allows
        for unlimited distribution of the public key to dCDNs.
        However, if a shared secret key is required, then the distribution <span class="bcp14">SHOULD</span>
        be performed by the CSP directly.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">Note: While using a symmetric shared key is supported, it is <span class="bcp14">NOT RECOMMENDED</span>.
        See the <span><a href="#security" class="xref">Security Considerations</a> (<a href="#security" class="xref">Section 7</a>)</span> about the
        limitations of shared keys.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2-3">The URI Signing method
        (assuming iterative DNS request routing and a CDN path with two
        CDNs) includes the following steps.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
<span id="name-dns-based-request-routing-w"></span><div id="fig_dns_routing">
<figure id="figure-4">
          <div class="alignLeft art-text artwork" id="section-5.2-4.1">
<pre>
     End-User            dCDN                 uCDN                CSP
     |                    |                    |                    |
     |               1.CDNI FCI used to        |                    |
     |        advertise URI Signing capability |                    |
     |                    |-------------------&gt;|                    |
     |                    |                    |                    |
     |              2.Provides information to verify Signed JWT     |
     |                    |                    |&lt;-------------------|
     |        3.CDNI Metadata interface used to|                    |
     |           provide URI Signing attributes|                    |
     |                    |&lt;-------------------|                    |
     :                    :                    :                    :
     :   (Later in time)  :                    :                    :
     |4.Authorization request                  |                    |
     |-------------------------------------------------------------&gt;|
     |                    |                    |  [Apply distribution
     |                    |                    |   policy]          |
     |                    |                    |                    |
     |                    |             (ALT: Authorization decision)
     |5.Request is denied |                    |      &lt;Negative&gt;    |
     |&lt;-------------------------------------------------------------|
     |                    |                    |                    |
     |6.Provides Signed URI                    |      &lt;Positive&gt;    |
     |&lt;-------------------------------------------------------------|
     |                    |                    |                    |
     |7.DNS request       |                    |                    |
     |----------------------------------------&gt;|                    |
     |                    |                    |                    |
     |8.Redirect DNS to dCDN                   |                    |
     |&lt;----------------------------------------|                    |
     |                    |                    |                    |
     |9.DNS request       |                    |                    |
     |-------------------&gt;|                    |                    |
     |                    |                    |                    |
     |10.IP address of Surrogate               |                    |
     |&lt;-------------------|                    |                    |
     |                    |                    |                    |
     |11.Content request  |                    |                    |
     |-------------------&gt;| [Verify URI        |                    |
     |                    |  signature]        |                    |
     |                    |                    |                    |
     |    (ALT: Verification result)           |                    |
     |12.Request is denied| &lt;Negative&gt;         |                    |
     |&lt;-------------------|                    |                    |
     |                    |                    |                    |
     |13.Content delivery | &lt;Positive&gt;         |                    |
     |&lt;-------------------|                    |                    |
     :                    :                    :                    :
     :   (Later in time)  :                    :                    :
     |14.CDNI Logging interface to report URI Signing information   |
     |                    |-------------------&gt;|                    |
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-dns-based-request-routing-w" class="selfRef">DNS-based Request Routing with URI Signing</a>
          </figcaption></figure>
</div>
<ol start="1" type="1" class="normal type-1" id="section-5.2-5">
   <li id="section-5.2-5.1">Using the CDNI Footprint &amp; Capabilities Advertisement
            interface, the dCDN advertises its capabilities
            including URI Signing support to the uCDN.<a href="#section-5.2-5.1" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-5.2">CSP provides to the uCDN the information needed to
            verify Signed JWTs from that CSP. For example, this
            information will include one or more keys used for validation.<a href="#section-5.2-5.2" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-5.3">Using the CDNI Metadata interface, the uCDN
            communicates to a dCDN the information needed to
            verify Signed JWTs from the CSP (e.g., the URI query
            string parameter name for the URI Signing Package Attribute). In
            the case of symmetric shared key, the uCDN <span class="bcp14">MUST NOT</span> share the key
            with a dCDN.<a href="#section-5.2-5.3" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-5.4">When a UA requests a piece of protected content from the CSP,
            the CSP makes a specific authorization decision for this unique
            request based on its local distribution policy.<a href="#section-5.2-5.4" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-5.5">If the authorization decision is negative, the CSP rejects the
            request and sends an error code (e.g., 403 Forbidden) in the HTTP
            response.<a href="#section-5.2-5.5" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-5.6">If the authorization decision is positive, the CSP computes a
            Signed JWT that is based on unique parameters of that
            request and includes it in the URI provided to the end user to
            request the content.<a href="#section-5.2-5.6" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-5.7">The end user sends a DNS request to the uCDN.<a href="#section-5.2-5.7" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-5.8">On receipt of the DNS request, the uCDN redirects
            the request to the dCDN.<a href="#section-5.2-5.8" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-5.9">The end user sends a DNS request to the dCDN.<a href="#section-5.2-5.9" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-5.10">On receipt of the DNS request, the dCDN responds with
            IP address of one of its Surrogates.<a href="#section-5.2-5.10" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-5.11">On receipt of the corresponding content request, the
            dCDN verifies the Signed JWT in the URI using the
            information provided by the uCDN in the CDNI
            Metadata.<a href="#section-5.2-5.11" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-5.12">If the verification result is negative, the dCDN rejects the
            request and sends an error code 403 Forbidden in the HTTP
            response.<a href="#section-5.2-5.12" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-5.13">If the verification result is positive, the dCDN serves the
            request and delivers the content.<a href="#section-5.2-5.13" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-5.14">At a later time, dCDN reports logging events that
            includes URI Signing information.<a href="#section-5.2-5.14" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-5.2-6">With DNS-based request routing, URI Signing matches well the
        general chain of trust model of CDNI when used with asymmetric keys
        because the only key information that needs to be distributed across
        multiple, possibly untrusted, CDNI hops is the public key, which
        is generally not confidential.<a href="#section-5.2-6" class="pilcrow">¶</a></p>
<p id="section-5.2-7">With DNS-based request routing, URI Signing does not match well with the
        general chain of trust model of CDNI when used with symmetric keys
        because the symmetric key information needs to be distributed across
        multiple CDNI hops to CDNs with which the CSP may not have a trust
        relationship. This raises a security concern for applicability of URI
        Signing with symmetric keys in case of DNS-based inter-CDN request
        routing. Due to these flaws, this architecture <span class="bcp14">MUST NOT</span> be implemented.<a href="#section-5.2-7" class="pilcrow">¶</a></p>
<p id="section-5.2-8">Note: While using a symmetric shared key is supported, it is <span class="bcp14">NOT RECOMMENDED</span>.
        See the <span><a href="#security" class="xref">Security Considerations</a> (<a href="#security" class="xref">Section 7</a>)</span> about the
        limitations of shared keys.<a href="#section-5.2-8" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec.IANA">
<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="sec.IANA.payload">
<section id="section-6.1">
        <h3 id="name-cdni-payload-type">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-cdni-payload-type" class="section-name selfRef">CDNI Payload Type</a>
        </h3>
<p id="section-6.1-1">IANA has registered the following CDNI
        Payload Type under the IANA "CDNI Payload Types" registry:<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<table class="center" id="table-1">
          <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Payload Type</th>
              <th class="text-left" rowspan="1" colspan="1">Specification</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">MI.UriSigning</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
            </tr>
          </tbody>
        </table>
<div id="sec.IANA.payload.UriSigning">
<section id="section-6.1.1">
          <h4 id="name-cdni-urisigning-payload-typ">
<a href="#section-6.1.1" class="section-number selfRef">6.1.1. </a><a href="#name-cdni-urisigning-payload-typ" class="section-name selfRef">CDNI UriSigning Payload Type</a>
          </h4>
<span class="break"></span><dl class="dlParallel" id="section-6.1.1-1">
            <dt id="section-6.1.1-1.1">Purpose:
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.1.1-1.2">The purpose of this payload type is to distinguish                      
          UriSigning Metadata interface (MI) objects (and any associated capability advertisement).<a href="#section-6.1.1-1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.1.1-1.3">Interface: 
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.1.1-1.4">MI/FCI<a href="#section-6.1.1-1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.1.1-1.5">Encoding:
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.1.1-1.6">see <a href="#metadata" class="xref">Section 4.4</a><a href="#section-6.1.1-1.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="sec.IANA.logging_record">
<section id="section-6.2">
        <h3 id="name-cdni-logging-record-type">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-cdni-logging-record-type" class="section-name selfRef">CDNI Logging Record Type</a>
        </h3>
<p id="section-6.2-1">IANA has registered the following CDNI
        Logging record-type under the IANA "CDNI Logging record-types" registry:<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<table class="center" id="table-2">
          <caption><a href="#table-2" class="selfRef">Table 2</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">record-types</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">cdni_http_request_v2</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Extension to CDNI Logging Record version 1 for content
          delivery using HTTP, to include URI Signing Logging fields</td>
            </tr>
          </tbody>
        </table>
<div id="sec.IANA.record_type.cdni_http_request_v2">
<section id="section-6.2.1">
          <h4 id="name-cdni-logging-record-version">
<a href="#section-6.2.1" class="section-number selfRef">6.2.1. </a><a href="#name-cdni-logging-record-version" class="section-name selfRef">CDNI Logging Record Version 2 for HTTP</a>
          </h4>
<p id="section-6.2.1-1">The "cdni_http_request_v2" record-type supports all of
          the fields supported by the "cdni_http_request_v1"
          record-type <span>[<a href="#RFC7937" class="xref">RFC7937</a>]</span> plus the
          two additional fields "s-uri-signing" and
          "s-uri-signing-deny-reason", registered by this document in
          <a href="#sec.IANA.fields" class="xref">Section 6.3</a>.  The name,
          format, field value, and occurrence information for the two
          new fields can be found in
          <a href="#logging" class="xref">Section 4.5</a> of this
          document.<a href="#section-6.2.1-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec.IANA.fields">
<section id="section-6.3">
        <h3 id="name-cdni-logging-field-names">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-cdni-logging-field-names" class="section-name selfRef">CDNI Logging Field Names</a>
        </h3>
<p id="section-6.3-1">IANA has registered the following CDNI
        Logging fields under the IANA "CDNI Logging Field Names" registry:<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<table class="center" id="table-3">
          <caption><a href="#table-3" class="selfRef">Table 3</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Field Name</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">s-uri-signing</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">s-uri-signing-deny-reason</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
            </tr>
          </tbody>
        </table>
</section>
</div>
<div id="sec.IANA.field.s-uri-signing.values">
<section id="section-6.4">
        <h3 id="name-cdni-uri-signing-verificati">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-cdni-uri-signing-verificati" class="section-name selfRef">CDNI URI Signing Verification Code</a>
        </h3>
<p id="section-6.4-1">IANA has created a new "CDNI URI Signing Verification Code" subregistry in the
        "Content Delivery Networks Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing Verification Code"
        namespace defines the valid values associated with the s-uri-signing CDNI Logging field. The CDNI URI Signing
        Verification Code is a 3DIGIT value as defined in <a href="#logging" class="xref">Section 4.5</a>. Additions to the CDNI URI Signing
        Verification Code namespace will conform to the "Specification Required" policy as defined in
        <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>. Updates to this subregistry are expected to be infrequent.<a href="#section-6.4-1" class="pilcrow">¶</a></p>
<table class="center" id="table-4">
          <caption><a href="#table-4" class="selfRef">Table 4</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Value</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">000</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">No signed JWT verification performed</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">200</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Signed JWT verification performed and verified</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">400</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Signed JWT verification performed and rejected because of incorrect signature</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">401</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Signed JWT verification performed and rejected because of Issuer enforcement</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">402</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Signed JWT verification performed and rejected because of Subject enforcement</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">403</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Signed JWT verification performed and rejected because of Audience enforcement</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">404</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Signed JWT verification performed and rejected because of Expiration Time enforcement</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">405</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Signed JWT verification performed and rejected because of Not Before enforcement</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">406</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Signed JWT verification performed and rejected because only one of CDNI Signed Token Transport or CDNI Expiration Time Setting present</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">407</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Signed JWT verification performed and rejected because of JWT ID enforcement</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">408</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Signed JWT verification performed and rejected because of Version enforcement</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">409</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Signed JWT verification performed and rejected because of Critical Extension enforcement</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">410</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Signed JWT verification performed and rejected because of Client IP enforcement</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">411</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Signed JWT verification performed and rejected because of URI Container enforcement</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">500</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
              <td class="text-left" rowspan="1" colspan="1">Unable to perform signed JWT verification because of malformed URI</td>
            </tr>
          </tbody>
        </table>
</section>
</div>
<div id="sec.IANA.cdnistt">
<section id="section-6.5">
        <h3 id="name-cdni-uri-signing-signed-tok">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-cdni-uri-signing-signed-tok" class="section-name selfRef">CDNI URI Signing Signed Token Transport</a>
        </h3>
<p id="section-6.5-1">IANA has created a new "CDNI URI Signing
        Signed Token Transport" subregistry in the "Content
        Delivery Networks Interconnection (CDNI) Parameters" registry.
        The "CDNI URI Signing Signed Token Transport"
        namespace defines the valid values
        that may be in the Signed Token Transport (cdnistt) JWT claim.
        Additions to the Signed Token Transport namespace conform to the
        "Specification Required" policy as defined in <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.
        Updates to this subregistry are expected to be infrequent.<a href="#section-6.5-1" class="pilcrow">¶</a></p>
<p id="section-6.5-2">The following table defines the initial Enforcement
        Information Elements:<a href="#section-6.5-2" class="pilcrow">¶</a></p>
<table class="center" id="table-5">
          <caption><a href="#table-5" class="selfRef">Table 5</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Value</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
              <th class="text-left" rowspan="1" colspan="1">RFC</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">Designates token transport is not enabled</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">Designates token transport via cookie</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">Designates token transport via query string</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9246</td>
            </tr>
          </tbody>
        </table>
</section>
</div>
<div id="ClaimsReg">
<section id="section-6.6">
        <h3 id="name-json-web-token-claims-regis">
<a href="#section-6.6" class="section-number selfRef">6.6. </a><a href="#name-json-web-token-claims-regis" class="section-name selfRef">JSON Web Token Claims Registration</a>
        </h3>
<p id="section-6.6-1">
          This specification registers the following claims
          in the IANA "JSON Web Token Claims" registry  <span>[<a href="#IANA.JWT.Claims" class="xref">IANA.JWT.Claims</a>]</span> established by <span>[<a href="#RFC7519" class="xref">RFC7519</a>]</span>.<a href="#section-6.6-1" class="pilcrow">¶</a></p>
<div id="ClaimsContents">
<section id="section-6.6.1">
          <h4 id="name-registry-contents">
<a href="#section-6.6.1" class="section-number selfRef">6.6.1. </a><a href="#name-registry-contents" class="section-name selfRef">Registry Contents</a>
          </h4>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-6.6.1-1">
            <dt id="section-6.6.1-1.1">Claim Name:
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-1.2">
              <code>cdniv</code><a href="#section-6.6.1-1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-1.3">Claim Description:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-1.4">CDNI Claim Set Version<a href="#section-6.6.1-1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-1.5">Change Controller:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-1.6">IESG<a href="#section-6.6.1-1.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-1.7">Specification Document(s):
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-1.8">
              <a href="#cdniv_claim" class="xref">Section 2.1.8</a> of   
RFC 9246<a href="#section-6.6.1-1.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-6.6.1-2">
            <dt id="section-6.6.1-2.1">Claim Name:
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-2.2">
              <code>cdnicrit</code><a href="#section-6.6.1-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-2.3">Claim Description:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-2.4">CDNI Critical Claims Set<a href="#section-6.6.1-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-2.5">Change Controller: 
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-2.6">IESG<a href="#section-6.6.1-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-2.7">Specification Document(s):
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-2.8">
              <a href="#cdnicrit_claim" class="xref">Section 2.1.9</a>   
of RFC 9246<a href="#section-6.6.1-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-6.6.1-3">
            <dt id="section-6.6.1-3.1">Claim Name:
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-3.2">
              <code>cdniip</code><a href="#section-6.6.1-3.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-3.3">Claim Description:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-3.4">CDNI IP Address<a href="#section-6.6.1-3.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-3.5">Change Controller:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-3.6">IESG<a href="#section-6.6.1-3.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-3.7">Specification Document(s):
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-3.8">
              <a href="#cdniip_claim" class="xref">Section 2.1.10</a> of 
RFC 9246<a href="#section-6.6.1-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-6.6.1-4">
            <dt id="section-6.6.1-4.1">Claim Name: 
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-4.2">
              <code>cdniuc</code><a href="#section-6.6.1-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-4.3">Claim Description:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-4.4">CDNI URI Container<a href="#section-6.6.1-4.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-4.5">Change Controller:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-4.6">IESG<a href="#section-6.6.1-4.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-4.7">Specification Document(s):
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-4.8">
              <a href="#cdniuc_claim" class="xref">Section 2.1.11</a> of 
RFC 9246<a href="#section-6.6.1-4.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-6.6.1-5">
            <dt id="section-6.6.1-5.1">Claim Name:
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-5.2">
              <code>cdniets</code><a href="#section-6.6.1-5.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-5.3">Claim Description:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-5.4">CDNI Expiration Time Setting for Signed Token Renewal<a href="#section-6.6.1-5.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-5.5">Change Controller:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-5.6">IESG<a href="#section-6.6.1-5.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-5.7">Specification Document(s):
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-5.8">
              <a href="#cdniets_claim" class="xref">Section 2.1.12</a>    
of RFC 9246<a href="#section-6.6.1-5.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-6.6.1-6">
            <dt id="section-6.6.1-6.1">Claim Name:
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-6.2">
              <code>cdnistt</code><a href="#section-6.6.1-6.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-6.3">Claim Description:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-6.4">CDNI Signed Token Transport Method for Signed Token        
Renewal<a href="#section-6.6.1-6.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-6.5">Change Controller:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-6.6">IESG<a href="#section-6.6.1-6.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-6.7">Specification Document(s):
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-6.8">
              <a href="#cdnistt_claim" class="xref">Section 2.1.13</a>    
of RFC 9246<a href="#section-6.6.1-6.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-6.6.1-7">
            <dt id="section-6.6.1-7.1">Claim Name:
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-7.2">
              <code>cdnistd</code><a href="#section-6.6.1-7.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-7.3">Claim Description:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-7.4">CDNI Signed Token Depth<a href="#section-6.6.1-7.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-7.5">Change Controller:
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-7.6">IESG<a href="#section-6.6.1-7.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.6.1-7.7">Specification Document(s):
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.6.1-7.8">
              <a href="#cdnistd_claim" class="xref">Section 2.1.14</a>    
of RFC 9246<a href="#section-6.6.1-7.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="expertreview">
<section id="section-6.7">
        <h3 id="name-expert-review-guidance">
<a href="#section-6.7" class="section-number selfRef">6.7. </a><a href="#name-expert-review-guidance" class="section-name selfRef">Expert Review Guidance</a>
        </h3>
<p id="section-6.7-1">Generally speaking, we should determine the registration has a rational justification
         and does not duplicate a previous registration. Early assignment should be permissible as long
         as there is a reasonable expectation that the specification will become formalized. Expert
         Reviewers should be empowered to make determinations, but generally speaking they should allow
         new claims that do not otherwise introduce conflicts with implementation or things that may lead
         to confusion.  They should also follow the guidelines of <span><a href="https://www.rfc-editor.org/rfc/rfc8126#section-5" class="relref">Section 5</a> of [<a href="#RFC8126" class="xref">RFC8126</a>]</span> when sensible.<a href="#section-6.7-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="security">
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-7-1">This document describes the concept of URI Signing and how it can be
      used to provide access authorization in the case of
      CDNI. The primary goal of URI Signing is to make sure that only
      authorized UAs are able to access the content, with a
      CSP being able to authorize every individual request. It
      should be noted that URI Signing is not a content protection scheme; if
      a CSP wants to protect the content itself, other mechanisms, such as
      DRM, are more appropriate.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">CDNI URI Signing Signed Tokens leverage JSON Web Tokens and thus, guidelines in <span>[<a href="#RFC8725" class="xref">RFC8725</a>]</span>
      are applicable for all JWT interactions.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">In general, it holds that the level of protection against
      illegitimate access can be increased by including more claims
      in the signed JWT. The current version of this document
      includes claims for enforcing Issuer, Client IP Address, Not Before time, and Expiration Time;
      however, this list can be extended with other more complex attributes
      that are able to provide some form of protection against some of the
      vulnerabilities highlighted below.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">That said, there are a number of aspects that limit the level of
      security offered by URI Signing and that anybody implementing URI
      Signing should be aware of.<a href="#section-7-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7-5">
        <dt id="section-7-5.1">Replay attacks:
        </dt>
        <dd style="margin-left: 1.5em" id="section-7-5.2">A (valid) Signed URI may be used to perform replay attacks. The
   vulnerability to replay attacks can be reduced by picking a
   relatively short window between the Not Before time and Expiration
   Time attributes, although this is limited by the fact that any
   HTTP-based request needs a window of at least a couple of seconds to
   prevent sudden network issues from denying legitimate UAs access to
   the content. One may also reduce exposure to replay attacks by
   including a unique one-time access ID via the JWT ID attribute (jti
   claim). Whenever the dCDN receives a request with a given unique ID,
   it adds that ID to the list of 'used' IDs. In the case an
   illegitimate UA tries to use the same URI through a replay attack,
   the dCDN can deny the request based on the already used access
   ID. This list should be kept bounded. A reasonable approach would be
   to expire the entries based on the exp claim value. If no exp claim
   is present, then a simple Least Recently Used (LRU) cache could be
   used; however, this would allow values to eventually be reused.<a href="#section-7-5.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-7-5.3">Illegitimate clients behind a NAT:
        </dt>
        <dd style="margin-left: 1.5em" id="section-7-5.4">In cases where there are multiple users behind the same NAT, all
   users will have the same IP address from the point of view of the
   dCDN. This results in the dCDN not being able to distinguish between
   different users based on Client IP Address, which can lead to
   illegitimate users being able to access the content. One way to
   reduce exposure to this kind of attack is to not only check for
   Client IP but also for other attributes, e.g., attributes that can
   be found in HTTP headers.  However, this may be easily circumvented
   by a sophisticated attacker.<a href="#section-7-5.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-7-6">A shared key distributed between CSP and uCDN is more likely to be
      compromised. Since this key can be used
      to legitimately sign a URL for content access authorization, it is
      important to know the implications of a compromised shared key. While
      using a shared key scheme can be convenient, this architecture is <span class="bcp14">NOT RECOMMENDED</span> due to the risks associated. It is included for legacy
      feature parity and is highly discouraged in new implementations.<a href="#section-7-6" class="pilcrow">¶</a></p>
<p id="section-7-7">If a shared key usable for signing is compromised, an attacker
      can use it to perform a denial-of-service attack by forcing the CDN to
      evaluate prohibitively expensive regular expressions embedded in a
      URI Container (cdniuc) claim. As a result, compromised keys should be timely revoked
      in order to prevent exploitation.<a href="#section-7-7" class="pilcrow">¶</a></p>
<p id="section-7-8">The URI Container (cdniuc) claim can be given a wildcard value. This, combined
      with the fact that it is the only mandatory claim, means you can effectively make
      a skeleton key. Doing this does not sufficiently limit the scope of the JWT and is
      <span class="bcp14">NOT RECOMMENDED</span>. The only way to prevent such a key from being used after it is
      distributed is to revoke the signing key so it no longer validates.<a href="#section-7-8" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-8">
      <h2 id="name-privacy">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-privacy" class="section-name selfRef">Privacy</a>
      </h2>
<p id="section-8-1">The privacy protection concerns described in "<a href="#RFC7937" class="xref">Content Distribution Network Interconnection (CDNI) Logging Interface</a>" <span>[<a href="#RFC7937" class="xref">RFC7937</a>]</span> apply when
      the client's IP address (cdniip) or Subject (sub) is embedded in the Signed URI.
      For this reason, the mechanism described in <a href="#jwt_profile" class="xref">Section 2</a> encrypts the Client IP or Subject before
      including it in the URI Signing Package (and thus the URL itself).<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="POSIX.1">[POSIX.1]</dt>
        <dd>
<span class="refAuthor">The Open Group</span>, <span class="refTitle">"IEEE Standard for Information Technology -- Portable Operating System Interface (POSIX(TM)) Base Specifications, Issue 7"</span>, <span class="refContent">(Revision of IEEE Std 1003.1-2008)
          </span>, <span class="seriesInfo">IEEE Std 1003.1-2017</span>, <time datetime="2018-01" class="refDate">January 2018</time>, <span>&lt;<a href="https://pubs.opengroup.org/onlinepubs/9699919799/">https://pubs.opengroup.org/onlinepubs/9699919799/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0791">[RFC0791]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Internet Protocol"</span>, <span class="seriesInfo">STD 5</span>, <span class="seriesInfo">RFC 791</span>, <span class="seriesInfo">DOI 10.17487/RFC0791</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc791">https://www.rfc-editor.org/info/rfc791</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3986">[RFC3986]</dt>
        <dd>
<span class="refAuthor">Berners-Lee, T.</span>, <span class="refAuthor">Fielding, R.</span>, and <span class="refAuthor">L. Masinter</span>, <span class="refTitle">"Uniform Resource Identifier (URI): Generic Syntax"</span>, <span class="seriesInfo">STD 66</span>, <span class="seriesInfo">RFC 3986</span>, <span class="seriesInfo">DOI 10.17487/RFC3986</span>, <time datetime="2005-01" class="refDate">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3986">https://www.rfc-editor.org/info/rfc3986</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5905">[RFC5905]</dt>
        <dd>
<span class="refAuthor">Mills, D.</span>, <span class="refAuthor">Martin, J., Ed.</span>, <span class="refAuthor">Burbank, J.</span>, and <span class="refAuthor">W. Kasch</span>, <span class="refTitle">"Network Time Protocol Version 4: Protocol and Algorithms Specification"</span>, <span class="seriesInfo">RFC 5905</span>, <span class="seriesInfo">DOI 10.17487/RFC5905</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5905">https://www.rfc-editor.org/info/rfc5905</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5952">[RFC5952]</dt>
        <dd>
<span class="refAuthor">Kawamura, S.</span> and <span class="refAuthor">M. Kawashima</span>, <span class="refTitle">"A Recommendation for IPv6 Address Text Representation"</span>, <span class="seriesInfo">RFC 5952</span>, <span class="seriesInfo">DOI 10.17487/RFC5952</span>, <time datetime="2010-08" class="refDate">August 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5952">https://www.rfc-editor.org/info/rfc5952</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6265">[RFC6265]</dt>
        <dd>
<span class="refAuthor">Barth, A.</span>, <span class="refTitle">"HTTP State Management Mechanism"</span>, <span class="seriesInfo">RFC 6265</span>, <span class="seriesInfo">DOI 10.17487/RFC6265</span>, <time datetime="2011-04" class="refDate">April 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6265">https://www.rfc-editor.org/info/rfc6265</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6570">[RFC6570]</dt>
        <dd>
<span class="refAuthor">Gregorio, J.</span>, <span class="refAuthor">Fielding, R.</span>, <span class="refAuthor">Hadley, M.</span>, <span class="refAuthor">Nottingham, M.</span>, and <span class="refAuthor">D. Orchard</span>, <span class="refTitle">"URI Template"</span>, <span class="seriesInfo">RFC 6570</span>, <span class="seriesInfo">DOI 10.17487/RFC6570</span>, <time datetime="2012-03" class="refDate">March 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6570">https://www.rfc-editor.org/info/rfc6570</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6707">[RFC6707]</dt>
        <dd>
<span class="refAuthor">Niven-Jenkins, B.</span>, <span class="refAuthor">Le Faucheur, F.</span>, and <span class="refAuthor">N. Bitar</span>, <span class="refTitle">"Content Distribution Network Interconnection (CDNI) Problem Statement"</span>, <span class="seriesInfo">RFC 6707</span>, <span class="seriesInfo">DOI 10.17487/RFC6707</span>, <time datetime="2012-09" class="refDate">September 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6707">https://www.rfc-editor.org/info/rfc6707</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6920">[RFC6920]</dt>
        <dd>
<span class="refAuthor">Farrell, S.</span>, <span class="refAuthor">Kutscher, D.</span>, <span class="refAuthor">Dannewitz, C.</span>, <span class="refAuthor">Ohlman, B.</span>, <span class="refAuthor">Keranen, A.</span>, and <span class="refAuthor">P. Hallam-Baker</span>, <span class="refTitle">"Naming Things with Hashes"</span>, <span class="seriesInfo">RFC 6920</span>, <span class="seriesInfo">DOI 10.17487/RFC6920</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6920">https://www.rfc-editor.org/info/rfc6920</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7230">[RFC7230]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span> and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"</span>, <span class="seriesInfo">RFC 7230</span>, <span class="seriesInfo">DOI 10.17487/RFC7230</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7230">https://www.rfc-editor.org/info/rfc7230</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7516">[RFC7516]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span> and <span class="refAuthor">J. Hildebrand</span>, <span class="refTitle">"JSON Web Encryption (JWE)"</span>, <span class="seriesInfo">RFC 7516</span>, <span class="seriesInfo">DOI 10.17487/RFC7516</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7516">https://www.rfc-editor.org/info/rfc7516</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7519">[RFC7519]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">N. Sakimura</span>, <span class="refTitle">"JSON Web Token (JWT)"</span>, <span class="seriesInfo">RFC 7519</span>, <span class="seriesInfo">DOI 10.17487/RFC7519</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7519">https://www.rfc-editor.org/info/rfc7519</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7937">[RFC7937]</dt>
        <dd>
<span class="refAuthor">Le Faucheur, F., Ed.</span>, <span class="refAuthor">Bertrand, G., Ed.</span>, <span class="refAuthor">Oprescu, I., Ed.</span>, and <span class="refAuthor">R. Peterkofsky</span>, <span class="refTitle">"Content Distribution Network Interconnection (CDNI) Logging Interface"</span>, <span class="seriesInfo">RFC 7937</span>, <span class="seriesInfo">DOI 10.17487/RFC7937</span>, <time datetime="2016-08" class="refDate">August 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7937">https://www.rfc-editor.org/info/rfc7937</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8006">[RFC8006]</dt>
        <dd>
<span class="refAuthor">Niven-Jenkins, B.</span>, <span class="refAuthor">Murray, R.</span>, <span class="refAuthor">Caulfield, M.</span>, and <span class="refAuthor">K. Ma</span>, <span class="refTitle">"Content Delivery Network Interconnection (CDNI) Metadata"</span>, <span class="seriesInfo">RFC 8006</span>, <span class="seriesInfo">DOI 10.17487/RFC8006</span>, <time datetime="2016-12" class="refDate">December 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8006">https://www.rfc-editor.org/info/rfc8006</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8259">[RFC8259]</dt>
      <dd>
<span class="refAuthor">Bray, T., Ed.</span>, <span class="refTitle">"The JavaScript Object Notation (JSON) Data Interchange Format"</span>, <span class="seriesInfo">STD 90</span>, <span class="seriesInfo">RFC 8259</span>, <span class="seriesInfo">DOI 10.17487/RFC8259</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8259">https://www.rfc-editor.org/info/rfc8259</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="IANA.JWT.Claims">[IANA.JWT.Claims]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"JSON Web Token (JWT)"</span>, <span>&lt;<a href="https://www.iana.org/assignments/jwt">https://www.iana.org/assignments/jwt</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="MPEG-DASH">[MPEG-DASH]</dt>
        <dd>
<span class="refAuthor">ISO</span>, <span class="refTitle">"Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats"</span>, <span class="seriesInfo">ISO/IEC 23009-1:2019</span>, <span class="seriesInfo">Edition 4</span>, <time datetime="2019-12" class="refDate">December 2019</time>, <span>&lt;<a href="https://www.iso.org/standard/79329.html">https://www.iso.org/standard/79329.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6983">[RFC6983]</dt>
        <dd>
<span class="refAuthor">van Brandenburg, R.</span>, <span class="refAuthor">van Deventer, O.</span>, <span class="refAuthor">Le Faucheur, F.</span>, and <span class="refAuthor">K. Leung</span>, <span class="refTitle">"Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)"</span>, <span class="seriesInfo">RFC 6983</span>, <span class="seriesInfo">DOI 10.17487/RFC6983</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6983">https://www.rfc-editor.org/info/rfc6983</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7336">[RFC7336]</dt>
        <dd>
<span class="refAuthor">Peterson, L.</span>, <span class="refAuthor">Davie, B.</span>, and <span class="refAuthor">R. van Brandenburg, Ed.</span>, <span class="refTitle">"Framework for Content Distribution Network Interconnection (CDNI)"</span>, <span class="seriesInfo">RFC 7336</span>, <span class="seriesInfo">DOI 10.17487/RFC7336</span>, <time datetime="2014-08" class="refDate">August 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7336">https://www.rfc-editor.org/info/rfc7336</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7337">[RFC7337]</dt>
        <dd>
<span class="refAuthor">Leung, K., Ed.</span> and <span class="refAuthor">Y. Lee, Ed.</span>, <span class="refTitle">"Content Distribution Network Interconnection (CDNI) Requirements"</span>, <span class="seriesInfo">RFC 7337</span>, <span class="seriesInfo">DOI 10.17487/RFC7337</span>, <time datetime="2014-08" class="refDate">August 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7337">https://www.rfc-editor.org/info/rfc7337</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7517">[RFC7517]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refTitle">"JSON Web Key (JWK)"</span>, <span class="seriesInfo">RFC 7517</span>, <span class="seriesInfo">DOI 10.17487/RFC7517</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7517">https://www.rfc-editor.org/info/rfc7517</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7975">[RFC7975]</dt>
        <dd>
<span class="refAuthor">Niven-Jenkins, B., Ed.</span> and <span class="refAuthor">R. van Brandenburg, Ed.</span>, <span class="refTitle">"Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection"</span>, <span class="seriesInfo">RFC 7975</span>, <span class="seriesInfo">DOI 10.17487/RFC7975</span>, <time datetime="2016-10" class="refDate">October 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7975">https://www.rfc-editor.org/info/rfc7975</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8008">[RFC8008]</dt>
        <dd>
<span class="refAuthor">Seedorf, J.</span>, <span class="refAuthor">Peterson, J.</span>, <span class="refAuthor">Previdi, S.</span>, <span class="refAuthor">van Brandenburg, R.</span>, and <span class="refAuthor">K. Ma</span>, <span class="refTitle">"Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics"</span>, <span class="seriesInfo">RFC 8008</span>, <span class="seriesInfo">DOI 10.17487/RFC8008</span>, <time datetime="2016-12" class="refDate">December 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8008">https://www.rfc-editor.org/info/rfc8008</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8216">[RFC8216]</dt>
        <dd>
<span class="refAuthor">Pantos, R., Ed.</span> and <span class="refAuthor">W. May</span>, <span class="refTitle">"HTTP Live Streaming"</span>, <span class="seriesInfo">RFC 8216</span>, <span class="seriesInfo">DOI 10.17487/RFC8216</span>, <time datetime="2017-08" class="refDate">August 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8216">https://www.rfc-editor.org/info/rfc8216</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8725">[RFC8725]</dt>
      <dd>
<span class="refAuthor">Sheffer, Y.</span>, <span class="refAuthor">Hardt, D.</span>, and <span class="refAuthor">M. Jones</span>, <span class="refTitle">"JSON Web Token Best Current Practices"</span>, <span class="seriesInfo">BCP 225</span>, <span class="seriesInfo">RFC 8725</span>, <span class="seriesInfo">DOI 10.17487/RFC8725</span>, <time datetime="2020-02" class="refDate">February 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8725">https://www.rfc-editor.org/info/rfc8725</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="sup_example">
<section id="appendix-A">
      <h2 id="name-signed-uri-package-example">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-signed-uri-package-example" class="section-name selfRef">Signed URI Package Example</a>
      </h2>
<p id="appendix-A-1">This section contains three examples of token usage: a simple example with only the
      required claim present, a complex example that demonstrates the full JWT claims set,
      including an encrypted Client IP Address (cdniip), and one that uses a Signed Token Renewal.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">Note: All of the examples have empty space added to improve formatting and readability,
      but are not present in the generated content.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<p id="appendix-A-3">All examples use the following JWK Set <span>[<a href="#RFC7517" class="xref">RFC7517</a>]</span>:<a href="#appendix-A-3" class="pilcrow">¶</a></p>
<div id="appendix-A-4">
<pre class="lang-json sourcecode">
{ "keys": [
  {
    "kty": "EC",
    "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0",
    "use": "sig",
    "alg": "ES256",
    "crv": "P-256",
    "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8",
    "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA"
  },
  {
    "kty": "EC",
    "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0",
    "use": "sig",
    "alg": "ES256",
    "crv": "P-256",
    "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8",
    "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA",
    "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M"
  },
  {
    "kty": "oct",
    "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998",
    "use": "enc",
    "alg": "A128GCM",
    "k": "4uFxxV7fhNmrtiah2d1fFg"
  }
]}
</pre><a href="#appendix-A-4" class="pilcrow">¶</a>
</div>
<p id="appendix-A-5">Note: They are the public signing key, the private signing
     key, and the shared secret encryption key, respectively. The public and private signing
     keys have the same fingerprint and only vary by the 'd' parameter that is missing from the
     public signing key.<a href="#appendix-A-5" class="pilcrow">¶</a></p>
<div id="simple_example">
<section id="appendix-A.1">
        <h3 id="name-simple-example">
<a href="#appendix-A.1" class="section-number selfRef">A.1. </a><a href="#name-simple-example" class="section-name selfRef">Simple Example</a>
        </h3>
<p id="appendix-A.1-1">
          This example is a simple common usage example containing
          a minimal subset of claims that the authors find most useful.<a href="#appendix-A.1-1" class="pilcrow">¶</a></p>
<p id="appendix-A.1-2">
          The JWT Claim Set before signing:<a href="#appendix-A.1-2" class="pilcrow">¶</a></p>
<p id="appendix-A.1-3">
          Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the URL Segment form
          (<span><a href="https://www.rfc-editor.org/rfc/rfc6920#section-5" class="relref">Section 5</a> of [<a href="#RFC6920" class="xref">RFC6920</a>]</span>) of "http://cdni.example/foo/bar".<a href="#appendix-A.1-3" class="pilcrow">¶</a></p>
<div id="appendix-A.1-4">
<pre class="lang-json sourcecode">
{
  "exp": 1646867369,
  "iss": "uCDN Inc",
  "cdniuc":
    "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY"
}
</pre><a href="#appendix-A.1-4" class="pilcrow">¶</a>
</div>
<p id="appendix-A.1-5">
          The signed JWT:<a href="#appendix-A.1-5" class="pilcrow">¶</a></p>
<div id="appendix-A.1-6">
<pre class="sourcecode">
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE2NDY4NjczNjksImlzcyI6InVDRE4gS
W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV
wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.TaNlJM3D96i_9J9XvlICO6FUIDFTqt3E2Y
JkEUOLfcH0b89wYRKTbJ9Yj6h_GRgSoZoQO0cps3yUPcWGK3smCw
</pre><a href="#appendix-A.1-6" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="complex_example">
<section id="appendix-A.2">
        <h3 id="name-complex-example">
<a href="#appendix-A.2" class="section-number selfRef">A.2. </a><a href="#name-complex-example" class="section-name selfRef">Complex Example</a>
        </h3>
<p id="appendix-A.2-1">
          This example uses all fields except for those dealing
          with Signed Token Renewal, including Client IP Address (cdniip) and Subject (sub), which are
          encrypted. This significantly increases the size of the signed
          JWT token.<a href="#appendix-A.2-1" class="pilcrow">¶</a></p>
<p id="appendix-A.2-2">
          JWE for Client IP Address (cdniip) of [2001:db8::1/32]:<a href="#appendix-A.2-2" class="pilcrow">¶</a></p>
<div id="appendix-A.2-3">
<pre class="sourcecode">
eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST
NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..aUDDFEQBIc3nWjOb.bGXWT
HPkntmPCKn0pPPNEQ.iyTttnFybO2YBLqwl_YSjA
</pre><a href="#appendix-A.2-3" class="pilcrow">¶</a>
</div>
<p id="appendix-A.2-4">
          JWE for Subject (sub) of "UserToken":<a href="#appendix-A.2-4" class="pilcrow">¶</a></p>
<div id="appendix-A.2-5">
<pre class="sourcecode">
eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST
NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..CLAu80xclc8Bp-Ui.6P1A3
F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g
</pre><a href="#appendix-A.2-5" class="pilcrow">¶</a>
</div>
<p id="appendix-A.2-6">
          The JWT Claim Set before signing:<a href="#appendix-A.2-6" class="pilcrow">¶</a></p>
<div id="appendix-A.2-7">
<pre class="lang-json sourcecode">
{
  "aud": "dCDN LLC",
  "sub": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4
QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..CLAu80xclc8B
p-Ui.6P1A3F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g",
  "cdniip": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XY
mp4QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..aUDDFEQBI
c3nWjOb.bGXWTHPkntmPCKn0pPPNEQ.iyTttnFybO2YBLqwl_YSjA",
  "cdniv": 1,
  "exp": 1646867369,
  "iat": 1646694569,
  "iss": "uCDN Inc",
  "jti": "5DAafLhZAfhsbe",
  "nbf": 1646780969,
  "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png"
}
</pre><a href="#appendix-A.2-7" class="pilcrow">¶</a>
</div>
<p id="appendix-A.2-8">
          The signed JWT:<a href="#appendix-A.2-8" class="pilcrow">¶</a></p>
<div id="appendix-A.2-9">
<pre class="sourcecode">
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5Smxib
U1pT2lKQk1USTRSME5OSWl3aVlXeG5Jam9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA
0UWtNelpGQjFTVE5rTWpSclVESm9ablp2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T
0NKOS4uQ0xBdTgweGNsYzhCcC1VaS42UDFBM0Y2aXAyRHYuQ29oZHRMTHBnQm5UdlJ
KUUNGdXotZyIsImNkbmlpcCI6ImV5SmxibU1pT2lKQk1USTRSME5OSWl3aVlXeG5Ja
m9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA0UWtNelpGQjFTVE5rTWpSclVESm9ablp
2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T0NKOS4uYVVEREZFUUJJYzNuV2pPYi5iR
1hXVEhQa250bVBDS24wcFBQTkVRLml5VHR0bkZ5Yk8yWUJMcXdsX1lTakEiLCJjZG5
pdiI6MSwiZXhwIjoxNjQ2ODY3MzY5LCJpYXQiOjE2NDY2OTQ1NjksImlzcyI6InVDR
E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE2NDY3ODA5NjksImN
kbml1YyI6InJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL1swLTlde
zN9XFwucG5nIn0.IjmVX0uD5MYqArc-M08uEsEeoDQn8kuYXZ9HGHDmDDxsHikT0c8
jcX8xYD0z3LzQclMG65i1kT2sRbZ7isUw8w
</pre><a href="#appendix-A.2-9" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="token_renewal_example">
<section id="appendix-A.3">
        <h3 id="name-signed-token-renewal-exampl">
<a href="#appendix-A.3" class="section-number selfRef">A.3. </a><a href="#name-signed-token-renewal-exampl" class="section-name selfRef">Signed Token Renewal Example</a>
        </h3>
<p id="appendix-A.3-1">
          This example uses fields for Signed Token Renewal.<a href="#appendix-A.3-1" class="pilcrow">¶</a></p>
<p id="appendix-A.3-2">
          The JWT Claim Set before signing:<a href="#appendix-A.3-2" class="pilcrow">¶</a></p>
<div id="appendix-A.3-3">
<pre class="lang-json sourcecode">
{
  "cdniets": 30,
  "cdnistt": 1,
  "cdnistd": 2,
  "exp": 1646867369,
  "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts"
}
</pre><a href="#appendix-A.3-3" class="pilcrow">¶</a>
</div>
<p id="appendix-A.3-4">
          The signed JWT:<a href="#appendix-A.3-4" class="pilcrow">¶</a></p>
<div id="appendix-A.3-5">
<pre class="sourcecode">
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua
XN0ZCI6MiwiZXhwIjoxNjQ2ODY3MzY5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R
uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.tlPvoKw3BCClw4Lx9
PQu7MK6b2IN55ZoCPSaxovGK0zS53Wpb1MbJBow7G8LiGR39h6-2Iq7PWUSr3MdTIz
HYw
</pre><a href="#appendix-A.3-5" class="pilcrow">¶</a>
</div>
<p id="appendix-A.3-6">
          Once the server verifies the signed JWT it will return a
          new signed JWT with an updated Expiry Time (exp) as shown
          below. Note the Expiry Time is increased by the expiration
          time setting (cdniets) value.<a href="#appendix-A.3-6" class="pilcrow">¶</a></p>
<p id="appendix-A.3-7">
          The JWT Claim Set before signing:<a href="#appendix-A.3-7" class="pilcrow">¶</a></p>
<div id="appendix-A.3-8">
<pre class="lang-json sourcecode">
{
  "cdniets": 30,
  "cdnistt": 1,
  "cdnistd": 2,
  "exp": 1646867399,
  "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts"
}
</pre><a href="#appendix-A.3-8" class="pilcrow">¶</a>
</div>
<p id="appendix-A.3-9">
          The signed JWT:<a href="#appendix-A.3-9" class="pilcrow">¶</a></p>
<div id="appendix-A.3-10">
<pre class="sourcecode">
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua
XN0ZCI6MiwiZXhwIjoxNjQ2ODY3Mzk5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R
uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.ivY5d_fKGd-OHTpUs
8uJUrnHvt-rduzu5H4zM7167pUUAghub53FqDQ5G16jRYX2sY73mA_uLpYDdb-CPts
8FA
</pre><a href="#appendix-A.3-10" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
<section id="appendix-B">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-B-1">The authors would like to thank the following people for their
      contributions in reviewing this document and providing feedback: <span class="contact-name">Scott       Leibrand</span>, <span class="contact-name">Kevin Ma</span>, <span class="contact-name">Ben Niven-Jenkins</span>, <span class="contact-name">Thierry Magnien</span>, <span class="contact-name">Dan York</span>,
      <span class="contact-name">Bhaskar Bhupalam</span>, <span class="contact-name">Matt Caulfield</span>, <span class="contact-name">Samuel Rajakumar</span>, <span class="contact-name">Iuniana Oprescu</span>,
      <span class="contact-name">Leif Hedstrom</span>, <span class="contact-name">Gancho Tenev</span>, <span class="contact-name">Brian Campbell</span>, and <span class="contact-name">Chris Lemmons</span>.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
</section>
<section id="appendix-C">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<p id="appendix-C-1">In addition, the authors would also like to make special mentions for certain
      people who contributed significant sections to this document.<a href="#appendix-C-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C-2.1">
          <p id="appendix-C-2.1.1"><span class="contact-name">Matt Caulfield</span> provided content for <a href="#metadata" class="xref">Section 4.4</a>, "CDNI Metadata Interface".<a href="#appendix-C-2.1.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="appendix-C-2.2">
          <p id="appendix-C-2.2.1"><span class="contact-name">Emmanuel Thomas</span> provided content for HTTP Adaptive Streaming.<a href="#appendix-C-2.2.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="appendix-C-2.3">
          <p id="appendix-C-2.3.1"><span class="contact-name">Matt Miller</span> provided consultation on JWT usage as well as code to generate working JWT examples.<a href="#appendix-C-2.3.1" class="pilcrow">¶</a></p>
</li>
      </ul>
</section>
<div id="authors-addresses">
<section id="appendix-D">
      <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">Ray van Brandenburg</span></div>
<div dir="auto" class="left"><span class="org">Tiledmedia</span></div>
<div dir="auto" class="left"><span class="street-address">Anna van Buerenplein 1</span></div>
<div dir="auto" class="left">
<span class="postal-code">2595DA</span> <span class="locality">Den Haag</span>
</div>
<div dir="auto" class="left"><span class="country-name">Netherlands</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+31%2088%20866%207000" class="tel">+31 88 866 7000</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:ray@tiledmedia.com" class="email">ray@tiledmedia.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Kent Leung</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mail4kentl@gmail.com" class="email">mail4kentl@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Phil Sorber</span></div>
<div dir="auto" class="left"><span class="org">Apple, Inc.</span></div>
<div dir="auto" class="left"><span class="extended-address">Suite 410</span></div>
<div dir="auto" class="left"><span class="street-address">1800 Wazee Street</span></div>
<div dir="auto" class="left">
<span class="locality">Denver</span>, <span class="region">CO</span> <span class="postal-code">80202</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:sorber@apple.com" class="email">sorber@apple.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>