rfc9246xml2.original.xml   rfc9246.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc [
<?rfc toc="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocompact="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc tocdepth="4"?> <!ENTITY nbhy "&#8209;">
<?rfc tocindent="yes"?> <!ENTITY wj "&#8288;">
<?rfc symrefs="yes"?> ]>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<?rfc inline="yes"?> std" consensus="true" docName="draft-ietf-cdni-uri-signing-26" number="9246" ipr
<?rfc compact="yes"?> ="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth=
<?rfc subcompact="no"?> "4" symRefs="true" sortRefs="true" version="3">
<rfc category="std" docName="draft-ietf-cdni-uri-signing-26" ipr="trust200902">
<front> <front>
<title abbrev="CDNI URI Signing">URI Signing for Content Delivery Network In terconnection <title abbrev="CDNI URI Signing">URI Signing for Content Delivery Network In terconnection
(CDNI)</title> (CDNI)</title>
<seriesInfo name="RFC" value="9246"/>
<author fullname="Ray van Brandenburg" initials="R" <author fullname="Ray van Brandenburg" initials="R" surname="van Brandenburg
surname="van Brandenburg"> ">
<organization>Tiledmedia</organization> <organization>Tiledmedia</organization>
<address> <address>
<postal> <postal>
<street>Anna van Buerenplein 1</street> <street>Anna van Buerenplein 1</street>
<city>Den Haag</city> <city>Den Haag</city>
<region/> <region/>
<code>2595DA</code> <code>2595DA</code>
<country>Netherlands</country>
<country>The Netherlands</country>
</postal> </postal>
<phone>+31 88 866 7000</phone> <phone>+31 88 866 7000</phone>
<email>ray@tiledmedia.com</email> <email>ray@tiledmedia.com</email>
</address> </address>
</author> </author>
<author fullname="Kent Leung" initials="K" surname="Leung"> <author fullname="Kent Leung" initials="K" surname="Leung">
<address> <address>
<email>mail4kentl@gmail.com</email> <email>mail4kentl@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Phil Sorber" initials="P" surname="Sorber"> <author fullname="Phil Sorber" initials="P" surname="Sorber">
<organization>Apple, Inc.</organization> <organization>Apple, Inc.</organization>
<address> <address>
<postal> <postal>
<street>1800 Wazee Street</street> <street>1800 Wazee Street</street>
<extaddr>Suite 410</extaddr>
<street>Suite 410</street>
<city>Denver</city> <city>Denver</city>
<region>CO</region> <region>CO</region>
<code>80202</code> <code>80202</code>
<country>United States</country> <country>United States</country>
</postal> </postal>
<email>sorber@apple.com</email> <email>sorber@apple.com</email>
</address> </address>
</author> </author>
<date year="2022" month="June" />
<area>art</area>
<workgroup>cdni</workgroup>
<date/> <keyword>jwt, json, token, cdn, url, http, hls, dash</keyword>
<workgroup>CDNI</workgroup>
<abstract> <abstract>
<t>This document describes how the concept of URI Signing supports the <t>This document describes how the concept of URI Signing supports the
content access control requirements of Content Delivery Network Interconne ction (CDNI) and proposes a URI Signing content access control requirements of Content Delivery Network Interconne ction (CDNI) and proposes a URI Signing
method as a JSON Web Token (JWT) profile.</t> method as a JSON Web Token (JWT) profile.</t>
<t>The proposed URI Signing method specifies the information needed to <t>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 n eeded be included in the URI to transmit the signed JWT, as well as the claims n eeded
by the signed JWT to authorize a User Agent (UA). The by the signed JWT to authorize a User Agent (UA). The
mechanism described can be used both in CDNI and single Content Delivery N etwork (CDN) mechanism described can be used both in CDNI and single Content Delivery N etwork (CDN)
scenarios.</t> scenarios.</t>
</abstract> </abstract>
</front>
</front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>This document describes the concept of URI Signing and how it can be <t>This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of redirection between used to provide access authorization in the case of redirection between
cooperating CDNs and between a Content Service Provider (CSP) cooperating CDNs and between a Content Service Provider (CSP)
and a CDN. The primary goal of URI Signing is to make sure that only 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 authorized UAs are able to access the content, with a CSP
being able to authorize every individual request. It should be noted 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 that URI Signing is not a content protection scheme; if a CSP wants to
protect the content itself, other mechanisms, such as Digital Rights Manag ement (DRM), are more protect the content itself, other mechanisms, such as Digital Rights Manag ement (DRM), are more
appropriate. In addition to access control, URI Signing also has appropriate. In addition to access control, URI Signing also has
benefits in reducing the impact of denial-of-service attacks.</t> benefits in reducing the impact of denial-of-service attacks.</t>
skipping to change at line 98 skipping to change at line 79
<t>This document describes the concept of URI Signing and how it can be <t>This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of redirection between used to provide access authorization in the case of redirection between
cooperating CDNs and between a Content Service Provider (CSP) cooperating CDNs and between a Content Service Provider (CSP)
and a CDN. The primary goal of URI Signing is to make sure that only 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 authorized UAs are able to access the content, with a CSP
being able to authorize every individual request. It should be noted 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 that URI Signing is not a content protection scheme; if a CSP wants to
protect the content itself, other mechanisms, such as Digital Rights Manag ement (DRM), are more protect the content itself, other mechanisms, such as Digital Rights Manag ement (DRM), are more
appropriate. In addition to access control, URI Signing also has appropriate. In addition to access control, URI Signing also has
benefits in reducing the impact of denial-of-service attacks.</t> benefits in reducing the impact of denial-of-service attacks.</t>
<t>The overall problem space for CDN Interconnection (CDNI) is described <t>The overall problem space for CDN Interconnection (CDNI) is described
in <xref target="RFC6707">CDNI Problem Statement</xref>. This in the CDNI Problem Statement <xref target="RFC6707" format="default"/>
document, along with the <xref target="RFC7337">CDNI Requirements</xref> specification. This document, along with the <xref target="RFC7337"
document and the <xref target="RFC7336">CDNI Framework</xref>, describes t format="default">Content Distribution Network Interconnection (CDNI) Requi
he need rements</xref> document and the <xref
for interconnected CDNs to be able to implement an access control target="RFC7336" format="default">Framework for Content Distribution Netwo
rk Interconnection (CDNI)</xref>, describes the
need for interconnected CDNs to be able to implement an access control
mechanism that enforces a CSP's distribution policies.</t> mechanism that enforces a CSP's distribution policies.</t>
<t>Specifically, the <xref target="RFC7336" format="default">CDNI Framewor
<t>Specifically, the <xref target="RFC7336">CDNI Framework</xref> k</xref>
states:</t> states:</t>
<ul empty="true" spacing="normal">
<t><list style="empty"> <li>The CSP may also trust the CDN operator to perform actions such as
<t>The CSP may also trust the CDN operator to perform actions such as
delegating traffic to additional downstream CDNs, and to enforce per-req uest authorization performed by the CSP using delegating traffic to additional downstream CDNs, and to enforce per-req uest authorization performed by the CSP using
techniques such as URI Signing.</t> techniques such as URI Signing.</li>
</list></t> </ul>
<t>In particular, the following requirement is listed in the <xref target=
<t>In particular, the following requirement is listed in the <xref "RFC7337" format="default">CDNI Requirements</xref>:</t>
target="RFC7337">CDNI Requirements</xref>:</t> <ul empty="true" spacing="normal">
<li>
<t><list style="empty"> <blockquote><dl><dt>MI-16</dt><dd>{HIGH} The CDNI Metadata interface sh
<t>MI-16 {HIGH} The CDNI Metadata interface shall allow signaling of all allow signaling of
authorization checks and verification that are to be performed by the authorization checks and validation that are to be performed
Surrogate before delivery. For example, this could potentially by the Surrogate before delivery. For example, this could
include the need to verify information (e.g., Expiry time, Client potentially include the need to validate information (e.g.,
IP address) required for access authorization.</t> Expiry time, Client IP address) required for access
</list></t> authorization.</dd>
</dl>
</blockquote>
</li>
</ul>
<t>This document defines a method of signing URIs that allows Surrogates i n <t>This document defines a method of signing URIs that allows Surrogates i n
interconnected CDNs to enforce a per-request authorization initiated by interconnected CDNs to enforce a per-request authorization initiated by
the CSP. Splitting the role of initiating per-request authorization 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 the CSP and the role of verifying this authorization by the CDN allows
any arbitrary distribution policy to be enforced across CDNs without the any arbitrary distribution policy to be enforced across CDNs without the
need of CDNs to have any awareness of the specific CSP distribution need of CDNs to have any awareness of the specific CSP distribution
policies.</t> policies.</t>
<t>The method is implemented using signed JSON Web Tokens (JWTs) <xref tar
get="RFC7519" format="default"/>.</t>
<section numbered="true" toc="default">
<name>Terminology</name>
<t>The method is implemented using Signed JSON Web Tokens (JWTs) <xref tar <t>
get="RFC7519"/>.</t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<section title="Terminology"> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
"MAY", and "OPTIONAL" in this document are to be interpreted as be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
</t>
<t>This document uses the terminology defined in the <xref
target="RFC6707">CDNI Problem Statement</xref>.</t>
<t>This document also uses the terminology of the <xref
target="RFC7519">JSON Web Token (JWT)</xref>.</t>
<t>This document uses the terminology defined in the <xref target="RFC67
07" format="default">CDNI Problem Statement</xref>.</t>
<t>This document also uses the terminology of the <xref target="RFC7519"
format="default">JSON Web Token (JWT)</xref>.</t>
<t>In addition, the following terms are used throughout this <t>In addition, the following terms are used throughout this
document:</t> document:</t>
<t><list style="symbols"> <dl>
<t>Signed URI: A URI for which a signed JWT is provided.</t>
<t>Target CDN URI: URI created by the CSP to direct a UA <dt>FCI:
towards the Upstream CDN (uCDN). The Target CDN URI can be signed by </dt>
the <dd>Footprint &amp; Capabilities Advertisement interface
CSP and verified by the uCDN and possibly further Downstream CDNs (d </dd>
CDNs).</t> <dt>Signed URI:
</dt>
<dd>A URI for which a signed JWT is provided.
</dd>
<t>Redirection URI: URI created by the uCDN to redirect a UA <dt>Target CDN URI:
towards the dCDN. The Redirection URI can be signed by </dt>
the uCDN and verified by the dCDN. In a cascaded <dd>A URI created by the CSP to direct a UA towards the upstream CDN (u
CDNI scenario, there can be more than one Redirection URI.</t> CDN). The Target CDN URI can be signed by the CSP and verified by the uCDN and p
ossibly further downstream CDNs (dCDNs).
</dd>
<t>Signed Token Renewal: A series of signed JWTs that are used for s <dt>Redirection URI:
ubsequent </dt>
access to a set of related resources in a CDN, such as a set of HTTP <dd>A URI created by the uCDN to redirect a UA towards the dCDN. The Re
Adaptive Streaming files. Every time a signed JWT is used to direction URI can be signed by the uCDN and verified by the dCDN. In a cascaded
access a particular resource, a new signed JWT is sent along CDNI scenario, there can be more than one Redirection URI.
with the resource that can be used to request the next resource </dd>
in the set. When generating a new signed JWT in Signed Token Renewal
,
parameters are carried over from one signed JWT to the next.</t>
</list></t>
</section>
<section anchor="background" <dt>Signed Token Renewal:
title="Background and overview on URI Signing "> </dt>
<dd>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.
</dd>
</dl>
</section>
<section anchor="background" numbered="true" toc="default">
<name>Background and Overview on URI Signing</name>
<t>A CSP and CDN are assumed to have a trust relationship that enables <t>A CSP and CDN are assumed to have a trust relationship that enables
the CSP to authorize access to a content item, which is the CSP to authorize access to a content item, which is
realized in practice by including a set of claims in a signed JWT 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 in the URI before redirecting a UA to the CDN. Using these
attributes, it is possible for a CDN to check an incoming content 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 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 alter a time window or pattern matching the URI). To prevent the UA from alter
ing the claims ing the claims,
the JWT MUST be signed.</t> the JWT <bcp14>MUST</bcp14> be signed.</t>
<t><xref target="fig_single_cdn" format="default"/> presents an overview
<t><xref target="fig_single_cdn"/>, shown below, presents an overview of of the URI Signing
the URI Signing
mechanism in the case of a CSP with a single CDN. When the UA browses 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 for content on CSP's website (1), it receives HTML web pages with
embedded content URIs. Upon requesting these URIs, the CSP redirects embedded content URIs. Upon requesting these URIs, the CSP redirects
to a CDN, creating a Target CDN URI (#2) (alternatively, the Target 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 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 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 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 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 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 Signed URI to the CDN (3). Upon receiving the request, the CDN
authenticates the Signed URI by verifying the signed JWT. authenticates the Signed URI by verifying the signed JWT.
If applicable, the CDN checks whether the time window is still valid 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. in the Signed URI and the pattern matches the URI of the request.
After these claims are verified, the CDN delivers the content (#4).</t> After these claims are verified, the CDN delivers the content (4).</t>
<t>Note: While using a symmetric shared key is supported, it is <bcp14>N
<t>Note: While using a symmetric shared key is supported, it is NOT RECO OT RECOMMENDED</bcp14>.
MMENDED. See the <xref target="security" format="default">Security Considerations
See the <xref target="security">Security Considerations</xref> section a </xref> about the
bout the
limitations of shared keys.</t> limitations of shared keys.</t>
<figure anchor="fig_single_cdn">
<figure anchor="fig_single_cdn" <name>URI Signing in a CDN Environment</name>
title="URI Signing in a CDN Environment"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
-------- --------
/ \ / \
| CSP |&lt; * * * * * * * * * * * | CSP |< * * * * * * * * * * *
\ / Trust * \ / Trust *
-------- relationship * -------- relationship *
^ | * ^ | *
| | * | | *
1. Browse | | 2. Signed * 1. Browse | | 2. Signed *
for | | URI * for | | URI *
content | | * content | | *
| v v | v v
+------+ 3. Signed URI -------- +------+ 3. Signed URI --------
| User |-----------------&gt;/ \ | User |----------------->/ \
| Agent| | CDN | | Agent| | CDN |
| |&lt;-----------------\ / | |<-----------------\ /
+------+ 4. Content -------- +------+ 4. Content --------
Delivery Delivery
</artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section numbered="true" toc="default">
<section title="CDNI URI Signing Overview"> <name>CDNI URI Signing Overview</name>
<t>In a CDNI environment, as shown in <xref target="fig_cdni_env"/> belo <t>In a CDNI environment, as shown in <xref target="fig_cdni_env" format
w, URI Signing operates the same way in the ="default"/> below, URI Signing operates the same way in the
initial steps #1 and #2, but the later steps involve multiple CDNs initial steps 1 and 2, but the later steps involve multiple CDNs
delivering the content. The main difference from the delivering the content. The main difference from the
single CDN case is a redirection step between the uCDN and 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, 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. depending on whether HTTP-based or DNS-based request routing is used.
The uCDN responds by directing the UA towards the The uCDN responds by directing the UA towards the
dCDN using either a Redirection URI (i.e., a Signed URI generated by dCDN using either a Redirection URI (i.e., a Signed URI generated by
the uCDN) or a DNS reply, respectively (#4). Once the UA the uCDN) or a DNS reply, respectively (4). Once the UA
receives the response, it sends the Redirection URI/Target CDN URI to receives the response, it sends the Redirection URI/Target CDN URI to
the dCDN (#5). The received URI is verified by the the dCDN (5). The received URI is verified by the
dCDN before delivering the content (#6). Note: The CDNI call flows are c dCDN before delivering the content (6).</t>
overed in <xref
target="operation">Detailed URI Signing Operation</xref>.</t>
<figure anchor="fig_cdni_env" title="URI Signing in a CDNI Environment"> <t>Note: The CDNI call flows are covered in <xref target="operation" form
<artwork> at="default">URI Signing Message Flow</xref>.</t>
<figure anchor="fig_cdni_env">
<name>URI Signing in a CDNI Environment</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-------------------------+ +-------------------------+
|Request Redirection Modes| |Request Redirection Modes|
+-------------------------+ +-------------------------+
| a) HTTP | | a) HTTP |
| b) DNS | | b) DNS |
+-------------------------+ +-------------------------+
-------- --------
/ \&lt; * * * * * * * * * * * * * * / \< * * * * * * * * * * * * * *
| CSP |&lt; * * * * * * * * * * * * | CSP |< * * * * * * * * * * * *
\ / Trust * * \ / Trust * *
-------- relationship * * -------- relationship * *
^ | * * ^ | * *
| | 2. Signed * * | | 2. Signed * *
1. Browse | | URI in * * 1. Browse | | URI in * *
for | | HTML * * for | | HTML * *
content | | * * content | | * *
| v 3.a)Signed URI v * | v 3.a)Signed URI v *
+------+ b)DNS request -------- * Trust +------+ b)DNS request -------- * Trust
| User |-----------------&gt;/ \ * relationship | User |----------------->/ \ * relationship
| Agent| | uCDN | * (optional) | Agent| | uCDN | * (optional)
| |&lt;-----------------\ / * | |<-----------------\ / *
+------+ 4.a)Redirection URI------- * +------+ 4.a)Redirection URI------- *
^ | b)DNS Reply ^ * ^ | b)DNS Reply ^ *
| | * * | | * *
| | Trust relationship * * | | Trust relationship * *
| | * * | | * *
6. Content | | 5.a)Redirection URI * * 6. Content | | 5.a)Redirection URI * *
delivery | | b)Signed URI(after v v delivery | | b)Signed URI(after v v
| | DNS exchange) -------- | | DNS exchange) --------
| +----------------------&gt;/ \ [May be | +---------------------->/ \ [May be
| | dCDN | cascaded | | dCDN | cascaded
+--------------------------\ / CDNs] +--------------------------\ / CDNs]
-------- --------
</artwork> ]]></artwork>
</figure> </figure>
<t>The trust relationships between CSP, uCDN, and <t>The trust relationships between CSP, uCDN, and
dCDN have direct implications for URI Signing. In the case shown in dCDN have direct implications for URI Signing. In the case shown in
<xref target="fig_cdni_env"/>, the CSP has a trust relationship with the <xref target="fig_cdni_env" format="default"/>, the CSP has a trust rela tionship with the
uCDN. The delivery of the content may be delegated to a uCDN. The delivery of the content may be delegated to a
dCDN, which has a relationship with the uCDN but may dCDN, which has a relationship with the uCDN but may
have no relationship with the CSP.</t> have no relationship with the CSP.</t>
<t>In CDNI, there are two methods for request routing: DNS-based and <t>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 Tar get HTTP-based. For DNS-based request routing, the Signed URI (i.e., the Tar get
CDN URI) provided by the CSP reaches the CDN directly. In CDN URI) provided by the CSP reaches the CDN directly. In
the case where the dCDN does not have a trust relationship the case where the dCDN does not have a trust relationship
with the CSP, this means that either an asymmetric public/private key 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 an d method needs to be used for computing the signed JWT (because the CSP an d
dCDN are not able to exchange symmetric shared secret keys). Shared keys MUST NOT dCDN are not able to exchange symmetric shared secret keys). Shared keys <bcp14>MUST NOT</bcp14>
be redistributed.</t> be redistributed.</t>
<t>For HTTP-based request routing, the Signed URI (i.e., the Target CDN <t>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 URI) provided by the CSP reaches the uCDN. After this URI has
been verified by the uCDN, the uCDN been verified by the uCDN, the uCDN
creates and signs a new Redirection URI, redirecting the UA to the 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 bet ween the dCDN. Since this new URI can have a new signed JWT, the relationship bet ween the
dCDN and CSP is not relevant. Because a dCDN and CSP is not relevant. Because a
relationship between uCDN and dCDN always exists, relationship between uCDN and dCDN always exists,
either asymmetric public/private keys or symmetric shared secret keys either asymmetric public/private keys or symmetric shared secret keys
can be used for URI Signing with HTTP-based request routing. Note that t can be used for URI Signing with HTTP-based request routing. Note that t
he signed Redirection URI MUST he signed Redirection URI <bcp14>MUST</bcp14>
maintain HTTPS as the scheme if it was present in the original and it MA maintain HTTPS as the scheme if it was present in the original, and it <
Y be upgraded from http: to https:.</t> bcp14>MAY</bcp14> be upgraded from "http:" to "https:".</t>
<t>Two types of keys can be used for URI Signing: asymmetric keys and <t>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 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 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 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 verification of the Signed URI. With symmetric keys, the same key is
used by both the signing entity for signing the URI and the used by both the signing entity for signing the URI and the
verifying entity for verifying the Signed URI. Regardless of the type 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 tha t allows trust to of keys used, the verifying entity has to obtain the key in a manner tha t allows trust to
be placed in the assertions made using that key (either the be placed in the assertions made using that key (either the
public or the symmetric key). There are very different requirements public or the symmetric key). There are very different requirements
(outside the scope of this document) for distributing asymmetric keys (outside the scope of this document) for distributing asymmetric keys
and symmetric keys. Key distribution for symmetric keys requires and symmetric keys. Key distribution for symmetric keys requires
confidentiality to prevent third parties from getting access to the key, confidentiality to prevent third parties from getting access to the key,
since they could then generate valid Signed URIs for unauthorized since they could then generate valid Signed URIs for unauthorized
requests. Key distribution for asymmetric keys does not require requests. Key distribution for asymmetric keys does not require
confidentiality since public keys can typically be distributed openly confidentiality since public keys can typically be distributed openly
(because they cannot be used to sign URIs) and the corresponding private keys are kept (because they cannot be used to sign URIs) and the corresponding private keys are kept
secret by the URI signer.</t> secret by the URI signer.</t>
<t>Note: While using a symmetric shared key is supported, it is <bcp14>N
<t>Note: While using a symmetric shared key is supported, it is NOT RECO OT RECOMMENDED</bcp14>.
MMENDED. See the <xref target="security" format="default">Security Considerations
See the <xref target="security">Security Considerations</xref> section a </xref> about the
bout the
limitations of shared keys.</t> limitations of shared keys.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="URI Signing in a non-CDNI context"> <name>URI Signing in a Non-CDNI Context</name>
<t>While the URI Signing method defined in this document was primarily <t>While the URI Signing method defined in this document was primarily
created for the purpose of allowing URI Signing in CDNI scenarios, created for the purpose of allowing URI Signing in CDNI scenarios,
i.e., between a uCDN and a dCDN, there is i.e., between a uCDN and a dCDN, there is
nothing in the defined URI Signing method that precludes it from being 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 non-CDNI context. As such, the described mechanism could be
used in a single-CDN scenario such as shown in <xref target="fig_single_ used in a single-CDN scenario such as shown in <xref target="fig_single_
cdn"/> cdn" format="default"/>
in <xref target="background"/>, for example in <xref target="background" format="default"/> for example
to allow a CSP that uses different CDNs to only have to implement a to allow a CSP that uses different CDNs to only have to implement a
single URI Signing mechanism.</t> single URI Signing mechanism.</t>
</section> </section>
</section> </section>
<section anchor="jwt_profile" numbered="true" toc="default">
<section anchor="jwt_profile" title="JWT Format and Processing Requirements" <name>JWT Format and Processing Requirements</name>
> <t>The concept behind URI Signing is based on embedding a signed <xref tar
<t>The concept behind URI Signing is based on embedding a signed <xref tar get="RFC7519" format="default">JSON Web Token (JWT)</xref>
get="RFC7519">JSON Web Token (JWT)</xref> in an <xref target="RFC7230" format="default">HTTP or HTTPS URI</xref> (se
in an <xref target="RFC7230">HTTP or HTTPS URI</xref> (see [RFC7230] Secti e <xref target="RFC7230" sectionFormat="of" section="2.7"/>). The signed JWT con
on 2.7). The signed JWT contains a number of tains a number of
claims that can be verified to ensure the UA has legitimate access to the content.</t> claims that can be verified to ensure the UA has legitimate access to the content.</t>
<t>This document specifies the following attribute for embedding a signed JWT in a Target CDN URI or Redirection URI:</t> <t>This document specifies the following attribute for embedding a signed JWT in a Target CDN URI or Redirection URI:</t>
<t> <dl>
<list style="symbols">
<t>URI Signing Package (URISigningPackage): The URI attribute that <dt>URI Signing Package (URISigningPackage):
encapsulates all the URI Signing claims in a signed JWT encoded </dt>
format. This attribute is exposed in the Signed URI as a path-style pa <dd>The URI attribute that encapsulates all the URI Signing claims in
rameter a signed JWT encoded format. This attribute is exposed in the Signed
or a form-style parameter.</t> URI as a path-style parameter or a form-style parameter.
</list> </dd>
</t> </dl>
<t>The parameter name of the URI Signing Package Attribute is <t>The parameter name of the URI Signing Package Attribute is
defined in the <xref target="metadata">CDNI Metadata</xref>. If the CDNI M etadata interface defined in the <xref target="metadata" format="default">CDNI Metadata</xre f>. If the CDNI Metadata interface
is not used, or does not include a parameter name for the URI Signing 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 Package Attribute, the parameter name can be set by configuration (out of
scope of this document).</t> scope of this document).</t>
<t>The URI Signing Package will be found by parsing any path-style paramet ers and <t>The URI Signing Package will be found by parsing any path-style paramet ers and
form-style parameters looking for a key name matching the URI Signing Pack age Attribute. form-style parameters looking for a key name matching the URI Signing Pack age Attribute.
Both parameter styles MUST be supported to allow flexibility of operation. Both parameter styles <bcp14>MUST</bcp14> be supported to allow flexibilit
The first matching parameter SHOULD be taken to provide the signed JWT, th y of operation.
ough providing The first matching parameter <bcp14>SHOULD</bcp14> be taken to provide the
signed JWT, though providing
more than one matching key is undefined behavior. Path-style parameters ge nerated in the more than one matching key is undefined behavior. Path-style parameters ge nerated in the
form indicated by Section 3.2.7 of <xref target="RFC6570" /> and form indicated by <xref target="RFC6570" sectionFormat="of" section="3.2.7
Form-style parameters generated in the form indicated by Sections 3.2.8 an " format="default"/> and
d 3.2.9 of Form-style parameters generated in the form indicated by Sections <xref ta
<xref target="RFC6570" /> MUST be supported.</t> rget="RFC6570" section="3.2.8" sectionFormat="bare"/> and <xref target="RFC6570
" sectionFormat="bare" section="3.2.9"/> of
<xref target="RFC6570" format="default"/> <bcp14>MUST</bcp14> be supported
.</t>
<t>The following is an example where the URI Signing Package Attribute nam e is "token" and the signed JWT is "SIGNEDJWT":</t> <t>The following is an example where the URI Signing Package Attribute nam e is "token" and the signed JWT is "SIGNEDJWT":</t>
<figure><artwork>http://example.com/media/path?come=data&amp;token=SIGNEDJ WT&amp;other=data</artwork></figure>
<section anchor="jwt_claims" title="JWT Claims"> <sourcecode><![CDATA[http://example.com/media/path?come=data&token=SIGNEDJ
WT&other=data]]></sourcecode>
<section anchor="jwt_claims" numbered="true" toc="default">
<name>JWT Claims</name>
<t>This section identifies the set of claims that can be <t>This section identifies the set of claims that can be
used to enforce the CSP distribution policy. New claims can be introduce d in the future to extend the used to enforce the CSP distribution policy. New claims can be introduce d in the future to extend the
distribution policy capabilities.</t> distribution policy capabilities.</t>
<t>In order to provide distribution policy flexibility, <t>In order to provide distribution policy flexibility,
the exact subset of claims used in a given signed JWT is a runtime decis ion. the exact subset of claims used in a given signed JWT is a runtime decis ion.
Claim requirements are defined in the <xref target="metadata">CDNI Metad ata</xref>. Claim requirements are defined in the <xref target="metadata" format="de fault">CDNI Metadata</xref>.
If the CDNI Metadata interface is not used, or If the CDNI Metadata interface is not used, or
does not include claim requirements, the claim requirements does not include claim requirements, the claim requirements
can be set by configuration (out of scope of this document).</t> can be set by configuration (out of scope of this document).</t>
<t>The following claims (where the "JSON Web Token Claims" registry <t>The following claims (where the "JSON Web Token Claims" registry
claim name is specified in parentheses below) are used to enforce the claim name is specified in parentheses below) are used to enforce the
distribution policies. All of the listed claims are mandatory distribution policies. All of the listed claims are mandatory
to implement in a URI Signing implementation, but are not necessarily to implement in a URI Signing implementation but are not necessarily
mandatory to use in a given signed JWT. (The "optional" and mandatory to use in a given signed JWT. (The "optional" and
"mandatory" identifiers in square brackets refer to whether or "mandatory" identifiers in square brackets refer to whether or
not a given claim MUST be present in a URI Signing JWT.)</t> not a given claim <bcp14>MUST</bcp14> be present in a URI Signing JWT.)<
/t>
<t>Note: The time on the entities that generate and <t>Note: The time on the entities that generate and
verify the signed URI MUST be in sync. In the CDNI case, this verify the Signed URI <bcp14>MUST</bcp14> be in sync. In the CDNI case, this
means that CSP, uCDN, and dCDN servers need to be means that CSP, uCDN, and dCDN servers need to be
time-synchronized. It is RECOMMENDED to use time synchronized. It is <bcp14>RECOMMENDED</bcp14> to use
<xref target="RFC5905">NTP</xref> for time synchronization.</t> <xref target="RFC5905" format="default">NTP</xref> for time synchronizat
ion.</t>
<t>Note: See the <xref target="security">Security <t>Note: See the <xref target="security" format="default">Security
Considerations</xref> section on the limitations of using an Considerations</xref> on the limitations of using an
expiration time and client IP address for distribution policy expiration time and Client IP address for distribution policy
enforcement.</t> enforcement.</t>
<section anchor="iss_claim" numbered="true" toc="default">
<name>Issuer (iss) Claim</name>
<section anchor="iss_claim" title="Issuer (iss) claim"> <t>Issuer (iss) [optional] - The semantics in
<t>Issuer (iss) [optional] - The semantics in <xref target="RFC7519" sectionFormat="of" section="4.1.1" format="de
<xref target="RFC7519"/> Section 4.1.1 MUST be followed. fault"/> <bcp14>MUST</bcp14> be followed.
If this claim is used, it MUST be used to identify the If this claim is used, it <bcp14>MUST</bcp14> be used to identify th
issuer (signer) of the JWT. In particular, the recipient will have e
already Issuer (signer) of the JWT. In particular, the recipient will have
received, in trusted configuration, a mapping of issuer name to one already
or more received, in trusted configuration, a mapping of Issuer name to one
keys used to sign JWTs, and must verify that the JWT was signed by o or more
ne of keys used to sign JWTs and must verify that the JWT was signed by on
e of
those keys. If this claim is used and the CDN verifying the those keys. If this claim is used and the CDN verifying the
signed JWT does not support Issuer verification, or if the signed JWT does not support Issuer verification, or if the
Issuer in the signed JWT does not match the list of known Issuer in the signed JWT does not match the list of known
acceptable Issuers, or if the Issuer claim does not acceptable Issuers, or if the Issuer claim does not
match the key used to sign the JWT, the CDN MUST reject the request. If the match the key used to sign the JWT, the CDN <bcp14>MUST</bcp14> reje ct the request. If the
received signed JWT contains an Issuer claim, then any received signed JWT contains an Issuer claim, then any
JWT subsequently generated for CDNI redirection MUST also contain an JWT subsequently generated for CDNI redirection <bcp14>MUST</bcp14>
Issuer also contain an Issuer
claim, and the Issuer value MUST be updated to identify the claim, and the Issuer value <bcp14>MUST</bcp14> be updated to identi
fy the
redirecting CDN. If the received signed JWT does not redirecting CDN. If the received signed JWT does not
contain an Issuer claim, an Issuer claim MAY be added to contain an Issuer claim, an Issuer claim <bcp14>MAY</bcp14> be added to
a signed JWT generated for CDNI redirection.</t> a signed JWT generated for CDNI redirection.</t>
</section> </section>
<section anchor="sub_claim" title="Subject (sub) claim"> <section anchor="sub_claim" numbered="true" toc="default">
<t>Subject (sub) [optional] - The semantics in <xref target="RFC7519 <name>Subject (sub) Claim</name>
"/> Section 4.1.2 MUST be followed. <t>Subject (sub) [optional] - The semantics in <xref target="RFC7519"
If this claim is used, it MUST be a JSON Web Encryption (<xref targe sectionFormat="of" section="4.1.2" format="default"/> <bcp14>MUST</bcp14> be fo
t="RFC7516">JWE</xref>) llowed.
If this claim is used, it <bcp14>MUST</bcp14> be a JSON Web Encrypti
on (<xref target="RFC7516" format="default">JWE</xref>)
Object in compact serialization form, because it contains Object in compact serialization form, because it contains
personally identifiable information. This claim contains personally identifiable information. This claim contains
information about the subject (for example, a user or an agent) information about the Subject (for example, a user or an agent)
that MAY be used to verify the signed JWT. that <bcp14>MAY</bcp14> be used to verify the signed JWT.
If the received signed JWT contains a Subject claim, then any If the received signed JWT contains a Subject claim, then any
JWT subsequently generated for CDNI redirection MUST also JWT subsequently generated for CDNI redirection <bcp14>MUST</bcp14>
contain a Subject claim, and the Subject value MUST be the same also
contain a Subject claim, and the Subject value <bcp14>MUST</bcp14> b
e the same
as in the received signed JWT. A signed JWT generated for CDNI as in the received signed JWT. A signed JWT generated for CDNI
redirection MUST NOT add a Subject claim if no Subject claim redirection <bcp14>MUST NOT</bcp14> add a Subject claim if no Subjec t claim
existed in the received signed JWT.</t> existed in the received signed JWT.</t>
</section> </section>
<section anchor="aud_claim" title="Audience (aud) claim">
<t>Audience (aud) [optional] - The semantics in <xref target="RFC751 <section anchor="aud_claim" numbered="true" toc="default">
9"/> Section 4.1.3 MUST be followed. <name>Audience (aud) Claim</name>
<t>Audience (aud) [optional] - The semantics in <xref target="RFC7519"
sectionFormat="of" section="4.1.3" format="default"/> <bcp14>MUST</bcp14> be fo
llowed.
This claim is used to ensure that the CDN verifying the JWT is an in tended recipient This claim is used to ensure that the CDN verifying the JWT is an in tended recipient
of the request. The claim MUST of the request. The claim <bcp14>MUST</bcp14>
contain an identity belonging to the chain of entities involved in 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) 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 r equest. that the recipient is configured to use for the processing of this r equest.
A CDN MAY modify the claim as long it can generate a valid signature .</t> A CDN <bcp14>MAY</bcp14> modify the claim as long it can generate a valid signature.</t>
</section> </section>
<section anchor="exp_claim" title="Expiry Time (exp) claim"> <section anchor="exp_claim" numbered="true" toc="default">
<t>Expiry Time (exp) [optional] - The semantics in <xref target="RFC <name>Expiry Time (exp) Claim</name>
7519"/> Section 4.1.4 MUST be followed, <t>Expiry Time (exp) [optional] - The semantics in <xref
though URI Signing implementations MUST NOT allow for any time synch target="RFC7519" sectionFormat="of" section="4.1.4"
ronization "leeway". format="default"/> <bcp14>MUST</bcp14> be followed,
If this claim is used and the CDN verifying the signed JWT does not though URI Signing implementations <bcp14>MUST NOT</bcp14> allow for
support any time-synchronization "leeway". If this claim is used and the
Expiry Time verification, or if the Expiry Time in the CDN verifying the signed JWT does not support Expiry Time
signed JWT corresponds to a time equal to or earlier than the time o verification, or if the Expiry Time in the signed JWT corresponds to
f a time equal to or earlier than the time of the content request, the
the content request, the CDN MUST reject the CDN <bcp14>MUST</bcp14> reject the request. If the received signed
request. JWT contains an Expiry Time claim, then any JWT subsequently
If the received signed JWT contains an Expiry Time claim, then any generated for CDNI redirection <bcp14>MUST</bcp14> also contain an
JWT subsequently generated for CDNI redirection MUST also Expiry Time claim, and the Expiry Time value <bcp14>MUST</bcp14> be
contain an Expiry Time claim, and the Expiry Time value MUST be the same as in the received signed JWT. A signed JWT generated for
the same as in the received signed JWT. A signed JWT CDNI redirection <bcp14>MUST NOT</bcp14> add an Expiry Time claim if
generated for CDNI redirection MUST NOT add an Expiry Time no Expiry Time claim existed in the received signed JWT.</t>
claim if no Expiry Time claim existed in the received
signed JWT.</t>
</section> </section>
<section anchor="nbf_claim" title="Not Before (nbf) claim"> <section anchor="nbf_claim" numbered="true" toc="default">
<t>Not Before (nbf) [optional] - The semantics in <xref target="RFC7 <name>Not Before (nbf) Claim</name>
519"/> Section 4.1.5 MUST be followed, <t>Not Before (nbf) [optional] - The semantics in <xref target="RFC751
though URI Signing implementations MUST NOT allow for any time synch 9"
ronization "leeway". sectionFormat="of" section="4.1.5" format="default"/> <bcp14>MUST</bcp14> be fo
llowed,
though URI Signing implementations <bcp14>MUST NOT</bcp14> allow for
any time-synchronization "leeway".
If this claim is used and the CDN verifying the signed JWT does not support 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 Not Before time verification, or if the Not Before time in the
signed JWT corresponds to a time later than the time of signed JWT corresponds to a time later than the time of
the content request, the CDN MUST reject the the content request, the CDN <bcp14>MUST</bcp14> reject the
request. request.
If the received signed JWT contains a Not Before time claim, then an y If the received signed JWT contains a Not Before time claim, then an y
JWT subsequently generated for CDNI redirection MUST also JWT subsequently generated for CDNI redirection <bcp14>MUST</bcp14>
contain a Not Before time claim, and the Not Before time value MUST also
be contain a Not Before time claim, and the Not Before time value <bcp1
4>MUST</bcp14> be
the same as in the received signed JWT. A signed JWT the same as in the received signed JWT. A signed JWT
generated for CDNI redirection MUST NOT add a Not Before time generated for CDNI redirection <bcp14>MUST NOT</bcp14> add a Not Bef ore time
claim if no Not Before time claim existed in the received claim if no Not Before time claim existed in the received
signed JWT.</t> signed JWT.</t>
</section> </section>
<section anchor="iat_claim" title="Issued At (iat) claim"> <section anchor="iat_claim" numbered="true" toc="default">
<t>Issued At (iat) [optional] - The semantics in <xref target="RFC75 <name>Issued At (iat) Claim</name>
19"/> Section 4.1.6 MUST be followed. <t>Issued At (iat) [optional] - The semantics in <xref target="RFC7519
"
sectionFormat="of" section="4.1.6" format="default"/> <bcp14>MUST</bcp14> be fo
llowed.
If the received signed JWT contains an Issued At claim, then any If the received signed JWT contains an Issued At claim, then any
JWT subsequently generated for CDNI redirection MUST also contain an JWT subsequently generated for CDNI redirection <bcp14>MUST</bcp14>
Issued At also contain an Issued At
claim, and the Issued At value MUST be updated to identify the claim, and the Issued At value <bcp14>MUST</bcp14> be updated to ide
ntify the
time the new JWT was generated. If the received signed time the new JWT was generated. If the received signed
JWT does not contain an Issued At claim, an Issued At JWT does not contain an Issued At claim, an Issued At
claim MAY be added to a signed JWT generated for CDNI redirection.</ t> claim <bcp14>MAY</bcp14> be added to a signed JWT generated for CDNI redirection.</t>
</section> </section>
<section anchor="jti_claim" title="JWT ID (jti) claim"> <section anchor="jti_claim" numbered="true" toc="default">
<t>JWT ID (jti) [optional] - The semantics in <xref target="RFC7519" <name>JWT ID (jti) Claim</name>
/> Section 4.1.7 MUST be followed. <t>JWT ID (jti) [optional] - The semantics in <xref target="RFC7519"
sectionFormat="of" section="4.1.7" format="default"/> <bcp14>MUST</bcp14> be fo
llowed.
A JWT ID can be used to prevent replay attacks if the CDN stores a A JWT ID can be used to prevent replay attacks if the CDN stores a
list of all previously used values, and verifies list of all previously used values and verifies
that the value in the current JWT has never been used that the value in the current JWT has never been used
before. If the signed JWT contains a JWT ID claim and the before. If the signed JWT contains a JWT ID claim and the
CDN verifying the signed JWT either does not support JWT ID CDN verifying the signed JWT either does not support JWT ID
storage or has previously seen the value used in a request for the s ame content, then the CDN MUST reject the request. storage or has previously seen the value used in a request for the s ame content, then the CDN <bcp14>MUST</bcp14> reject the request.
If the received signed JWT contains a JWT ID claim, then any If the received signed JWT contains a JWT ID claim, then any
JWT subsequently generated for CDNI redirection MUST also JWT subsequently generated for CDNI redirection <bcp14>MUST</bcp14>
contain a JWT ID claim, and the value MUST be the also
contain a JWT ID claim, and the value <bcp14>MUST</bcp14> be the
same as in the received signed JWT. same as in the received signed JWT.
If the received signed JWT does not contain a If the received signed JWT does not contain a
JWT ID claim, a JWT ID claim MUST NOT be added to a signed JWT JWT ID claim, a JWT ID claim <bcp14>MUST NOT</bcp14> be added to a s igned JWT
generated for CDNI redirection. Sizing of the JWT ID is application generated for CDNI redirection. Sizing of the JWT ID is application
dependent given the desired security constraints.</t> dependent given the desired security constraints.</t>
</section> </section>
<section anchor="cdniv_claim" title="CDNI Claim Set Version (cdniv) clai <section anchor="cdniv_claim" numbered="true" toc="default">
m">
<t>CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set Ve <name>CDNI Claim Set Version (cdniv) Claim</name>
rsion (cdniv) <t>CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set Vers
ion (cdniv)
claim provides a means within a signed JWT to tie the claim set to a specific version 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 of this specification. The cdniv claim is intended to allow changes in and facilitate
upgrades across specifications. The type is JSON integer and the val ue MUST be set to "1", upgrades across specifications. The type is a JSON integer and the v alue <bcp14>MUST</bcp14> be set to "1"
for this version of the specification. In the absence of this claim, the value is assumed 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. Impleme ntations MUST reject to be "1". For future versions, this claim will be mandatory. Implem entations <bcp14>MUST</bcp14> reject
signed JWTs with unsupported CDNI Claim Set versions.</t> signed JWTs with unsupported CDNI Claim Set versions.</t>
</section> </section>
<section anchor="cdnicrit_claim" title="CDNI Critical Claims Set (cdnicr <section anchor="cdnicrit_claim" numbered="true" toc="default">
it) claim"> <name>CDNI Critical Claims Set (cdnicrit) Claim</name>
<t>CDNI Critical Claims Set (cdnicrit) [optional] - The CDNI Critica <t>CDNI Critical Claims Set (cdnicrit) [optional] - The CDNI Critical
l Claims Set (cdnicrit) claim Claims Set (cdnicrit) claim
indicates that extensions to this specification are being used that indicates that extensions to this specification are being used that
MUST be understood and processed. Its value is a comma separated li sting <bcp14>MUST</bcp14> be understood and processed. Its value is a com ma-separated listing
of claims in the Signed JWT that use those extensions. of claims in the Signed JWT that use those extensions.
If any of the listed extension claims are not understood If any of the listed extension claims are not understood
and supported by the recipient, then the Signed JWT MUST be rejected and supported by the recipient, then the Signed JWT <bcp14>MUST</bcp
. Producers 14> be rejected. Producers
MUST NOT include claim names defined by this specification, duplicat <bcp14>MUST NOT</bcp14> include claim names defined by this specific
e names, or names that do not ation, duplicate names, or names that do not
occur as claim names within the Signed JWT in the cdnicrit occur as claim names within the Signed JWT in the cdnicrit
list. Producers MUST NOT use the empty list "" as the cdnicrit list. Producers <bcp14>MUST NOT</bcp14> use the empty list "" as th
value. Recipients MAY consider the Signed JWT to be invalid if the e cdnicrit
cdnicrit value. Recipients <bcp14>MAY</bcp14> consider the Signed JWT to be
invalid if the cdnicrit
list contains any claim names defined by this list contains any claim names defined by this
specification or if any other constraints specification or if any other constraints
on its use are violated. This claim MUST be understood and processe d by all implementations.</t> on its use are violated. This claim <bcp14>MUST</bcp14> be understo od and processed by all implementations.</t>
</section> </section>
<section anchor="cdniip_claim" title="Client IP Address (cdniip) claim"> <section anchor="cdniip_claim" numbered="true" toc="default">
<t>Client IP Address (cdniip) [optional] - The Client IP Address (cd <name>Client IP Address (cdniip) Claim</name>
niip) claim holds an IP address or IP prefix for
<t>Client IP Address (cdniip) [optional] - The Client IP Address (cdni
ip) claim holds an IP address or IP prefix for
which the Signed URI is valid. This is represented in CIDR which the Signed URI is valid. This is represented in CIDR
notation, with dotted decimal format for <xref target="RFC0791">IPv4 notation with dotted decimal format for <xref target="RFC0791" forma
addresses</xref> or canonical text t="default">IPv4 addresses</xref> or canonical text
representation for <xref target="RFC5952">IPv6 addresses</xref>. representation for <xref target="RFC5952" format="default">IPv6 addr
The request MUST be rejected if sourced from a client outside the esses</xref>.
specified IP range. Since the client IP is considered The request <bcp14>MUST</bcp14> be rejected if sourced from a client
personally identifiable information this field outside the
MUST be a JSON Web Encryption (<xref target="RFC7516">JWE</xref>) specified IP range. Since the Client IP is considered
personally identifiable information, this field
<bcp14>MUST</bcp14> be a JSON Web Encryption (<xref target="RFC7516"
format="default">JWE</xref>)
Object in compact serialization form. If the CDN verifying the Object in compact serialization form. If the CDN verifying the
signed JWT does not support Client IP verification, or if the signed JWT does not support Client IP verification, or if the
Client IP in the signed JWT does not match the source IP Client IP in the signed JWT does not match the source IP
address in the content request, the CDN MUST address in the content request, the CDN <bcp14>MUST</bcp14>
reject the request. The type of this claim is a JSON string that reject the request. The type of this claim is a JSON string that
contains the JWE. contains the JWE.
If the received signed JWT contains a Client IP claim, then any If the received signed JWT contains a Client IP claim, then any
JWT subsequently generated for CDNI redirection MUST also JWT subsequently generated for CDNI redirection <bcp14>MUST</bcp14>
contain a Client IP claim, and the Client IP value MUST be also
contain a Client IP claim, and the Client IP value <bcp14>MUST</bcp1
4> be
the same as in the received signed JWT. A signed JWT the same as in the received signed JWT. A signed JWT
generated for CDNI redirection MUST NOT add a Client IP generated for CDNI redirection <bcp14>MUST NOT</bcp14> add a Client IP
claim if no Client IP claim existed in the received claim if no Client IP claim existed in the received
signed JWT.</t> signed JWT.</t>
<t>It should be noted that use of this claim can cause issues, for e xample, <t>It should be noted that use of this claim can cause issues, for exa mple,
in situations with dual-stack IPv4 and IPv6 networks, MPTCP, QUIC, a nd in situations with dual-stack IPv4 and IPv6 networks, MPTCP, QUIC, a nd
mobile clients switching from Wi-Fi to Cellular networks where the c lient's mobile clients switching from Wi-Fi to Cellular networks where the c lient's
source address can change, even between address families. This claim exists source address can change, even between address families. This claim exists
mainly for legacy feature parity reasons, therefore use of this clai m should mainly for legacy feature parity reasons; therefore, use of this cla im should
be done judiciously. An example of a reasonable use case would be ma king a be done judiciously. An example of a reasonable use case would be ma king a
signed JWT for an internal preview of an asset where the end consume r understands signed JWT for an internal preview of an asset where the end consume r understands
that they must be originated from the same IP for the entirety of th e session. that they must be originated from the same IP for the entirety of th e session.
Using this claim at large is NOT RECOMMENDED.</t> Using this claim at large is <bcp14>NOT RECOMMENDED</bcp14>.</t>
</section> </section>
<section anchor="cdniuc_claim" title="CDNI URI Container (cdniuc) claim" <section anchor="cdniuc_claim" numbered="true" toc="default">
> <name>CDNI URI Container (cdniuc) Claim</name>
<t>URI Container (cdniuc) [mandatory] - The URI Container (cdniuc) <t>URI Container (cdniuc) [mandatory] - The URI Container (cdniuc)
holds the URI representation before a URI Signing Package is holds the URI representation before a URI Signing Package is
added. This representation can take one of several forms detailed in added. This representation can take one of several forms detailed in
<xref target="uri_container_forms"/>. If the URI Container used in t he signed <xref target="uri_container_forms" format="default"/>. If the URI Co ntainer used in the signed
JWT does not match the URI of the content request, the CDN verifyin g the JWT does not match the URI of the content request, the CDN verifyin g the
signed JWT MUST reject the request. When comparing the URI, the perc signed JWT <bcp14>MUST</bcp14> reject the request. When comparing th
ent encoded e URI, the percent encoded
form as defined in <xref target="RFC3986"/> Section 2.1 MUST be used form as defined in <xref target="RFC3986" sectionFormat="of" section
. When ="2.1" format="default"/> <bcp14>MUST</bcp14> be used. When
redirecting a URI, the CDN generating the new signed JWT MAY change redirecting a URI, the CDN generating the new signed JWT <bcp14>MAY<
the URI /bcp14> change the URI
Container to comport with the URI being used in the redirection.</t> Container to comport with the URI being used in the redirection.</t>
</section> </section>
<section anchor="cdniets_claim" title="CDNI Expiration Time Setting (cdn <section anchor="cdniets_claim" numbered="true" toc="default">
iets) claim"> <name>CDNI Expiration Time Setting (cdniets) Claim</name>
<t>CDNI Expiration Time Setting (cdniets) [optional] - The CDNI Expi <t>CDNI Expiration Time Setting (cdniets) [optional] - The CDNI Expira
ration tion
Time Setting (cdniets) claim provides a means for setting the value Time Setting (cdniets) claim provides a means for setting the value
of the Expiry Time (exp) claim when generating a subsequent signed J WT of the Expiry Time (exp) claim when generating a subsequent signed J WT
in Signed Token Renewal. Its type is a JSON numeric value. It 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 J WT is verified denotes the number of seconds to be added to the time at which the J WT is verified
that gives the value of the Expiry Time (exp) claim of the next sign ed JWT. that gives the value of the Expiry Time (exp) claim of the next sign ed JWT.
The CDNI Expiration Time Setting (cdniets) SHOULD NOT be used when n The CDNI Expiration Time Setting (cdniets) <bcp14>SHOULD NOT</bcp14>
ot using Signed Token Renewal be used when not using Signed Token Renewal
and MUST be present when using Signed Token Renewal.</t> and <bcp14>MUST</bcp14> be present when using Signed Token Renewal.<
/t>
</section> </section>
<section anchor="cdnistt_claim" title="CDNI Signed Token Transport (cdni <section anchor="cdnistt_claim" numbered="true" toc="default">
stt) claim"> <name>CDNI Signed Token Transport (cdnistt) Claim</name>
<t>CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed Token Transport (cdnistt) claim <t>CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed Token Transport (cdnistt) claim
provides a means of signalling the method through which a new signed J WT provides a means of signaling the method through which a new signed JW T
is transported from the CDN to the UA and vice versa for the purpose o f Signed Token Renewal. Its type is a JSON integer. is transported from the CDN to the UA and vice versa for the purpose o f Signed Token Renewal. Its type is a JSON integer.
Values for this claim are defined in <xref target="sec.IANA.cdnistt"/> Values for this claim are defined in <xref target="sec.IANA.cdnistt" f
. If using ormat="default"/>. If using
this claim you MUST also specify a CDNI Expiration Time Setting (cdnie this claim, you <bcp14>MUST</bcp14> also specify a CDNI Expiration Tim
ts) as noted above.</t> e Setting (cdniets) as noted above.</t>
</section> </section>
<section anchor="cdnistd_claim" title="CDNI Signed Token Depth (cdnistd) <section anchor="cdnistd_claim" numbered="true" toc="default">
claim"> <name>CDNI Signed Token Depth (cdnistd) Claim</name>
<t>CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Toke n Depth (cdnistd) claim is used to <t>CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Toke n Depth (cdnistd) claim is used to
associate a subsequent signed JWT, generated as the result of a CDNI S igned Token Transport claim, associate a subsequent signed JWT, generated as the result of a CDNI S igned Token Transport claim,
with a specific URI subset. Its type is a JSON integer. Signed JWTs MU ST NOT use a negative with a specific URI subset. Its type is a JSON integer. Signed JWTs <b cp14>MUST NOT</bcp14> use a negative
value for the CDNI Signed Token Depth claim.</t> value for the CDNI Signed Token Depth claim.</t>
<t>If the transport used for Signed Token Transport allows the CDN to associate the path component of a <t>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 section 4.1 .2.4 of <xref target="RFC6265"/>), URI with tokens (e.g., an HTTP Cookie Path as described in <xref targe t="RFC6265" sectionFormat="of" section="4.1.2.4" format="default"/>),
the CDNI Signed Token Depth value is the number of path segments that should be 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 considered significant for this association. A CDNI Signed Token Depth of zero means that the
client SHOULD be directed to return the token with requests for any pa client <bcp14>SHOULD</bcp14> be directed to return the token with requ
th. If the CDNI Signed ests for any path. If the CDNI Signed
Token Depth is greater than zero, then the CDN SHOULD send the client Token Depth is greater than zero, then the CDN <bcp14>SHOULD</bcp14> s
a token to return for end the client a token to return for
future requests wherein the first CDNI Signed Token Depth segments of the path match the first 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 CDNI Signed Token Depth segments of the Signed URI path. This matching
MUST use the URI with the <bcp14>MUST</bcp14> use the URI with the
token removed, as specified in <xref target="uri_container_forms"/>.</ token removed, as specified in <xref target="uri_container_forms" form
t> at="default"/>.</t>
<t>If the URI path to match contains fewer segments than the CDNI Sign ed Token Depth claim, a signed JWT <t>If the URI path to match contains fewer segments than the CDNI Sign ed Token Depth claim, a signed JWT
MUST NOT be generated for the purposes of Signed Token Renewal. If the CDNI Signed Token Depth <bcp14>MUST NOT</bcp14> 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. I f the received signed JWT claim is omitted, it means the same thing as if its value were zero. I f the received signed JWT
contains a CDNI Signed Token Depth claim, then any JWT subsequently ge nerated for CDNI contains a CDNI Signed Token Depth claim, then any JWT subsequently ge nerated for CDNI
redirection or Signed Token Transport MUST also contain a CDNI Signed redirection or Signed Token Transport <bcp14>MUST</bcp14> also contain
Token Depth claim, and the a CDNI Signed Token Depth claim, and the
value MUST be the same as in the received signed JWT.</t> value <bcp14>MUST</bcp14> be the same as in the received signed JWT.</
t>
</section> </section>
<section anchor="uri_container_forms" title="URI Container Forms"> <section anchor="uri_container_forms" numbered="true" toc="default">
<name>URI Container Forms</name>
<t>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 capabil ities.</t> <t>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 capabil ities.</t>
<t>Before comparing a URI with contents of this container, the followi <t>Before comparing a URI with contents of this container, the followi
ng steps MUST be performed: ng steps <bcp14>MUST</bcp14> be performed:
<list style="symbols"> </t>
<t>Prior to verification, remove the signed JWT from <ul spacing="normal">
the URI. This removal is only for the purpose of determining if th <li>Prior to verification, remove the signed JWT from the
e URI matches; all URI. This removal is only for the purpose of determining if the
other purposes will use the original URI. If the signed JWT is ter URI matches; all other purposes will use the original URI. If the
minated by anything signed JWT is terminated by anything other than a sub-delimiter
other than a sub-delimiter (as defined in <xref target="RFC3986"/> (as defined in <xref target="RFC3986" section="2.2"
Section 2.2), sectionFormat="of" format="default"/>), everything from the
everything from the reserved character (as defined in <xref target reserved character (as defined in <xref target="RFC3986"
="RFC3986"/> Section 2.2) section="2.2"/>) that precedes the URI Signing Package Attribute to
that precedes the URI Signing Package Attribute to the last charac the last character of the signed
ter of the signed
JWT will be removed, inclusive. Otherwise, everything from the fir st character of the JWT will be removed, inclusive. Otherwise, everything from the fir st character of the
URI Signing Package Attribute to the sub-delimiter that terminates the signed URI Signing Package Attribute to the sub-delimiter that terminates the signed
JWT will be removed, inclusive.</t> JWT will be removed, inclusive.</li>
<t>Normalize the URI according to <xref target="RFC7230">section 2.7 <li>Normalize the URI according to <xref target="RFC7230" sectionF
.3</xref> and ormat="of" section="2.7.3" format="default"/> and Sections
<xref target="RFC3986"> sections 6.2.2 and 6.2.3</xref>. This appl <xref target="RFC3986" section="6.2.2" sectionFormat="bare"/> and <
ies to both generation xref target="RFC3986" section="6.2.3" sectionFormat="bare"/> of
and verification of the signed JWT.</t> <xref target="RFC3986" format="default"/>. This applies to both ge
</list></t> neration
and verification of the signed JWT.</li>
<section anchor="uri_container_forms_hash" title="URI Hash Container ( </ul>
hash:)"> <section anchor="uri_container_forms_hash" numbered="true" toc="defaul
<t>Prefixed with 'hash:', this string is a URL Segment form (<xref t">
target="RFC6920"/> Section 5) of the URI.</t> <name>URI Hash Container (hash:)</name>
<t>Prefixed with 'hash:', this string is a URL Segment form (<xref t
arget="RFC6920" section="5" sectionFormat="of" format="default"/>) of the URI.<
/t>
</section> </section>
<section anchor="uri_container_forms_regex" numbered="true" toc="defau
lt">
<name>URI Regular Expression Container (regex:)</name>
<t>Prefixed with 'regex:', this string is any regular expression com
patible with POSIX (Section 9 of <xref
target="POSIX.1" format="default"/>) Extended Regular
Expression used to match against the
requested URI. These regular expressions <bcp14>MUST</bcp14> be
evaluated in the POSIX locale (Section 7.2 of <xref target="POSIX.1"
format="default"/>).
</t>
<t>Note: Because '\' has special meaning in JSON <xref target="RFC82
59" format="default"/> as the escape character within JSON strings, the regular
expression character '\' <bcp14>MUST</bcp14> be escaped as '\\'.</t>
<t>An example of a 'regex:' is the following:</t>
<section anchor="uri_container_forms_regex" title="URI Regular Express <sourcecode><![CDATA[
ion Container (regex:)"> [^:]*\\://[^/]*/dir/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)?
<t>Prefixed with 'regex:', this string is any <xref target="POSIX. ]]></sourcecode>
1">POSIX Section 9</xref> Extended <t>Note: Due to computational complexity of executing arbitrary regu
Regular Expression compatible regular expression used to match aga lar expressions, it is <bcp14>RECOMMENDED</bcp14> to only execute after verifyin
inst the requested URI. g the JWT to ensure its authenticity.</t>
These regular expressions MUST be evaluated in the POSIX locale (<
xref target="POSIX.1">POSIX Section 7.2</xref>).
</t>
<t>Note: Because '\' has special meaning in JSON <xref target="RFC
8259"/> as the escape character within JSON strings, the regular expression char
acter '\' MUST be escaped as '\\'.</t>
<t>An example of a 'regex:' is the following:</t>
<t>
<figure>
<artwork>
[^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)?
</artwork>
</figure>
</t>
<t>Note: Due to computational complexity of executing arbitrary re
gular expressions, it is RECOMMENDED to only execute after verifying the JWT to
ensure its authenticity.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="jwt_header" numbered="true" toc="default">
<section anchor="jwt_header" title="JWT Header"> <name>JWT Header</name>
<t>The header of the JWT MAY be passed via the CDNI Metadata interface ins <t>The header of the JWT <bcp14>MAY</bcp14> be passed via the CDNI Metad
tead of ata interface instead of
being included in the URISigningPackage. The header value MUST be transmit being included in the URISigningPackage. The header value <bcp14>MUST</bcp
ted in 14> be transmitted in
the serialized encoded form and prepended to the JWT payload and signature passed 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 the URISigningPackage prior to verification. This reduces the size of the signed JWT
token.</t> token.</t>
</section> </section>
</section> </section>
<section anchor="uri_signing_token_renewal" numbered="true" toc="default">
<section anchor="uri_signing_token_renewal" title="URI Signing Token Renewal <name>URI Signing Token Renewal</name>
"> <section anchor="token_renewal_intro" numbered="true" toc="default">
<section anchor="token_renewal_intro" title="Overview"> <name>Overview</name>
<t>For content that is delivered via HTTP in a segmented fashion, <t>For content that is delivered via HTTP in a segmented fashion,
such as <xref target="MPEG-DASH">MPEG-DASH</xref> or <xref target="RFC82 16"> HTTP Live Streaming (HLS)</xref>, such as <xref target="MPEG-DASH" format="default">MPEG-DASH</xref> or <x ref target="RFC8216" format="default"> HTTP Live Streaming (HLS)</xref>,
special provisions need to be made in order to ensure URI Signing can be special provisions need to be made in order to ensure URI Signing can be
applied. In general, segmented protocols work by breaking large objects applied. In general, segmented protocols work by breaking large objects
(e.g., videos) into a sequence of small independent segments. Such segme nts (e.g., videos) into a sequence of small independent segments. Such segme nts
are then referenced by a separate manifest file, which either includes 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 list of URLs to the segments or specifies an algorithm through which
a User Agent can construct the URLs to the segments. Requests for segmen ts a User Agent can construct the URLs to the segments. Requests for segmen ts
therefore originate from the manifest file and, unless the URLs in the 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. 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 This opens up a vulnerability to malicious User Agents sharing the
manifest file and deep-linking to the segments.</t> manifest file and deep linking to the segments.</t>
<t>One method for dealing with this vulnerability would be to include, i n <t>One method for dealing with this vulnerability would be to include, i n
the manifest itself, Signed URIs that point to the individual segments. the manifest itself, Signed URIs that point to the individual segments.
There exist a number of issues with that approach. First, it requires th e There exist a number of issues with that approach. First, it requires th e
CDN delivering the manifest to rewrite the manifest file for each User A gent, CDN delivering the manifest to rewrite the manifest file for each User A gent,
which would require the CDN to be aware of the exact segmentation protoc ol which would require the CDN to be aware of the exact segmentation protoc ol
used. Secondly, it could also require the expiration time of the used. Secondly, it could also require the expiration time of the
Signed URIs to be valid for an extended duration if the content 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 inst ance, if the manifest file were described by the manifest is meant to be consumed in real time. For inst ance, if the manifest file were
to contain a segmented video stream of more than 30 minutes in length, 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 r educing Signed URIs would require to be valid for at least 30 minutes, thereby r educing
their effectiveness and that of the URI Signing mechanism in general. their effectiveness and that of the URI Signing mechanism in general.
For a more detailed analysis of how segmented protocols such as HTTP Ada ptive Streaming protocols affect CDNI, For a more detailed analysis of how segmented protocols such as HTTP Ada ptive Streaming protocols affect CDNI,
see <xref target="RFC6983">Models for HTTP-Adaptive-Streaming-Aware CDNI see <xref target="RFC6983" format="default">Models for HTTP-Adaptive-Str
</xref>.</t> eaming-Aware Content Distribution Network Interconnection (CDNI)</xref>.</t>
<t>The method described in this section allows CDNs to use URI Signing <t>The method described in this section allows CDNs to use URI Signing
for segmented content without for segmented content without
having to include the Signed URIs in the manifest files themselves.</t> having to include the Signed URIs in the manifest files themselves.</t>
</section> </section>
<section anchor="uri_signing_mechanism" numbered="true" toc="default">
<section anchor="uri_signing_mechanism" title="Signed Token Renewal mechan <name>Signed Token Renewal Mechanism</name>
ism">
<t>In order to allow for effective access control of segmented content, the <t>In order to allow for effective access control of segmented content, the
URI Signing mechanism defined in this section is based on a method URI Signing mechanism defined in this section is based on a method
through which subsequent segment requests can be linked together. through which subsequent segment requests can be linked together.
As part of the JWT verification procedure, the CDN can generate a new 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 specific ally, signed JWT that the UA can use to do a subsequent request. More specific ally,
whenever a UA successfully retrieves a segment, it receives, in the whenever a UA successfully retrieves a segment, it receives, in the
HTTP 2xx Successful message, a signed JWT that it can use whenever it HTTP 2xx Successful message, a signed JWT that it can use whenever it
requests the next segment. As long as each successive signed JWT requests the next segment. As long as each successive signed JWT
is correctly verified before a new one is generated, the model is not is correctly verified before a new one is generated, the model is not
broken, and the User Agent can successfully retrieve additional segments . broken, and the User Agent can successfully retrieve additional segments .
Given the fact that with segmented protocols, it is usually not possible to 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 determine a priori which segment will be requested next (i.e., to allow for
seeking within the content and for switching to a different representati on), seeking within the content and for switching to a different representati on),
the Signed Token Renewal uses the the Signed Token Renewal uses the
URI Regular Expression Container scoping mechanisms in the URI Container 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.< /t> (cdniuc) claim to allow a signed JWT to be valid for more than one URL.< /t>
<t>In order for this renewal of signed JWTs to work, it is necessary for <t>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 a n a UA to extract the signed JWT from the HTTP 2xx Successful message of a n
earlier request and use it to retrieve the next segment. The exact mecha nism earlier request and use it to retrieve the next segment. The exact mecha nism
by which the client does this is outside the scope of this document. 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 However, in order to also support legacy UAs that do not include any
specific provisions for the handling of signed JWTs, <xref target="commu specific provisions for the handling of signed JWTs, <xref target="commu
nicating_token"/> nicating_token" format="default"/>
defines a mechanism using HTTP Cookies <xref target="RFC6265"/> that all defines a mechanism using HTTP Cookies <xref target="RFC6265" format="de
ows such UAs to support fault"/> that allows such UAs to support
the concept of renewing signed JWTs without requiring any additional UA support.</t> the concept of renewing signed JWTs without requiring any additional UA support.</t>
<section numbered="true" toc="default">
<section title="Required Claims"> <name>Required Claims</name>
<t>The <xref target="cdnistt_claim">cdnistt claim</xref> and <xref tar <t>The <xref target="cdnistt_claim" format="default">cdnistt claim</xr
get="cdniets_claim">cdniets claim</xref> ef> and <xref target="cdniets_claim" format="default">cdniets claim</xref>
MUST both be present for Signed Token Renewal. cdnistt MAY be set to <bcp14>MUST</bcp14> both be present for Signed Token Renewal. cdnistt
a value of '0' to mean no Signed Token Renewal, but there still MUST b <bcp14>MAY</bcp14> be set to
e a corresponding cdniets that verifies as a value of '0' to mean no Signed Token Renewal, but there still <bcp14
a JSON number. However, if use of Signed Token Renewal is not desired, >MUST</bcp14> be a corresponding cdniets that verifies as
it is RECOMMENDED to simply omit both.</t> a JSON number. However, if use of Signed Token Renewal is not desired,
it is <bcp14>RECOMMENDED</bcp14> to simply omit both.</t>
</section> </section>
</section> </section>
<section anchor="communicating_token" numbered="true" toc="default">
<name>Communicating a Signed JWT in Signed Token Renewal</name>
<section anchor="communicating_token" title="Communicating a signed JWTs i n Signed Token Renewal">
<t>This section assumes the value of the CDNI Signed Token Transport (cd nistt) claim <t>This section assumes the value of the CDNI Signed Token Transport (cd nistt) claim
has been set to 1.</t> has been set to 1.</t>
<t>When using the Signed Token Renewal mechanism, the signed JWT is <t>When using the Signed Token Renewal mechanism, the signed JWT is
transported to the UA via a 'URISigningPackage' cookie added to the transported to the UA via a 'URISigningPackage' cookie added to the
HTTP 2xx Successful message along with the content being returned to 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 the UA, or to the HTTP 3xx Redirection message in case the UA is
redirected to a different server.</t> redirected to a different server.</t>
<section numbered="true" toc="default">
<section title="Support for cross-domain redirection"> <name>Support for Cross-Domain Redirection</name>
<t>For security purposes, the use of cross-domain cookies is not suppo rted <t>For security purposes, the use of cross-domain cookies is not suppo rted
in some application environments. As a result, the Cookie-based in some application environments. As a result, the Cookie-based
method for transport of the Signed Token described in <xref target="co mmunicating_token"/> method for transport of the Signed Token described in <xref target="co mmunicating_token" format="default"/>
might break if used in combination with an HTTP 3xx Redirection might break if used in combination with an HTTP 3xx Redirection
response where the target URL is in a different domain. In such response where the target URL is in a different domain. In such
scenarios, Signed Token Renewal of a signed JWT SHOULD be communicated scenarios, Signed Token Renewal of a signed JWT <bcp14>SHOULD</bcp14> be communicated
via the query string instead, in a similar fashion to how regular via the query string instead, in a similar fashion to how regular
signed JWTs (outside of Signed Token Renewal) are communicated. Note signed JWTs (outside of Signed Token Renewal) are communicated. Note
the value of the CDNI Signed Token Transport (cdnistt) claim the value of the CDNI Signed Token Transport (cdnistt) claim
MUST be set to 2.</t> <bcp14>MUST</bcp14> be set to 2.</t>
<t>Note that the process described herein only works in cases where bo th the manifest <t>Note that the process described herein only works in cases where bo th the manifest
file and segments constituting the segmented content are delivered fro m file and segments constituting the segmented content are delivered fro m
the same domain. In other words, any redirection between different dom ains needs to be the same domain. In other words, any redirection between different dom ains needs to be
carried out while retrieving the manifest file.</t> carried out while retrieving the manifest file.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="cdni_interfaces" numbered="true" toc="default">
<section anchor="cdni_interfaces" <name>Relationship with CDNI Interfaces</name>
title="Relationship with CDNI Interfaces">
<t>Some of the CDNI Interfaces need enhancements to support URI Signing. <t>Some of the CDNI Interfaces need enhancements to support URI Signing.
A dCDN that supports URI Signing needs to be A dCDN that supports URI Signing needs to be
able to advertise this capability to the uCDN. The uCDN able to advertise this capability to the uCDN. The uCDN
needs to select a dCDN based on such capability when the CSP needs to select a dCDN based on such capability when the CSP
requires access control to enforce its distribution policy via URI requires access control to enforce its distribution policy via URI
Signing. Also, the uCDN needs to be able to distribute via the Signing. Also, the uCDN needs to be able to distribute via the
CDNI Metadata interface the information necessary to allow the CDNI Metadata interface the information necessary to allow the
dCDN to verify a Signed URI. Events that pertain to URI dCDN to verify a Signed URI. Events that pertain to URI
Signing (e.g., request denial or delivery after an access authorization de cision has been made) Signing (e.g., request denial or delivery after an access authorization de cision has been made)
need to be included in the logs communicated through the CDNI Logging need to be included in the logs communicated through the CDNI Logging
interface.</t> interface.</t>
<section anchor="control" numbered="true" toc="default">
<section anchor="control" title="CDNI Control Interface"> <name>CDNI Control Interface</name>
<t>URI Signing has no impact on this interface.</t> <t>URI Signing has no impact on this interface.</t>
</section> </section>
<section anchor="advertisement" numbered="true" toc="default">
<section anchor="advertisement" <name>CDNI Footprint &amp; Capabilities Advertisement Interface</name>
title="CDNI Footprint &amp; Capabilities Advertisement Interface"
>
<t>The CDNI Request Routing: Footprint and Capabilities <t>The CDNI Request Routing: Footprint and Capabilities
Semantics document <xref target="RFC8008"/> defines support for Semantics document <xref target="RFC8008" format="default"/> defines sup
advertising CDNI Metadata capabilities, via CDNI Payload port for
Type. The CDNI Payload Type registered in <xref target="sec.IANA.payload advertising CDNI Metadata capabilities via CDNI Payload
"/> Type. The CDNI Payload Type registered in <xref target="sec.IANA.payload
" format="default"/>
can be used for capability advertisement.</t> can be used for capability advertisement.</t>
</section> </section>
<section anchor="redirection" numbered="true" toc="default">
<section anchor="redirection" <name>CDNI Request Routing Redirection Interface</name>
title="CDNI Request Routing Redirection Interface"> <t>The <xref target="RFC7975" format="default">CDNI Request Routing
<t>The <xref target="RFC7975">CDNI Request Routing
Redirection Interface</xref> describes the recursive request Redirection Interface</xref> describes the recursive request
redirection method. For URI Signing, the uCDN signs the URI redirection method. For URI Signing, the uCDN signs the URI
provided by the dCDN. URI Signing therefore has no impact provided by the dCDN. URI Signing therefore has no impact
on this interface.</t> on this interface.</t>
</section> </section>
<section anchor="metadata" numbered="true" toc="default">
<section anchor="metadata" title="CDNI Metadata Interface"> <name>CDNI Metadata Interface</name>
<t>The <xref target="RFC8006">CDNI Metadata <t>The <xref target="RFC8006" format="default">CDNI Metadata
Interface</xref> describes the CDNI metadata distribution needed to Interface</xref> describes the CDNI Metadata distribution needed to
enable content acquisition and delivery. For URI Signing, a new enable content acquisition and delivery. For URI Signing, a new
CDNI metadata object is specified.</t> CDNI Metadata object is specified.</t>
<t>The UriSigning Metadata object contains information to enable URI <t>The UriSigning Metadata object contains information to enable URI
Signing and verification by a dCDN. The UriSigning properties are Signing and verification by a dCDN. The UriSigning properties are
defined below.</t> defined below.</t>
<ul empty="true" spacing="normal">
<li>
<t>Property: enforce</t>
<ul empty="true" spacing="normal">
<li>
<t><list style="empty"> <dl>
<t>Property: enforce<list style="empty"> <dt>Description:
<t>Description: URI Signing enforcement flag. Specifically, </dt>
this flag indicates if the access to content is subject to URI <dd>URI Signing enforcement flag. Specifically, this flag indic
Signing. URI Signing requires the dCDN to ensure ates if the access to content is subject to URI Signing. URI Signing requires th
that the URI is signed and verified before e dCDN to ensure that the URI is signed and verified before delivering content.
delivering content. Otherwise, the dCDN does not perform Otherwise, the dCDN does not perform verification, regardless of whether or not
verification, regardless of whether or not the URI is signed.</t the URI is signed.
> </dd>
<dt>Type:
<t>Type: Boolean</t> </dt>
<dd>Boolean
<t>Mandatory-to-Specify: No. The default is true.</t> </dd>
</list></t>
<t>Property: issuers<list style="empty"> <dt>Mandatory-to-Specify:
<t>Description: A list of valid Issuers against which </dt>
the Issuer claim in the signed JWT may be cross-referenced.</t> <dd>No. The default is true.
</dd>
<t>Type: Array of Strings</t> </dl>
</li>
</ul>
</li>
<li>
<t>Property: issuers</t>
<ul empty="true" spacing="normal">
<li>
<dl>
<dt>Description:
</dt>
<dd>A list of valid Issuers against which
the Issuer claim in the signed JWT may be cross-referenced.
</dd>
<t>Mandatory-to-Specify: No. The default is an empty <dt>Type:
list. An empty list means that any Issuer in the trusted key st </dt>
ore of issuers is acceptable.</t> <dd>Array of Strings
</list></t> </dd>
<t>Property: package-attribute<list style="empty"> <dt>Mandatory-to-Specify:
<t>Description: The attribute name to use for the URI Signing </dt>
Package.</t> <dd>No. The default is an empty list. An empty list means that any Issuer in
the trusted key store of Issuers is acceptable.
</dd>
</dl>
<t>Type: String</t> </li>
</ul>
</li>
<li>
<t>Property: package-attribute</t>
<ul empty="true" spacing="normal">
<li>
<dl>
<dt>Description:
</dt>
<dd>The attribute name to use for the URI Signing
Package.
</dd>
<t>Mandatory-to-Specify: No. The default is <dt>
"URISigningPackage".</t> Type:
</list></t> </dt>
<dd>String</dd>
<t>Property: jwt-header<list style="empty"> <dt>Mandatory-to-Specify:</dt>
<t>Description: The header part of JWT that is used for <dd>No. The default is
verifying a signed JWT when the JWT token in the URI Signing "URISigningPackage".</dd>
Package does not contain a header part.</t> </dl>
</li>
<t>Type: String</t> </ul>
</li>
<li>
<t>Property: jwt-header</t>
<ul empty="true" spacing="normal">
<li>
<dl>
<dt>Description:
</dt>
<dd>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.
</dd>
<t>Mandatory-to-Specify: No. By default, the header is assumed t <dt>Type:
o be included in the JWT token.</t> </dt>
</list></t> <dd>String
</list></t> </dd>
<dt>Mandatory-to-Specify:
</dt>
<dd>No. By default, the header is assumed to be included
in the JWT token.
</dd>
</dl>
</li>
</ul>
</li>
</ul>
<t>The following is an example of a URI Signing metadata payload with al l default values:</t> <t>The following is an example of a URI Signing metadata payload with al l default values:</t>
<sourcecode type="json"><![CDATA[
<figure>
<artwork><![CDATA[
{ {
"generic-metadata-type": "MI.UriSigning" "generic-metadata-type": "MI.UriSigning"
"generic-metadata-value": {} "generic-metadata-value": {}
} }
]]> ]]></sourcecode>
</artwork>
</figure>
<t>The following is an example of a URI Signing metadata payload with ex plicit values:</t> <t>The following is an example of a URI Signing metadata payload with ex plicit values:</t>
<sourcecode type="json"><![CDATA[
<figure>
<artwork><![CDATA[
{ {
"generic-metadata-type": "MI.UriSigning" "generic-metadata-type": "MI.UriSigning"
"generic-metadata-value": "generic-metadata-value":
{ {
"enforce": true, "enforce": true,
"issuers": ["csp", "ucdn1", "ucdn2"], "issuers": ["csp", "ucdn1", "ucdn2"],
"package-attribute": "usp", "package-attribute": "usp",
"jwt-header": "jwt-header":
{ {
"alg": "ES256", "alg": "ES256",
"kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0" "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0"
} }
} }
} }
]]> ]]></sourcecode>
</artwork>
</figure>
</section> </section>
<section anchor="logging" numbered="true" toc="default">
<section anchor="logging" title="CDNI Logging Interface"> <name>CDNI Logging Interface</name>
<t>For URI Signing, the dCDN reports that enforcement of the <t>For URI Signing, the dCDN reports that enforcement of the
access control was applied to the request for content delivery. When access control was applied to the request for content delivery. When
the request is denied due to enforcement of URI Signing, the reason is the request is denied due to enforcement of URI Signing, the reason is
logged.</t> logged.</t>
<t>The following CDNI Logging field for URI Signing <bcp14>SHOULD</bcp14
<t>The following CDNI Logging field for URI Signing SHOULD be > be
supported in the HTTP Request Logging Record as specified in <xref supported in the HTTP Request Logging Record as specified in "<xref targ
target="RFC7937">CDNI Logging Interface</xref>, et="RFC7937" format="title"/>" <xref target="RFC7937"/>
using the new "cdni_http_request_v2" record-type registered in using the new "cdni_http_request_v2" record-type registered in
<xref target="sec.IANA.record_type.cdni_http_request_v2"/>.</t> <xref target="sec.IANA.record_type.cdni_http_request_v2" format="default
"/>.</t>
<ul spacing="normal">
<li>
<t>s-uri-signing (mandatory): </t>
<t><list style="symbols"> <dl>
<t>s-uri-signing (mandatory): <list> <dt>Format:
<t>format: 3DIGIT</t> </dt>
<dd>3DIGIT
</dd>
<t>field value: this characterises the URI Signing verification <dt>Field value:
performed by the Surrogate on the request. The allowed values </dt>
are registered in <xref target="sec.IANA.field.s-uri-signing.val <dd>this characterizes the URI Signing verification performed by
ues"/>.</t> the Surrogate on the request. The allowed values are registered
in <xref target="sec.IANA.field.s-uri-signing.values"
format="default"/>.
</dd>
<t>occurrence: there MUST be zero or exactly one instance of <dt>Occurrence:
this field.</t> </dt>
</list></t> <dd>there <bcp14>MUST</bcp14> be zero or exactly one instance of
this field.
</dd>
</dl>
<t>s-uri-signing-deny-reason (optional): <list> </li>
<t>format: QSTRING</t> <li>
<t>s-uri-signing-deny-reason (optional): </t>
<t>field value: a string for providing further information in <dl>
case the signed JWT was rejected, e.g., for debugging <dt>Format:
purposes.</t> </dt>
<dd>QSTRING
</dd>
<t>occurrence: there MUST be zero or exactly one instance of <dt>Field value:
this field.</t> </dt>
</list></t> <dd>a string for providing further information in case the signed J
</list></t> WT was rejected, e.g., for debugging purposes.
</dd>
<dt>Occurrence:
</dt>
<dd>there <bcp14>MUST</bcp14> be zero or exactly one instance of
this field.
</dd>
</dl>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="operation" numbered="true" toc="default">
<section anchor="operation" title="URI Signing Message Flow"> <name>URI Signing Message Flow</name>
<t>URI Signing supports both HTTP-based and DNS-based request routing. <t>URI Signing supports both HTTP-based and DNS-based request routing.
<xref target="RFC7519">JSON Web Token (JWT)</xref> defines a <xref target="RFC7519" format="default">JSON Web Token (JWT)</xref> define s a
compact, URL-safe means of representing compact, URL-safe means of representing
claims to be transferred between two parties. The claims in a Signed JWT 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 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 Web Signature (JWS) structure enabling the claims to be digitally
signed or integrity protected with a Message Authentication Code signed or integrity protected with a Message Authentication Code
(MAC).</t> (MAC).</t>
<section anchor="http" numbered="true" toc="default">
<section anchor="http" title="HTTP Redirection"> <name>HTTP Redirection</name>
<t>For HTTP-based request routing, a set of <t>For HTTP-based request routing, a set of
information that is unique to a given end user content request information that is unique to a given end user content request
is included in a Signed JWT, using is included in a Signed JWT, using
key information that is specific to a pair of adjacent CDNI hops (e.g., key information that is specific to a pair of adjacent CDNI hops (e.g.,
between the CSP and the uCDN or between the between the CSP and the uCDN or between the
uCDN and a dCDN). This allows a CDNI hop to ascertain the uCDN and a dCDN). This allows a CDNI hop to ascertain the
authenticity of a given request received from a previous CDNI hop.</t> authenticity of a given request received from a previous CDNI hop.</t>
<t>The URI Signing method <t>The URI Signing method
(assuming HTTP redirection, iterative request routing, and a CDN (assuming HTTP redirection, iterative request routing, and a CDN
path with two CDNs) includes the following steps:</t> path with two CDNs) includes the following steps:</t>
<figure anchor="fig_http_routing">
<figure anchor="fig_http_routing" title="HTTP-based Request Routing with <name>HTTP-Based Request Routing with URI Signing</name>
URI Signing"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
End-User dCDN uCDN CSP End-User dCDN uCDN CSP
| | | | | | | |
| 1.CDNI FCI interface used to | | | 1.CDNI FCI used to | |
| advertise URI Signing capability| | | advertise URI Signing capability | |
| |-------------------&gt;| | | |------------------->| |
| | | | | | | |
| 2.Provides information to verify Signed JWT | | 2.Provides information to verify Signed JWT |
| | |&lt;-------------------| | | |<-------------------|
| | | | | | | |
| 3.CDNI Metadata interface used to| | | 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| | | provide URI Signing attributes| |
| |&lt;-------------------| | | |<-------------------| |
: : : : : : : :
: (Later in time) : : : : (Later in time) : : :
|4.Authorization request | | |4.Authorization request | |
|-------------------------------------------------------------&gt;| |------------------------------------------------------------->|
| | | [Apply distribution | | | [Apply distribution
| | | policy] | | | | policy] |
| | | | | | | |
| | (ALT: Authorization decision) | | (ALT: Authorization decision)
|5.Request is denied | | &lt;Negative&gt; | |5.Request is denied | | <Negative> |
|&lt;-------------------------------------------------------------| |<-------------------------------------------------------------|
| | | | | | | |
|6.CSP provides signed URI | &lt;Positive&gt; | |6.CSP provides Signed URI | <Positive> |
|&lt;-------------------------------------------------------------| |<-------------------------------------------------------------|
| | | | | | | |
|7.Content request | | | |7.Content request | | |
|---------------------------------------->| [Verifiy URI | |---------------------------------------->| [Verify URI |
| | | signature] | | | | signature] |
| | | | | | | |
| | (ALT: Verification result) | | | (ALT: Verification result) |
|8.Request is denied | &lt;Negative&gt;| | |8.Request is denied | <Negative>| |
|&lt;----------------------------------------| | |<----------------------------------------| |
| | | | | | | |
|9.Re-sign URI and redirect to &lt;Positive&gt;| | |9.Re-sign URI and redirect to <Positive>| |
| dCDN (newly signed URI) | | | dCDN (newly Signed URI) | |
|&lt;----------------------------------------| | |<----------------------------------------| |
| | | | | | | |
|10.Content request | | | |10.Content request | | |
|-------------------&gt;| [Verify URI | | |------------------->| [Verify URI | |
| | signature] | | | | signature] | |
| | | | | | | |
| (ALT: Verification result) | | | (ALT: Verification result) | |
|11.Request is denied| &lt;Negative&gt; | | |11.Request is denied| <Negative> | |
|&lt;-------------------| | | |<-------------------| | |
| | | | | | | |
|12.Content delivery | &lt;Positive&gt; | | |12.Content delivery | <Positive> | |
|&lt;-------------------| | | |<-------------------| | |
: : : : : : : :
: (Later in time) : : : : (Later in time) : : :
|13.CDNI Logging interface to include URI Signing information | |13.CDNI Logging interface to include URI Signing information |
| |------------------->| |</artwor k> | |------------------->| |]]></artwor k>
</figure> </figure>
<ol spacing="normal" type="1"><li>Using the CDNI Footprint &amp; Capabil
<t><list style="numbers"> ities Advertisement
<t>Using the CDNI Footprint &amp; Capabilities Advertisement
interface, the dCDN advertises its capabilities interface, the dCDN advertises its capabilities
including URI Signing support to the uCDN.</t> including URI Signing support to the uCDN.</li>
<li>CSP provides to the uCDN the information needed to
<t>CSP provides to the uCDN the information needed to verify Signed URIs from that CSP. For example, this
verify signed URIs from that CSP. For example, this information will include one or more keys used for validation.</li>
information will include one or more keys used for validation.</t> <li>Using the CDNI Metadata interface, the uCDN
<t>Using the CDNI Metadata interface, the uCDN
communicates to a dCDN the information needed to communicates to a dCDN the information needed to
verify signed URIs from the uCDN for the given verify Signed URIs from the uCDN for the given
CSP. For example, this information may include the URI query CSP. For example, this information may include the URI query
string parameter name for the URI Signing Package Attribute string parameter name for the URI Signing Package Attribute
in addition to keys used for validation.</t> in addition to keys used for validation.</li>
<li>When a UA requests a piece of protected content from the CSP,
<t>When a UA requests a piece of protected content from the CSP,
the CSP makes a specific authorization decision for this unique the CSP makes a specific authorization decision for this unique
request based on its local distribution policy.</t> request based on its local distribution policy.</li>
<t>If the authorization decision is negative, the CSP rejects the <li>If the authorization decision is negative, the CSP rejects the
request and sends an error code (e.g., 403 Forbidden) in the HTTP request and sends an error code (e.g., 403 Forbidden) in the HTTP
response.</t> response.</li>
<li>If the authorization decision is positive, the CSP computes a
<t>If the authorization decision is positive, the CSP computes a
Signed JWT that is based on unique parameters of that request and 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 conveys it to the end user as the URI to use to request the
content.</t> content.</li>
<li>On receipt of the corresponding content request, the
<t>On receipt of the corresponding content request, the
uCDN verifies the Signed JWT in the URI using the uCDN verifies the Signed JWT in the URI using the
information provided by the CSP.</t> information provided by the CSP.</li>
<li>If the verification result is negative, the uCDN rejects
<t>If the verification result is negative, the uCDN rejects
the request and sends an error code 403 Forbidden in the HTTP the request and sends an error code 403 Forbidden in the HTTP
response.</t> response.</li>
<li>If the verification result is positive, the uCDN computes a
<t>If the verification result is positive, the uCDN computes a
Signed JWT that is based on unique parameters of that request and 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 provides it to the end user as the URI to use to further request the
content from the dCDN.</t> content from the dCDN.</li>
<li>On receipt of the corresponding content request, the
<t>On receipt of the corresponding content request, the dCDN verifies the Signed JWT in the Signed URI using the
dCDN verifies the Signed JWT in the signed URI using the
information provided by the uCDN in the CDNI information provided by the uCDN in the CDNI
Metadata.</t> Metadata.</li>
<li>If the verification result is negative, the dCDN rejects the
<t>If the verification result is negative, the dCDN rejects the
request and sends an error code 403 Forbidden in the HTTP request and sends an error code 403 Forbidden in the HTTP
response.</t> response.</li>
<li>If the verification result is positive, the dCDN serves the
<t>If the verification result is positive, the dCDN serves the request and delivers the content.</li>
request and delivers the content.</t> <li>At a later time, the dCDN reports logging events that
include URI Signing information.</li>
<t>At a later time, the dCDN reports logging events that </ol>
include URI Signing information.</t>
</list></t>
<t>With HTTP-based request routing, URI Signing matches well the <t>With HTTP-based request routing, URI Signing matches well the
general chain of trust model of CDNI both with symmetric and general chain of trust model of CDNI both with symmetric and
asymmetric keys because the key information only needs to be specific asymmetric keys because the key information only needs to be specific
to a pair of adjacent CDNI hops.</t> to a pair of adjacent CDNI hops.</t>
<t>Note: While using a symmetric shared key is supported, it is <bcp14>N
<t>Note: While using a symmetric shared key is supported, it is NOT RECO OT RECOMMENDED</bcp14>.
MMENDED. See the <xref target="security" format="default">Security Considerations
See the <xref target="security">Security Considerations</xref> section a </xref> about the
bout the
limitations of shared keys.</t> limitations of shared keys.</t>
</section> </section>
<section anchor="dns" title="DNS Redirection"> <section anchor="dns" numbered="true" toc="default">
<name>DNS Redirection</name>
<t>For DNS-based request routing, the CSP and uCDN must <t>For DNS-based request routing, the CSP and uCDN must
agree on a trust model appropriate to the security requirements of the agree on a trust model appropriate to the security requirements of the
CSP's particular content. Use of asymmetric public/private keys allows CSP's particular content. Use of asymmetric public/private keys allows
for unlimited distribution of the public key to dCDNs. for unlimited distribution of the public key to dCDNs.
However, if a shared secret key is required, then the distribution SHOUL D However, if a shared secret key is required, then the distribution <bcp1 4>SHOULD</bcp14>
be performed by the CSP directly.</t> be performed by the CSP directly.</t>
<t>Note: While using a symmetric shared key is supported, it is <bcp14>N
<t>Note: While using a symmetric shared key is supported, it is NOT RECO OT RECOMMENDED</bcp14>.
MMENDED. See the <xref target="security" format="default">Security Considerations
See the <xref target="security">Security Considerations</xref> section a </xref> about the
bout the
limitations of shared keys.</t> limitations of shared keys.</t>
<t>The URI Signing method <t>The URI Signing method
(assuming iterative DNS request routing and a CDN path with two (assuming iterative DNS request routing and a CDN path with two
CDNs) includes the following steps.</t> CDNs) includes the following steps.</t>
<figure anchor="fig_dns_routing" title="DNS-based Request Routing with U <figure anchor="fig_dns_routing">
RI Signing"> <name>DNS-based Request Routing with URI Signing</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
End-User dCDN uCDN CSP End-User dCDN uCDN CSP
| | | | | | | |
| 1.CDNI FCI interface used to | | | 1.CDNI FCI used to | |
| advertise URI Signing capability| | | advertise URI Signing capability | |
| |-------------------&gt;| | | |------------------->| |
| | | | | | | |
| 2.Provides information to verify Signed JWT | | 2.Provides information to verify Signed JWT |
| | |&lt;-------------------| | | |<-------------------|
| 3.CDNI Metadata interface used to| | | 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| | | provide URI Signing attributes| |
| |&lt;-------------------| | | |<-------------------| |
: : : : : : : :
: (Later in time) : : : : (Later in time) : : :
|4.Authorization request | | |4.Authorization request | |
|-------------------------------------------------------------&gt;| |------------------------------------------------------------->|
| | | [Apply distribution | | | [Apply distribution
| | | policy] | | | | policy] |
| | | | | | | |
| | (ALT: Authorization decision) | | (ALT: Authorization decision)
|5.Request is denied | | &lt;Negative&gt; | |5.Request is denied | | <Negative> |
|&lt;-------------------------------------------------------------| |<-------------------------------------------------------------|
| | | | | | | |
|6.Provides signed URI | &lt;Positive&gt; | |6.Provides Signed URI | <Positive> |
|&lt;-------------------------------------------------------------| |<-------------------------------------------------------------|
| | | | | | | |
|7.DNS request | | | |7.DNS request | | |
|----------------------------------------&gt;| | |---------------------------------------->| |
| | | | | | | |
|8.Redirect DNS to dCDN | | |8.Redirect DNS to dCDN | |
|&lt;----------------------------------------| | |<----------------------------------------| |
| | | | | | | |
|9.DNS request | | | |9.DNS request | | |
|-------------------&gt;| | | |------------------->| | |
| | | | | | | |
|10.IP address of Surrogate | | |10.IP address of Surrogate | |
|&lt;-------------------| | | |<-------------------| | |
| | | | | | | |
|11.Content request | | | |11.Content request | | |
|-------------------&gt;| [Verify URI | | |------------------->| [Verify URI | |
| | signature] | | | | signature] | |
| | | | | | | |
| (ALT: Verification result) | | | (ALT: Verification result) | |
|12.Request is denied| &lt;Negative&gt; | | |12.Request is denied| <Negative> | |
|&lt;-------------------| | | |<-------------------| | |
| | | | | | | |
|13.Content delivery | &lt;Positive&gt; | | |13.Content delivery | <Positive> | |
|&lt;-------------------| | | |<-------------------| | |
: : : : : : : :
: (Later in time) : : : : (Later in time) : : :
|14.CDNI Logging interface to report URI Signing information | |14.CDNI Logging interface to report URI Signing information |
| |-------------------&gt;| | | |------------------->| |
</artwork> ]]></artwork>
</figure> </figure>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>Using the CDNI Footprint &amp; Capabilities Advertisement
<t>Using the CDNI Footprint &amp; Capabilities Advertisement
interface, the dCDN advertises its capabilities interface, the dCDN advertises its capabilities
including URI Signing support to the uCDN.</t> including URI Signing support to the uCDN.</li>
<li>CSP provides to the uCDN the information needed to
<t>CSP provides to the uCDN the information needed to
verify Signed JWTs from that CSP. For example, this verify Signed JWTs from that CSP. For example, this
information will include one or more keys used for validation.</t> information will include one or more keys used for validation.</li>
<li>Using the CDNI Metadata interface, the uCDN
<t>Using the CDNI Metadata interface, the uCDN
communicates to a dCDN the information needed to communicates to a dCDN the information needed to
verify Signed JWTs from the CSP (e.g., the URI query verify Signed JWTs from the CSP (e.g., the URI query
string parameter name for the URI Signing Package Attribute). In string parameter name for the URI Signing Package Attribute). In
the case of symmetric shared key, the uCDN MUST NOT share the key the case of symmetric shared key, the uCDN <bcp14>MUST NOT</bcp14> s
with a dCDN.</t> hare the key
with a dCDN.</li>
<t>When a UA requests a piece of protected content from the CSP, <li>When a UA requests a piece of protected content from the CSP,
the CSP makes a specific authorization decision for this unique the CSP makes a specific authorization decision for this unique
request based on its local distribution policy.</t> request based on its local distribution policy.</li>
<li>If the authorization decision is negative, the CSP rejects the
<t>If the authorization decision is negative, the CSP rejects the
request and sends an error code (e.g., 403 Forbidden) in the HTTP request and sends an error code (e.g., 403 Forbidden) in the HTTP
response.</t> response.</li>
<li>If the authorization decision is positive, the CSP computes a
<t>If the authorization decision is positive, the CSP computes a
Signed JWT that is based on unique parameters of that Signed JWT that is based on unique parameters of that
request and includes it in the URI provided to the end user to request and includes it in the URI provided to the end user to
request the content.</t> request the content.</li>
<li>The end user sends a DNS request to the uCDN.</li>
<t>End user sends DNS request to the uCDN.</t> <li>On receipt of the DNS request, the uCDN redirects
the request to the dCDN.</li>
<t>On receipt of the DNS request, the uCDN redirects <li>The end user sends a DNS request to the dCDN.</li>
the request to the dCDN.</t> <li>On receipt of the DNS request, the dCDN responds with
IP address of one of its Surrogates.</li>
<t>End user sends DNS request to the dCDN.</t> <li>On receipt of the corresponding content request, the
<t>On receipt of the DNS request, the dCDN responds with
IP address of one of its Surrogates.</t>
<t>On receipt of the corresponding content request, the
dCDN verifies the Signed JWT in the URI using the dCDN verifies the Signed JWT in the URI using the
information provided by the uCDN in the CDNI information provided by the uCDN in the CDNI
Metadata.</t> Metadata.</li>
<li>If the verification result is negative, the dCDN rejects the
<t>If the verification result is negative, the dCDN rejects the
request and sends an error code 403 Forbidden in the HTTP request and sends an error code 403 Forbidden in the HTTP
response.</t> response.</li>
<li>If the verification result is positive, the dCDN serves the
<t>If the verification result is positive, the dCDN serves the request and delivers the content.</li>
request and delivers the content.</t> <li>At a later time, dCDN reports logging events that
includes URI Signing information.</li>
<t>At a later time, dCDN reports logging events that </ol>
includes URI Signing information.</t>
</list></t>
<t>With DNS-based request routing, URI Signing matches well the <t>With DNS-based request routing, URI Signing matches well the
general chain of trust model of CDNI when used with asymmetric keys general chain of trust model of CDNI when used with asymmetric keys
because the only key information that needs to be distributed across because the only key information that needs to be distributed across
multiple, possibly untrusted, CDNI hops is the public key, which multiple, possibly untrusted, CDNI hops is the public key, which
is generally not confidential.</t> is generally not confidential.</t>
<t>With DNS-based request routing, URI Signing does not match well with the <t>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 general chain of trust model of CDNI when used with symmetric keys
because the symmetric key information needs to be distributed across because the symmetric key information needs to be distributed across
multiple CDNI hops, to CDNs with which the CSP may not have a trust multiple CDNI hops to CDNs with which the CSP may not have a trust
relationship. This raises a security concern for applicability of URI relationship. This raises a security concern for applicability of URI
Signing with symmetric keys in case of DNS-based inter-CDN request Signing with symmetric keys in case of DNS-based inter-CDN request
routing. Due to these flaws, this architecture MUST NOT be implemented.< routing. Due to these flaws, this architecture <bcp14>MUST NOT</bcp14> b
/t> e implemented.</t>
<t>Note: While using a symmetric shared key is supported, it is <bcp14>N
<t>Note: While using a symmetric shared key is supported, it is NOT RECO OT RECOMMENDED</bcp14>.
MMENDED. See the <xref target="security" format="default">Security Considerations
See the <xref target="security">Security Considerations</xref> section a </xref> about the
bout the
limitations of shared keys.</t> limitations of shared keys.</t>
</section> </section>
</section> </section>
<section anchor="sec.IANA" numbered="true" toc="default">
<section anchor="sec.IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<section anchor="sec.IANA.payload" title="CDNI Payload Type"> <section anchor="sec.IANA.payload" numbered="true" toc="default">
<name>CDNI Payload Type</name>
<t>This document requests the registration of the following CDNI <t>IANA has registered the following CDNI
Payload Type under the IANA "CDNI Payload Types" registry:</t> Payload Type under the IANA "CDNI Payload Types" registry:</t>
<table align="center">
<thead>
<tr>
<th align="left">Payload Type</th>
<th align="left">Specification</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">MI.UriSigning</td>
<td align="left">RFC 9246</td>
</tr>
</tbody>
</table>
<texttable> <section anchor="sec.IANA.payload.UriSigning" numbered="true" toc="defau
<ttcol align="left">Payload Type</ttcol> lt">
<ttcol align="left">Specification</ttcol> <name>CDNI UriSigning Payload Type</name>
<c>MI.UriSigning</c> <dl>
<c>RFCthis</c> <dt>Purpose:
</texttable> </dt>
<dd>The purpose of this payload type is to distinguish
UriSigning Metadata interface (MI) objects (and any associated capabil
ity advertisement).
</dd>
<t>[RFC Editor: Please replace RFCthis with the published RFC <dt>Interface:
number for this document.]</t> </dt>
<dd>MI/FCI
</dd>
<section anchor="sec.IANA.payload.UriSigning" title="CDNI UriSigning Pay <dt>Encoding:
load Type"> </dt>
<t>Purpose: The purpose of this payload type is to distinguish <dd>see <xref target="metadata" format="default"/>
UriSigning MI objects (and any associated capability advertisement).</ </dd>
t> </dl>
<t>Interface: MI/FCI</t>
<t>Encoding: see <xref target="metadata"/></t>
</section> </section>
</section> </section>
<section anchor="sec.IANA.logging_record" numbered="true" toc="default">
<section anchor="sec.IANA.logging_record" title="CDNI Logging Record Type" <name>CDNI Logging Record Type</name>
> <t>IANA has registered the following CDNI
<t>This document requests the registration of the following CDNI
Logging record-type under the IANA "CDNI Logging record-types" registry: </t> Logging record-type under the IANA "CDNI Logging record-types" registry: </t>
<table align="center">
<thead>
<tr>
<th align="left">record-types</th>
<th align="left">Reference</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">cdni_http_request_v2</td>
<td align="left">RFC 9246</td>
<td align="left">Extension to CDNI Logging Record version 1 for co
ntent
delivery using HTTP, to include URI Signing Logging fields</td>
</tr>
</tbody>
</table>
<texttable> <section anchor="sec.IANA.record_type.cdni_http_request_v2" numbered="tr
<ttcol align="left">record-types</ttcol> ue" toc="default">
<ttcol align="left">Reference</ttcol> <name>CDNI Logging Record Version 2 for HTTP</name>
<ttcol align="left">Description</ttcol>
<c>cdni_http_request_v2</c>
<c>RFCthis</c>
<c>Extension to CDNI Logging Record version 1 for content
delivery using HTTP, to include URI Signing logging fields</c>
</texttable>
<t>[RFC Editor: Please replace RFCthis with the published RFC
number for this document.]</t>
<section anchor="sec.IANA.record_type.cdni_http_request_v2"
title="CDNI Logging Record Version 2 for HTTP">
<t>The "cdni_http_request_v2" record-type supports all of <t>The "cdni_http_request_v2" record-type supports all of
the fields supported by the "cdni_http_request_v1" the fields supported by the "cdni_http_request_v1"
record-type <xref target="RFC7937"/> plus the record-type <xref target="RFC7937" format="default"/> plus the
two additional fields "s-uri-signing" and two additional fields "s-uri-signing" and
"s-uri-signing-deny-reason", registered by this document in "s-uri-signing-deny-reason", registered by this document in
<xref target="sec.IANA.fields"/>. The name, <xref target="sec.IANA.fields" format="default"/>. The name,
format, field value, and occurence information for the two format, field value, and occurrence information for the two
new fields can be found in new fields can be found in
<xref target="logging"/> of this <xref target="logging" format="default"/> of this
document.</t> document.</t>
</section> </section>
</section> </section>
<section anchor="sec.IANA.fields" numbered="true" toc="default">
<section anchor="sec.IANA.fields" title="CDNI Logging Field Names"> <name>CDNI Logging Field Names</name>
<t>IANA has registered the following CDNI
<t>This document requests the registration of the following CDNI
Logging fields under the IANA "CDNI Logging Field Names" registry:</t> Logging fields under the IANA "CDNI Logging Field Names" registry:</t>
<table align="center">
<texttable> <thead>
<ttcol align="left">Field Name</ttcol> <tr>
<ttcol align="left">Reference</ttcol> <th align="left">Field Name</th>
<th align="left">Reference</th>
<c>s-uri-signing</c> </tr>
<c>RFCthis</c> </thead>
<tbody>
<c>s-uri-signing-deny-reason</c> <tr>
<c>RFCthis</c> <td align="left">s-uri-signing</td>
</texttable> <td align="left">RFC 9246</td>
</tr>
<t>[RFC Editor: Please replace RFCthis with the published RFC <tr>
number for this document.]</t> <td align="left">s-uri-signing-deny-reason</td>
<td align="left">RFC 9246</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="sec.IANA.field.s-uri-signing.values" numbered="true" toc=
<section anchor="sec.IANA.field.s-uri-signing.values" title="CDNI URI Sign "default">
ing Verification Code"> <name>CDNI URI Signing Verification Code</name>
<t>The IANA is requested to create a new "CDNI URI Signing Verification <t>IANA has created a new "CDNI URI Signing Verification Code" subregist
Code" subregistry, in the ry in the
"Content Delivery Networks Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing Verification Code" "Content Delivery Networks Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing Verification Code"
namespace defines the valid values associated with the s-uri-signing CDN namespace defines the valid values associated with the s-uri-signing CDN
I Logging Field. The CDNI URI Signing I Logging field. The CDNI URI Signing
Verification Code is a 3DIGIT value as defined in <xref target="logging" Verification Code is a 3DIGIT value as defined in <xref target="logging"
/>. Additions to the CDNI URI Signing format="default"/>. Additions to the CDNI URI Signing
Verification Code namespace will conform to the "Specification Required" policy as defined in Verification Code namespace will conform to the "Specification Required" policy as defined in
<xref target="RFC8126"/>. Updates to this subregistry are expected to be <xref target="RFC8126" format="default"/>. Updates to this subregistry a
infrequent.</t> re expected to be infrequent.</t>
<table align="center">
<texttable> <thead>
<ttcol align="left">Value</ttcol> <tr>
<ttcol align="left">Reference</ttcol> <th align="left">Value</th>
<ttcol align="left">Description</ttcol> <th align="left">Reference</th>
<th align="left">Description</th>
<c>000</c> </tr>
<c>RFCthis</c> </thead>
<c>No signed JWT verification performed</c> <tbody>
<tr>
<c>200</c> <td align="left">000</td>
<c>RFCthis</c> <td align="left">RFC 9246</td>
<c>Signed JWT verification performed and verified</c> <td align="left">No signed JWT verification performed</td>
</tr>
<c>400</c> <tr>
<c>RFCthis</c> <td align="left">200</td>
<c>Signed JWT verification performed and rejected because of incorrect <td align="left">RFC 9246</td>
signature</c> <td align="left">Signed JWT verification performed and verified</t
d>
</tr>
<tr>
<td align="left">400</td>
<td align="left">RFC 9246</td>
<td align="left">Signed JWT verification performed and rejected be
cause of incorrect signature</td>
</tr>
<tr>
<td align="left">401</td>
<td align="left">RFC 9246</td>
<td align="left">Signed JWT verification performed and rejected be
cause of Issuer enforcement</td>
</tr>
<tr>
<td align="left">402</td>
<td align="left">RFC 9246</td>
<td align="left">Signed JWT verification performed and rejected be
cause of Subject enforcement</td>
</tr>
<tr>
<td align="left">403</td>
<td align="left">RFC 9246</td>
<td align="left">Signed JWT verification performed and rejected be
cause of Audience enforcement</td>
</tr>
<tr>
<td align="left">404</td>
<td align="left">RFC 9246</td>
<td align="left">Signed JWT verification performed and rejected be
cause of Expiration Time enforcement</td>
</tr>
<tr>
<td align="left">405</td>
<td align="left">RFC 9246</td>
<td align="left">Signed JWT verification performed and rejected be
cause of Not Before enforcement</td>
</tr>
<tr>
<td align="left">406</td>
<td align="left">RFC 9246</td>
<td align="left">Signed JWT verification performed and rejected be
cause only one of CDNI Signed Token Transport or CDNI Expiration Time Setting pr
esent</td>
</tr>
<tr>
<td align="left">407</td>
<td align="left">RFC 9246</td>
<td align="left">Signed JWT verification performed and rejected be
cause of JWT ID enforcement</td>
</tr>
<tr>
<td align="left">408</td>
<td align="left">RFC 9246</td>
<td align="left">Signed JWT verification performed and rejected be
cause of Version enforcement</td>
</tr>
<tr>
<td align="left">409</td>
<td align="left">RFC 9246</td>
<td align="left">Signed JWT verification performed and rejected be
cause of Critical Extension enforcement</td>
</tr>
<tr>
<td align="left">410</td>
<td align="left">RFC 9246</td>
<td align="left">Signed JWT verification performed and rejected be
cause of Client IP enforcement</td>
</tr>
<tr>
<td align="left">411</td>
<td align="left">RFC 9246</td>
<td align="left">Signed JWT verification performed and rejected be
cause of URI Container enforcement</td>
</tr>
<tr>
<td align="left">500</td>
<td align="left">RFC 9246</td>
<td align="left">Unable to perform signed JWT verification because
of malformed URI</td>
</tr>
</tbody>
</table>
<c>401</c> </section>
<c>RFCthis</c> <section anchor="sec.IANA.cdnistt" numbered="true" toc="default">
<c>Signed JWT verification performed and rejected because of Issuer en <name>CDNI URI Signing Signed Token Transport</name>
forcement</c> <t>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 <xref target="RFC8126" for
mat="default"/>.
Updates to this subregistry are expected to be infrequent.</t>
<t>The following table defines the initial Enforcement
Information Elements:</t>
<table align="center">
<thead>
<tr>
<th align="left">Value</th>
<th align="left">Description</th>
<th align="left">RFC</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0</td>
<td align="left">Designates token transport is not enabled</td>
<td align="left">RFC 9246</td>
</tr>
<tr>
<td align="left">1</td>
<td align="left">Designates token transport via cookie</td>
<td align="left">RFC 9246</td>
</tr>
<tr>
<td align="left">2</td>
<td align="left">Designates token transport via query string</td>
<td align="left">RFC 9246</td>
</tr>
</tbody>
</table>
<c>402</c> </section>
<c>RFCthis</c> <section anchor="ClaimsReg" numbered="true" toc="default">
<c>Signed JWT verification performed and rejected because of Subject e <name>JSON Web Token Claims Registration</name>
nforcement</c> <t>
This specification registers the following claims
in the IANA "JSON Web Token Claims" registry <xref target="IANA.JWT.C
laims" format="default"/> established by <xref target="RFC7519"/>.
</t>
<section anchor="ClaimsContents" numbered="true" toc="default">
<name>Registry Contents</name>
<c>403</c> <dl spacing="compact">
<c>RFCthis</c> <dt>Claim Name:
<c>Signed JWT verification performed and rejected because of Audience </dt>
enforcement</c> <dd> <tt>cdniv</tt>
</dd>
<dt>Claim Description:
</dt>
<dd>CDNI Claim Set Version
</dd>
<c>404</c> <dt>Change Controller:
<c>RFCthis</c> </dt>
<c>Signed JWT verification performed and rejected because of Expiratio <dd>IESG
n Time enforcement</c> </dd>
<c>405</c> <dt>Specification Document(s):
<c>RFCthis</c> </dt>
<c>Signed JWT verification performed and rejected because of Not Befor <dd><xref target="cdniv_claim" format="default"/> of
e enforcement</c> RFC 9246
</dd>
</dl>
<c>406</c> <dl spacing="compact">
<c>RFCthis</c> <dt>Claim Name:
<c>Signed JWT verification performed and rejected because only one of </dt>
CDNI Signed Token Transport or CDNI Expiration Time Setting present.</c> <dd><tt>cdnicrit</tt>
</dd>
<c>407</c> <dt>Claim Description:
<c>RFCthis</c> </dt>
<c>Signed JWT verification performed and rejected because of JWT ID en <dd>CDNI Critical Claims Set
forcement</c> </dd>
<dt>Change Controller:
</dt>
<dd>IESG
</dd>
<dt>Specification Document(s):
</dt>
<dd><xref target="cdnicrit_claim" format="default"/>
of RFC 9246
</dd>
<c>408</c> </dl>
<c>RFCthis</c>
<c>Signed JWT verification performed and rejected because of Version e
nforcement</c>
<c>409</c> <dl spacing="compact">
<c>RFCthis</c> <dt>Claim Name:
<c>Signed JWT verification performed and rejected because of Critical </dt>
Extension enforcement</c> <dd><tt>cdniip</tt>
</dd>
<c>410</c> <dt>Claim Description:
<c>RFCthis</c> </dt>
<c>Signed JWT verification performed and rejected because of Client IP <dd>CDNI IP Address
enforcement</c> </dd>
<c>411</c> <dt>Change Controller:
<c>RFCthis</c> </dt>
<c>Signed JWT verification performed and rejected because of URI Conta <dd>IESG
iner enforcement</c> </dd>
<c>500</c> <dt>Specification Document(s):
<c>RFCthis</c> </dt>
<c>Unable to perform signed JWT verification because of malformed URI< <dd><xref target="cdniip_claim" format="default"/> of
/c> RFC 9246
</texttable> </dd>
</dl>
<t>[RFC Editor: Please replace RFCthis with the published RFC <dl spacing="compact">
number for this document.]</t> <dt>Claim Name:
</section> </dt>
<dd><tt>cdniuc</tt>
</dd>
<section anchor="sec.IANA.cdnistt" <dt>Claim Description:
title="CDNI URI Signing Signed Token Transport"> </dt>
<t>The IANA is requested to create a new "CDNI URI Signing <dd>CDNI URI Container
Signed Token Transport" subregistry in the "Content </dd>
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 <xref target="RFC8126"/>.
Updates to this subregistry are expected to be infrequent.</t>
<t>The following table defines the initial Enforcement <dt>Change Controller:
Information Elements:</t> </dt>
<texttable> <dd>IESG
<ttcol align='left'>Value</ttcol> </dd>
<ttcol align='left'>Description</ttcol>
<ttcol align='left'>RFC</ttcol>
<c>0</c> <dt>Specification Document(s):
<c>Designates token transport is not enabled</c> </dt>
<c>RFCthis</c> <dd><xref target="cdniuc_claim" format="default"/> of
RFC 9246
</dd>
</dl>
<c>1</c> <dl spacing="compact">
<c>Designates token transport via cookie</c> <dt>Claim Name:
<c>RFCthis</c> </dt>
<dd><tt>cdniets</tt>
</dd>
<c>2</c> <dt>Claim Description:
<c>Designates token transport via query string</c> </dt>
<c>RFCthis</c> <dd>CDNI Expiration Time Setting for Signed Token Renewal
</texttable> </dd>
<t>[RFC Editor: Please replace RFCthis with the published RFC <dt>Change Controller:
number for this document.]</t> </dt>
</section> <dd>IESG
</dd>
<section anchor="ClaimsReg" title="JSON Web Token Claims Registration"> <dt>Specification Document(s):
</dt>
<dd><xref target="cdniets_claim" format="default"/>
of RFC 9246
</dd>
</dl>
<t> <dl spacing="compact">
This specification registers the following Claims <dt>Claim Name:
in the IANA "JSON Web Token Claims" registry </dt>
<xref target="IANA.JWT.Claims"/> <dd><tt>cdnistt</tt>
established by <xref target="RFC7519"/>. </dd>
</t>
<section anchor='ClaimsContents' title='Registry Contents'> <dt>Claim Description:
</dt>
<dd>CDNI Signed Token Transport Method for Signed Token
Renewal
</dd>
<t> <dt>Change Controller:
<?rfc subcompact="yes"?> </dt>
<list style="symbols"> <dd>IESG
<t>Claim Name: <spanx style="verb">cdniv</spanx></t> </dd>
<t>Claim Description: CDNI Claim Set Version</t>
<t>Change Controller: IESG</t>
<t>Specification Document(s): <xref target="cdniv_claim"/> of [[ t
his specification ]]</t>
</list>
</t>
<?rfc subcompact="no"?>
<t> <dt>Specification Document(s):
<?rfc subcompact="yes"?> </dt>
<list style="symbols"> <dd><xref target="cdnistt_claim" format="default"/>
<t>Claim Name: <spanx style="verb">cdnicrit</spanx></t> of RFC 9246
<t>Claim Description: CDNI Critical Claims Set</t> </dd>
<t>Change Controller: IESG</t>
<t>Specification Document(s): <xref target="cdnicrit_claim"/> of [
[ this specification ]]</t>
</list>
</t>
<?rfc subcompact="no"?>
<t> </dl>
<?rfc subcompact="yes"?>
<list style="symbols">
<t>Claim Name: <spanx style="verb">cdniip</spanx></t>
<t>Claim Description: CDNI IP Address</t>
<t>Change Controller: IESG</t>
<t>Specification Document(s): <xref target="cdniip_claim"/> of [[
this specification ]]</t>
</list>
</t>
<?rfc subcompact="no"?>
<t> <dl spacing="compact">
<?rfc subcompact="yes"?> <dt>Claim Name:
<list style="symbols"> </dt>
<t>Claim Name: <spanx style="verb">cdniuc</spanx></t> <dd><tt>cdnistd</tt>
<t>Claim Description: CDNI URI Container</t> </dd>
<t>Change Controller: IESG</t>
<t>Specification Document(s): <xref target="cdniuc_claim"/> of [[
this specification ]]</t>
</list>
</t>
<?rfc subcompact="no"?>
<t> <dt>Claim Description:
<?rfc subcompact="yes"?> </dt>
<list style="symbols"> <dd>CDNI Signed Token Depth
<t>Claim Name: <spanx style="verb">cdniets</spanx></t> </dd>
<t>Claim Description: CDNI Expiration Time Setting for Signed Toke
n Renewal</t>
<t>Change Controller: IESG</t>
<t>Specification Document(s): <xref target="cdniets_claim"/> of [[
this specification ]]</t>
</list>
</t>
<?rfc subcompact="no"?>
<t> <dt>Change Controller:
<?rfc subcompact="yes"?> </dt>
<list style="symbols"> <dd>IESG
<t>Claim Name: <spanx style="verb">cdnistt</spanx></t> </dd>
<t>Claim Description: CDNI Signed Token Transport Method for Signe
d Token Renewal</t>
<t>Change Controller: IESG</t>
<t>Specification Document(s): <xref target="cdnistt_claim"/> of [[
this specification ]]</t>
</list>
</t>
<?rfc subcompact="no"?>
<t> <dt>Specification Document(s):
<?rfc subcompact="yes"?> </dt>
<list style="symbols"> <dd><xref target="cdnistd_claim" format="default"/>
<t>Claim Name: <spanx style="verb">cdnistd</spanx></t> of RFC 9246
<t>Claim Description: CDNI Signed Token Depth</t> </dd>
<t>Change Controller: IESG</t> </dl>
<t>Specification Document(s): <xref target="cdnistd_claim"/> of [[
this specification ]]</t>
</list>
</t>
<?rfc subcompact="no"?>
</section> </section>
</section> </section>
<section anchor="expertreview" numbered="true" toc="default">
<section anchor="expertreview" title="Expert Review Guidance"> <name>Expert Review Guidance</name>
<t>Generally speaking, we should determine the registration has a ration al justification <t>Generally speaking, we should determine the registration has a ration al justification
and does not duplicate a previous registration. Early assignment should be permissible as long 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 as there is a reasonable expectation that the specification will become formalized. Expert
Reviewers should be empowered to make determinations, but generally spe aking they should allow Reviewers should be empowered to make determinations, but generally spe aking they should allow
new claims that do not otherwise introduce conflicts with implementatio n or things that may lead new claims that do not otherwise introduce conflicts with implementatio n or things that may lead
to confusion. They should also follow the guidelines of <xref target=" RFC8126"/> Section 5 when sensible.</t> to confusion. They should also follow the guidelines of <xref target=" RFC8126" sectionFormat="of" section="5" format="default"/> when sensible.</t>
</section> </section>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t>This document describes the concept of URI Signing and how it can be <t>This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of used to provide access authorization in the case of
CDNI. The primary goal of URI Signing is to make sure that only CDNI. The primary goal of URI Signing is to make sure that only
authorized UAs are able to access the content, with a authorized UAs are able to access the content, with a
CSP being able to authorize every individual request. It CSP being able to authorize every individual request. It
should be noted that URI Signing is not a content protection scheme; if 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 a CSP wants to protect the content itself, other mechanisms, such as
DRM, are more appropriate.</t> DRM, are more appropriate.</t>
<t>CDNI URI Signing Signed Tokens leverage JSON Web Tokens and thus, guide
<t>CDNI URI Signing Signed Tokens leverage JSON Web Tokens and thus guidel lines in <xref target="RFC8725" format="default"/>
ines in <xref target="RFC8725"/>
are applicable for all JWT interactions.</t> are applicable for all JWT interactions.</t>
<t>In general, it holds that the level of protection against <t>In general, it holds that the level of protection against
illegitimate access can be increased by including more claims illegitimate access can be increased by including more claims
in the signed JWT. The current version of this document in the signed JWT. The current version of this document
includes claims for enforcing Issuer, Client IP Address, Not Before time, includes claims for enforcing Issuer, Client IP Address, Not Before time,
and Expiration Time, and Expiration Time;
however this list can be extended with other, more complex, attributes however, this list can be extended with other more complex attributes
that are able to provide some form of protection against some of the that are able to provide some form of protection against some of the
vulnerabilities highlighted below.</t> vulnerabilities highlighted below.</t>
<t>That said, there are a number of aspects that limit the level of <t>That said, there are a number of aspects that limit the level of
security offered by URI Signing and that anybody implementing URI security offered by URI Signing and that anybody implementing URI
Signing should be aware of.</t> Signing should be aware of.</t>
<t><list style="symbols"> <dl>
<t>Replay attacks: A (valid) Signed URI may be used to perform <dt>Replay attacks:
replay attacks. The vulnerability to replay attacks can be reduced </dt>
by picking a relatively short window between the Not Before time and E <dd>A (valid) Signed URI may be used to perform replay attacks. The
xpiration Time vulnerability to replay attacks can be reduced by picking a
attributes, although this is limited by the fact that any HTTP-based relatively short window between the Not Before time and Expiration
request needs a window of at least a couple of seconds to prevent Time attributes, although this is limited by the fact that any
sudden network issues from denying legitimate UAs access to HTTP-based request needs a window of at least a couple of seconds to
the content. One may also reduce exposure to replay attacks by prevent sudden network issues from denying legitimate UAs access to
including a unique one-time access ID via the JWT ID attribute (jti cl the content. One may also reduce exposure to replay attacks by
aim). Whenever the including a unique one-time access ID via the JWT ID attribute (jti
dCDN receives a request with a given unique ID, it claim). Whenever the dCDN receives a request with a given unique ID,
adds that ID to the list of 'used' IDs. In the case an 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, illegitimate UA tries to use the same URI through a replay attack,
the dCDN can deny the request based on the already-used the dCDN can deny the request based on the already used access
access ID. This list should be kept bounded. A reasonable approach ID. This list should be kept bounded. A reasonable approach would be
would be to expire the entries based on the exp claim value. If no exp to expire the entries based on the exp claim value. If no exp claim
claim is present is present, then a simple Least Recently Used (LRU) cache could be
then a simple LRU could be used, however this would allow values to ev used; however, this would allow values to eventually be reused.
entually be reused.</t>
<t>Illegitimate clients behind a NAT: In cases where there are </dd>
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 illegitim
ate 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.<
/t>
</list></t>
<t>A shared key distribured between CSP and uCDN is more likely to be <dt>Illegitimate clients behind a NAT:
</dt>
<dd>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.
</dd>
</dl>
<t>A shared key distributed between CSP and uCDN is more likely to be
compromised. Since this key can be used compromised. Since this key can be used
to legitimately sign a URL for content access authorization, it is to legitimately sign a URL for content access authorization, it is
important to know the implications of a compromised shared key. While important to know the implications of a compromised shared key. While
using a shared key scheme can be convenient, this architecture is NOT using a shared key scheme can be convenient, this architecture is <bcp14>N
RECOMMENDED due to the risks associated. It is included for legacy OT
RECOMMENDED</bcp14> due to the risks associated. It is included for legacy
feature parity and is highly discouraged in new implementations.</t> feature parity and is highly discouraged in new implementations.</t>
<t>If a shared key usable for signing is compromised, an attacker <t>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 can use it to perform a denial-of-service attack by forcing the CDN to
evaluate prohibitively expensive regular expressions embedded in a evaluate prohibitively expensive regular expressions embedded in a
URI Container (cdniuc) claim. As a result, compromised keys should be time ly revoked URI Container (cdniuc) claim. As a result, compromised keys should be time ly revoked
in order to prevent exploitation.</t> in order to prevent exploitation.</t>
<t>The URI Container (cdniuc) claim can be given a wildcard value. This, c ombined <t>The URI Container (cdniuc) claim can be given a wildcard value. This, c ombined
with the fact that it is the only mandatory claim, means you can effective ly make with the fact that it is the only mandatory claim, means you can effective ly make
a skeleton key. Doing this does not sufficiently limit the scope of the JW T and is a skeleton key. Doing this does not sufficiently limit the scope of the JW T and is
NOT RECOMMENDED. The only way to prevent such a key from being used after it is <bcp14>NOT RECOMMENDED</bcp14>. The only way to prevent such a key from be ing used after it is
distributed is to revoke the signing key so it no longer validates.</t> distributed is to revoke the signing key so it no longer validates.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Privacy"> <name>Privacy</name>
<t>The privacy protection concerns described in <xref <t>The privacy protection concerns described in "<xref target="RFC7937" fo
target="RFC7937">CDNI Logging Interface</xref> apply when rmat="title"/>" <xref target="RFC7937" /> apply when
the client's IP address (cdniip) or Subject (sub) is embedded in the Signe d URI. the client's IP address (cdniip) or Subject (sub) is embedded in the Signe d URI.
For this reason, the mechanism described in <xref For this reason, the mechanism described in <xref target="jwt_profile" for
target="jwt_profile"/> encrypts the Client IP or Subject before mat="default"/> encrypts the Client IP or Subject before
including it in the URI Signing Package (and thus the URL itself).</t> including it in the URI Signing Package (and thus the URL itself).</t>
</section> </section>
<section title="Acknowledgements">
<t>The authors would like to thank the following people for their
contributions in reviewing this document and providing feedback: Scott
Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan York,
Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana Oprescu,
Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris Lemmons.</t>
</section>
<section title="Contributors">
<t>In addition, the authors would also like to make special mentions for c
ertain
people who contributed significant sections to this document.</t>
<t><list style="symbols">
<t>Matt Caulfield provided content for the CDNI Metadata Interface
section.</t>
<t>Emmanuel Thomas provided content for HTTP Adaptive Streaming.</t>
<t>Matt Miller provided consultation on JWT usage as well as code to
generate working JWT examples.</t>
</list></t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include='reference.RFC.2119'?> <name>References</name>
<references>
<?rfc include='reference.RFC.8174'?> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.7937'?> FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.7230'?> FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.8259'?> FC.7937.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.7519'?> FC.7230.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.7516'?> FC.8259.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.8006'?> FC.7519.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.6920'?> FC.7516.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.8126'?> FC.8006.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.0791'?> FC.6920.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.3986'?> FC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.5952'?> FC.0791.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.6265'?> FC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.6707'?> FC.5952.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.5905'?> FC.6265.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.6570'?> FC.6707.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<reference anchor="POSIX.1" target="http://pubs.opengroup.org/onlinepubs/9 FC.5905.xml"/>
699919799/"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.6570.xml"/>
<title>The Open Group Base Specifications Issue 7</title>
<author surname="IEEE"/>
<date day="31" month="Jan" year="2018"/>
</front>
<seriesInfo name="IEEE Std" value="1003.1 2018 Edition"/>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.7336'?>
<?rfc include='reference.RFC.7337'?>
<?rfc include='reference.RFC.8008'?>
<?rfc include='reference.RFC.7975'?>
<?rfc include='reference.RFC.6983'?>
<?rfc include='reference.RFC.7517'?>
<?rfc include='reference.RFC.8216'?>
<?rfc include='reference.RFC.8725'?> <reference anchor="POSIX.1" target="https://pubs.opengroup.org/onlinepubs/969991
9799/">
<front>
<title>IEEE Standard for Information Technology -- Portable Operatin
g System Interface (POSIX(TM)) Base Specifications, Issue 7</title>
<author>
<organization>The Open Group
</organization>
</author>
<date month="January" year="2018"/>
</front>
<seriesInfo name="IEEE Std" value="1003.1-2017"/>
<refcontent>(Revision of IEEE Std 1003.1-2008)
</refcontent>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7336.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7337.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8008.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7975.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6983.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7517.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8216.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8725.xml"/>
<reference anchor="IANA.JWT.Claims" target="http://www.iana.org/assignment <reference anchor="IANA.JWT.Claims" target="https://www.iana.org/assignm
s/jwt"> ents/jwt">
<front> <front>
<title>JSON Web Token Claims</title> <title>JSON Web Token (JWT)</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="MPEG-DASH" target="http://www.iso.org/standard/65274.ht <reference anchor="MPEG-DASH" target="https://www.iso.org/standard/79329
ml"> .html">
<front> <front>
<title>Information technology -- Dynamic adaptive streaming <title>Information technology -- Dynamic adaptive streaming over HTT
over HTTP (DASH) -- Part 1: Media presentation description P (DASH) -- Part 1: Media presentation description and segment formats</title>
and segment format</title> <author>
<author> <organization>ISO</organization>
<organization>ISO</organization> </author>
</author> <date month="December" year="2019"/>
<date month="05" year="2014"/> </front>
</front> <seriesInfo name="ISO/IEC" value="23009-1:2019"/>
<seriesInfo name="ISO/IEC" value="23009-1:2014"/> <seriesInfo name="Edition" value="4"/>
<seriesInfo name="Edition" value="2"/> </reference>
</reference>
</references>
</references> </references>
<section anchor="sup_example" numbered="true" toc="default">
<section title="Signed URI Package Example" anchor="sup_example"> <name>Signed URI Package Example</name>
<t>This section contains three examples of token usage: a simple example w ith only the <t>This section contains three examples of token usage: a simple example w ith only the
required claim present, a complex example which demonstrates the full JWT claims set, required claim present, a complex example that demonstrates the full JWT c laims set,
including an encrypted Client IP Address (cdniip), and one that uses a Sig ned Token Renewal.</t> including an encrypted Client IP Address (cdniip), and one that uses a Sig ned Token Renewal.</t>
<t>Note: All of the examples have empty space added to improve formatting
<t>Note: All of the examples have whitespace added to improve formatting a and readability,
nd readability,
but are not present in the generated content.</t> but are not present in the generated content.</t>
<t>All examples use the following JWK Set <xref target="RFC7517" format="d
<t>All examples use the following JWK Set <xref target="RFC7517"/>:</t> efault"/>:</t>
<figure><artwork><![CDATA[ <sourcecode type="json"><![CDATA[
{ "keys": [ { "keys": [
{ {
"kty": "EC", "kty": "EC",
"kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0",
"use": "sig", "use": "sig",
"alg": "ES256", "alg": "ES256",
"crv": "P-256", "crv": "P-256",
"x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8",
"y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA" "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA"
}, },
skipping to change at line 1761 skipping to change at line 1880
"d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M" "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M"
}, },
{ {
"kty": "oct", "kty": "oct",
"kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998", "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998",
"use": "enc", "use": "enc",
"alg": "A128GCM", "alg": "A128GCM",
"k": "4uFxxV7fhNmrtiah2d1fFg" "k": "4uFxxV7fhNmrtiah2d1fFg"
} }
]} ]}
]]></artwork></figure> ]]></sourcecode>
<t>Note: They are the public signing key, the private signing
<t>Note: They are the public signing key, the private signing key, and the shared secret encryption key, respectively. The public and pri
key, and the shared secret enctyption key, respectively. The public and pri vate signing
vate signing
keys have the same fingerprint and only vary by the 'd' parameter that is m issing from the keys have the same fingerprint and only vary by the 'd' parameter that is m issing from the
public signing key.</t> public signing key.</t>
<section anchor="simple_example" numbered="true" toc="default">
<section title="Simple Example" anchor="simple_example"> <name>Simple Example</name>
<t> <t>
This example is a simple common usage example containing This example is a simple common usage example containing
a minimal subset of claims that the authors find most useful. a minimal subset of claims that the authors find most useful.
</t> </t>
<t> <t>
The JWT Claim Set before signing: The JWT Claim Set before signing:
</t> </t>
<t> <t>
Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the URL Segment form Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the URL Segment form
(<xref target="RFC6920"/> Section 5) of "http://cdni.example/foo/bar". (<xref target="RFC6920" sectionFormat="of" section="5" format="default "/>) of "http://cdni.example/foo/bar".
</t> </t>
<figure><artwork><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"exp": 1646867369, "exp": 1646867369,
"iss": "uCDN Inc", "iss": "uCDN Inc",
"cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" "cdniuc":
"hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY"
} }
]]></artwork></figure> ]]></sourcecode>
<t> <t>
The signed JWT: The signed JWT:
</t> </t>
<sourcecode><![CDATA[
<figure><artwork><![CDATA[
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE2NDY4NjczNjksImlzcyI6InVDRE4gS dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE2NDY4NjczNjksImlzcyI6InVDRE4gS
W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV
wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.TaNlJM3D96i_9J9XvlICO6FUIDFTqt3E2Y wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.TaNlJM3D96i_9J9XvlICO6FUIDFTqt3E2Y
JkEUOLfcH0b89wYRKTbJ9Yj6h_GRgSoZoQO0cps3yUPcWGK3smCw JkEUOLfcH0b89wYRKTbJ9Yj6h_GRgSoZoQO0cps3yUPcWGK3smCw
]]></artwork></figure> ]]></sourcecode>
</section> </section>
<section anchor="complex_example" numbered="true" toc="default">
<section title="Complex Example" anchor="complex_example"> <name>Complex Example</name>
<t> <t>
This example uses all fields except for those dealing This example uses all fields except for those dealing
with Signed Token Renewal, including Client IP Address (cdniip) and Su with Signed Token Renewal, including Client IP Address (cdniip) and Su
bject (sub) which are bject (sub), which are
encrpyted. This significantly increases the size of the signed encrypted. This significantly increases the size of the signed
JWT token. JWT token.
</t> </t>
<t> <t>
JWE for Client IP Address (cdniip) of [2001:db8::1/32]: JWE for Client IP Address (cdniip) of [2001:db8::1/32]:
</t> </t>
<sourcecode><![CDATA[
<figure><artwork><![CDATA[
eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST
NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..aUDDFEQBIc3nWjOb.bGXWT NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..aUDDFEQBIc3nWjOb.bGXWT
HPkntmPCKn0pPPNEQ.iyTttnFybO2YBLqwl_YSjA HPkntmPCKn0pPPNEQ.iyTttnFybO2YBLqwl_YSjA
]]></artwork></figure> ]]></sourcecode>
<t> <t>
JWE for Subject (sub) of "UserToken": JWE for Subject (sub) of "UserToken":
</t> </t>
<sourcecode><![CDATA[
<figure><artwork><![CDATA[
eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST
NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..CLAu80xclc8Bp-Ui.6P1A3 NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..CLAu80xclc8Bp-Ui.6P1A3
F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g
]]></artwork></figure> ]]></sourcecode>
<t> <t>
The JWT Claim Set before signing: The JWT Claim Set before signing:
</t> </t>
<sourcecode type="json"><![CDATA[
<figure><artwork><![CDATA[
{ {
"aud": "dCDN LLC", "aud": "dCDN LLC",
"sub": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4 "sub": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4
QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..CLAu80xclc8B QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..CLAu80xclc8B
p-Ui.6P1A3F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g", p-Ui.6P1A3F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g",
"cdniip": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XY "cdniip": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XY
mp4QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..aUDDFEQBI mp4QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..aUDDFEQBI
c3nWjOb.bGXWTHPkntmPCKn0pPPNEQ.iyTttnFybO2YBLqwl_YSjA", c3nWjOb.bGXWTHPkntmPCKn0pPPNEQ.iyTttnFybO2YBLqwl_YSjA",
"cdniv": 1, "cdniv": 1,
"exp": 1646867369, "exp": 1646867369,
"iat": 1646694569, "iat": 1646694569,
"iss": "uCDN Inc", "iss": "uCDN Inc",
"jti": "5DAafLhZAfhsbe", "jti": "5DAafLhZAfhsbe",
"nbf": 1646780969, "nbf": 1646780969,
"cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png" "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png"
} }
]]></artwork></figure> ]]></sourcecode>
<t> <t>
The signed JWT: The signed JWT:
</t> </t>
<sourcecode><![CDATA[
<figure><artwork><![CDATA[
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5Smxib dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5Smxib
U1pT2lKQk1USTRSME5OSWl3aVlXeG5Jam9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA U1pT2lKQk1USTRSME5OSWl3aVlXeG5Jam9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA
0UWtNelpGQjFTVE5rTWpSclVESm9ablp2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T 0UWtNelpGQjFTVE5rTWpSclVESm9ablp2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T
0NKOS4uQ0xBdTgweGNsYzhCcC1VaS42UDFBM0Y2aXAyRHYuQ29oZHRMTHBnQm5UdlJ 0NKOS4uQ0xBdTgweGNsYzhCcC1VaS42UDFBM0Y2aXAyRHYuQ29oZHRMTHBnQm5UdlJ
KUUNGdXotZyIsImNkbmlpcCI6ImV5SmxibU1pT2lKQk1USTRSME5OSWl3aVlXeG5Ja KUUNGdXotZyIsImNkbmlpcCI6ImV5SmxibU1pT2lKQk1USTRSME5OSWl3aVlXeG5Ja
m9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA0UWtNelpGQjFTVE5rTWpSclVESm9ablp m9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA0UWtNelpGQjFTVE5rTWpSclVESm9ablp
2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T0NKOS4uYVVEREZFUUJJYzNuV2pPYi5iR 2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T0NKOS4uYVVEREZFUUJJYzNuV2pPYi5iR
1hXVEhQa250bVBDS24wcFBQTkVRLml5VHR0bkZ5Yk8yWUJMcXdsX1lTakEiLCJjZG5 1hXVEhQa250bVBDS24wcFBQTkVRLml5VHR0bkZ5Yk8yWUJMcXdsX1lTakEiLCJjZG5
pdiI6MSwiZXhwIjoxNjQ2ODY3MzY5LCJpYXQiOjE2NDY2OTQ1NjksImlzcyI6InVDR pdiI6MSwiZXhwIjoxNjQ2ODY3MzY5LCJpYXQiOjE2NDY2OTQ1NjksImlzcyI6InVDR
E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE2NDY3ODA5NjksImN E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE2NDY3ODA5NjksImN
kbml1YyI6InJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL1swLTlde kbml1YyI6InJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL1swLTlde
zN9XFwucG5nIn0.IjmVX0uD5MYqArc-M08uEsEeoDQn8kuYXZ9HGHDmDDxsHikT0c8 zN9XFwucG5nIn0.IjmVX0uD5MYqArc-M08uEsEeoDQn8kuYXZ9HGHDmDDxsHikT0c8
jcX8xYD0z3LzQclMG65i1kT2sRbZ7isUw8w jcX8xYD0z3LzQclMG65i1kT2sRbZ7isUw8w
]]></artwork></figure> ]]></sourcecode>
</section> </section>
<section anchor="token_renewal_example" numbered="true" toc="default">
<section title="Signed Token Renewal Example" anchor="token_renewal_exampl <name>Signed Token Renewal Example</name>
e">
<t> <t>
This example uses fields for Signed Token Renewal. This example uses fields for Signed Token Renewal.
</t> </t>
<t> <t>
The JWT Claim Set before signing: The JWT Claim Set before signing:
</t> </t>
<sourcecode type="json"><![CDATA[
<figure><artwork><![CDATA[
{ {
"cdniets": 30, "cdniets": 30,
"cdnistt": 1, "cdnistt": 1,
"cdnistd": 2, "cdnistd": 2,
"exp": 1646867369, "exp": 1646867369,
"cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts"
} }
]]></artwork></figure> ]]></sourcecode>
<t> <t>
The signed JWT: The signed JWT:
</t> </t>
<sourcecode><![CDATA[
<figure><artwork><![CDATA[
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua
XN0ZCI6MiwiZXhwIjoxNjQ2ODY3MzY5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R XN0ZCI6MiwiZXhwIjoxNjQ2ODY3MzY5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R
uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.tlPvoKw3BCClw4Lx9 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.tlPvoKw3BCClw4Lx9
PQu7MK6b2IN55ZoCPSaxovGK0zS53Wpb1MbJBow7G8LiGR39h6-2Iq7PWUSr3MdTIz PQu7MK6b2IN55ZoCPSaxovGK0zS53Wpb1MbJBow7G8LiGR39h6-2Iq7PWUSr3MdTIz
HYw HYw
]]></artwork></figure> ]]></sourcecode>
<t> <t>
Once the server verifies the signed JWT it will return a Once the server verifies the signed JWT it will return a
new signed JWT with an updated expiry time (exp) as shown new signed JWT with an updated Expiry Time (exp) as shown
below. Note the expiry time is increased by the expiration below. Note the Expiry Time is increased by the expiration
time setting (cdniets) value. time setting (cdniets) value.
</t> </t>
<t> <t>
The JWT Claim Set before signing: The JWT Claim Set before signing:
</t> </t>
<sourcecode type="json"><![CDATA[
<figure><artwork><![CDATA[
{ {
"cdniets": 30, "cdniets": 30,
"cdnistt": 1, "cdnistt": 1,
"cdnistd": 2, "cdnistd": 2,
"exp": 1646867399, "exp": 1646867399,
"cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts"
} }
]]></artwork></figure> ]]></sourcecode>
<t> <t>
The signed JWT: The signed JWT:
</t> </t>
<sourcecode><![CDATA[
<figure><artwork><![CDATA[
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua
XN0ZCI6MiwiZXhwIjoxNjQ2ODY3Mzk5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R XN0ZCI6MiwiZXhwIjoxNjQ2ODY3Mzk5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R
uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.ivY5d_fKGd-OHTpUs uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.ivY5d_fKGd-OHTpUs
8uJUrnHvt-rduzu5H4zM7167pUUAghub53FqDQ5G16jRYX2sY73mA_uLpYDdb-CPts 8uJUrnHvt-rduzu5H4zM7167pUUAghub53FqDQ5G16jRYX2sY73mA_uLpYDdb-CPts
8FA 8FA
]]></artwork></figure> ]]></sourcecode>
</section> </section>
</section> </section>
</back> <section numbered="false" toc="default">
</rfc> <name>Acknowledgements</name>
<t>The authors would like to thank the following people for their
contributions in reviewing this document and providing feedback: <contact
fullname="Scott
Leibrand"/>, <contact fullname="Kevin Ma"/>, <contact fullname="Ben Niven-
Jenkins"/>, <contact fullname="Thierry Magnien"/>, <contact fullname="Dan York"/
>,
<contact fullname="Bhaskar Bhupalam"/>, <contact fullname="Matt Caulfield"
/>, <contact fullname="Samuel Rajakumar"/>, <contact fullname="Iuniana Oprescu"/
>,
<contact fullname="Leif Hedstrom"/>, <contact fullname="Gancho Tenev"/>, <
contact fullname="Brian Campbell"/>, and <contact fullname="Chris Lemmons"/>.</t
>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<t>In addition, the authors would also like to make special mentions for c
ertain
people who contributed significant sections to this document.</t>
<ul spacing="normal">
<li><t><contact fullname= "Matt Caulfield"/> provided content for <xref
target="metadata"/>, "CDNI Metadata Interface".</t></li>
<li><t><contact fullname="Emmanuel Thomas"/> provided content for HTTP A
daptive Streaming.</t></li>
<li><t><contact fullname="Matt Miller"/> provided consultation on JWT us
age as well as code to generate working JWT examples.</t></li>
</ul>
</section> </back> </rfc>
 End of changes. 370 change blocks. 
1221 lines changed or deleted 1364 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/