<?xml version="1.0"encoding="US-ASCII"?>encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="4"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-cdni-uri-signing-26"ipr="trust200902">number="9246" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <front> <title abbrev="CDNI URI Signing">URI Signing for Content Delivery Network Interconnection (CDNI)</title> <seriesInfo name="RFC" value="9246"/> <author fullname="Ray van Brandenburg" initials="R" surname="van Brandenburg"> <organization>Tiledmedia</organization> <address> <postal> <street>Anna van Buerenplein 1</street> <city>Den Haag</city> <region/> <code>2595DA</code><country>The Netherlands</country><country>Netherlands</country> </postal> <phone>+31 88 866 7000</phone> <email>ray@tiledmedia.com</email> </address> </author> <author fullname="Kent Leung" initials="K" surname="Leung"> <address> <email>mail4kentl@gmail.com</email> </address> </author> <author fullname="Phil Sorber" initials="P" surname="Sorber"> <organization>Apple, Inc.</organization> <address> <postal> <street>1800 Wazee Street</street><street>Suite 410</street><extaddr>Suite 410</extaddr> <city>Denver</city> <region>CO</region> <code>80202</code> <country>United States</country> </postal> <email>sorber@apple.com</email> </address> </author><date/> <workgroup>CDNI</workgroup><date year="2022" month="May" /> <area>art</area> <workgroup>cdni</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract> <t>This document describes how the concept of URI Signing supports the content access control requirements of Content Delivery Network Interconnection (CDNI) and proposes a URI Signing method as a JSON Web Token (JWT) profile.</t> <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 needed by the signed JWT to authorize a User Agent (UA). The mechanism described can be used both in CDNI and single Content Delivery Network (CDN) scenarios.</t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <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 cooperating CDNs and between a Content Service Provider (CSP) and a CDN. The primary goal of URI Signing is to make sure that only authorized UAs are able to access the content, with a CSP being able to authorize every individual request. It should be noted that URI Signing is not a content protection scheme; if a CSP wants to protect the content itself, other mechanisms, such as Digital Rights Management (DRM), are more appropriate. In addition to access control, URI Signing also has benefits in reducing the impact of denial-of-service attacks.</t> <t>The overall problem space for CDN Interconnection (CDNI) is described in<xref target="RFC6707">CDNIthe CDNI ProblemStatement</xref>.Statement <xref target="RFC6707" format="default"/> specification. This document, along with the <xreftarget="RFC7337">CDNItarget="RFC7337" format="default">Content Distribution Network Interconnection (CDNI) Requirements</xref> document and the <xreftarget="RFC7336">CDNI Framework</xref>,target="RFC7336" format="default">Framework for Content Distribution Network 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> <t>Specifically, the <xreftarget="RFC7336">CDNItarget="RFC7336" format="default">CDNI Framework</xref> states:</t><t><list style="empty"> <t>The<ul empty="true" spacing="normal"> <li>The CSP may also trust the CDN operator to perform actions such as delegating traffic to additional downstream CDNs, and to enforce per-request authorization performed by the CSP using techniques such as URISigning.</t> </list></t>Signing.</li> </ul> <t>In particular, the following requirement is listed in the <xreftarget="RFC7337">CDNItarget="RFC7337" format="default">CDNI Requirements</xref>:</t><t><list style="empty"> <t>MI-16 {HIGH}<ul empty="true" spacing="normal"> <li> <blockquote><dl><dt>MI-16</dt><dd>{HIGH} The CDNI Metadata interface shall allow signaling of authorization checks andverificationvalidation that are to be performed by the Surrogate before delivery. For example, this could potentially include the need toverifyvalidate information (e.g., Expiry time, Client IP address) required for accessauthorization.</t> </list></t>authorization.</dd> </dl> </blockquote> </li> </ul> <t>This document defines a method of signing URIs that allows Surrogates in interconnected CDNs to enforce a per-request authorization initiated by the CSP. Splitting the role of initiating per-request authorization by the CSP and the role of verifying this authorization by the CDN allows any arbitrary distribution policy to be enforced across CDNs without the need of CDNs to have any awareness of the specific CSP distribution policies.</t> <t>The method is implemented usingSignedsigned JSON Web Tokens (JWTs) <xreftarget="RFC7519"/>.</t>target="RFC7519" format="default"/>.</t> <sectiontitle="Terminology"> <t>Thenumbered="true" toc="default"> <name>Terminology</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>This document uses the terminology defined in the <xreftarget="RFC6707">CDNItarget="RFC6707" format="default">CDNI Problem Statement</xref>.</t> <t>This document also uses the terminology of the <xreftarget="RFC7519">JSONtarget="RFC7519" format="default">JSON Web Token (JWT)</xref>.</t> <t>In addition, the following terms are used throughout this document:</t><t><list style="symbols"> <t>Signed<dl> <dt>Signed URI:A</dt> <dd>A URI for which a signed JWT isprovided.</t> <t>Targetprovided. </dd> <dt>Target CDN URI: </dt> <dd>A URI created by the CSP to direct a UA towards theUpstreamupstream CDN (uCDN). The Target CDN URI can be signed by the CSP and verified by the uCDN and possibly furtherDownstreamdownstream CDNs(dCDNs).</t> <t>Redirection(dCDNs). </dd> <dt>Redirection URI: </dt> <dd>A URI created by the uCDN to redirect a UA towards the dCDN. The Redirection URI can be signed by the uCDN and verified by the dCDN. In a cascaded CDNI scenario, there can be more than one RedirectionURI.</t> <t>SignedURI. </dd> <dt>Signed Token Renewal:A</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 thenext.</t> </list></t>next. </dd> </dl> </section> <section anchor="background"title="Backgroundnumbered="true" toc="default"> <name>Background andoverviewOverview on URISigning ">Signing</name> <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 realized in practice by including a set of claims in a signed JWT in the URI before redirecting a UA to the CDN. Using these attributes, it is possible for a CDN to check an incoming content request to see whether it was authorized by the CSP (e.g., based on a time window or pattern matching the URI). To prevent the UA from altering theclaimsclaims, the JWTMUST<bcp14>MUST</bcp14> be signed.</t> <t><xreftarget="fig_single_cdn"/>, shown below,target="fig_single_cdn" format="default"/> presents an overview of the URI Signing mechanism in the case of a CSP with a single CDN. When the UA browses for content on CSP's website(#1),(1), it receives HTML web pages with embedded content URIs. Upon requesting these URIs, the CSP redirects to a CDN, creating a Target CDN URI(#2)(2) (alternatively, the Target CDN URI itself is embedded in the HTML). The Target CDN URI is the SignedURIURI, which may include the IP address of the UA and/or a time window. The signed URI always contains a signed JWT generated by the CSP using a shared secret or private key. Once the UA receives the response with the Signed URI, it sends a new HTTP request using the Signed URI to the CDN(#3).(3). Upon receiving the request, the CDN authenticates the Signed URI by verifying the signed JWT. If applicable, the CDN checks whether the time window is still valid in the Signed URI and the pattern matches the URI of the request. After these claims are verified, the CDN delivers the content(#4).</t>(4).</t> <t>Note: While using a symmetric shared key is supported, it isNOT RECOMMENDED.<bcp14>NOT RECOMMENDED</bcp14>. See the <xreftarget="security">Securitytarget="security" format="default">Security Considerations</xref>sectionabout the limitations of shared keys.</t> <figureanchor="fig_single_cdn" title="URIanchor="fig_single_cdn"> <name>URI Signing in a CDNEnvironment"> <artwork>Environment</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -------- / \ | CSP|<|< * * * * * * * * * * * \ / Trust * -------- relationship * ^ | * | | * 1. Browse | | 2. Signed * for | | URI * content | | * | v v +------+ 3. Signed URI -------- | User|----------------->/|----------------->/ \ | Agent| | CDN | ||<-----------------\|<-----------------\ / +------+ 4. Content -------- Delivery</artwork>]]></artwork> </figure> </section> <sectiontitle="CDNInumbered="true" toc="default"> <name>CDNI URI SigningOverview">Overview</name> <t>In a CDNI environment, as shown in <xreftarget="fig_cdni_env"/>target="fig_cdni_env" format="default"/> below, URI Signing operates the same way in the initial steps#11 and#2,2, but the later steps involve multiple CDNs delivering the content. The main difference from the single CDN case is a redirection step between the uCDN and the dCDN. In step#3,3, the UA may send an HTTP request or a DNS request, depending on whether HTTP-based or DNS-based request routing is used. The uCDN responds by directing the UA towards the dCDN using either a Redirection URI (i.e., a Signed URI generated by the uCDN) or a DNS reply, respectively(#4).(4). Once the UA receives the response, it sends the Redirection URI/Target CDN URI to the dCDN(#5).(5). The received URI is verified by the dCDN before delivering the content(#6). Note:(6).</t> <t>Note: The CDNI call flows are covered in <xreftarget="operation">Detailed URItarget="operation" format="default">URI SigningOperation</xref>.</t>Message Flow</xref>.</t> <figureanchor="fig_cdni_env" title="URIanchor="fig_cdni_env"> <name>URI Signing in a CDNIEnvironment"> <artwork>Environment</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +-------------------------+ |Request Redirection Modes| +-------------------------+ | a) HTTP | | b) DNS | +-------------------------+ -------- /\<\< * * * * * * * * * * * * * * | CSP|<|< * * * * * * * * * * * * \ / Trust * * -------- relationship * * ^ | * * | | 2. Signed * * 1. Browse | | URI in * * for | | HTML * * content | | * * | v 3.a)Signed URI v * +------+ b)DNS request -------- * Trust | User|----------------->/|----------------->/ \ * relationship | Agent| | uCDN | * (optional) ||<-----------------\|<-----------------\ / * +------+ 4.a)Redirection URI------- * ^ | b)DNS Reply ^ * | | * * | | Trust relationship * * | | * * 6. Content | | 5.a)Redirection URI * * delivery | | b)Signed URI(after v v | | DNS exchange) -------- |+---------------------->/+---------------------->/ \ [May be | | dCDN | cascaded +--------------------------\ / CDNs] --------</artwork>]]></artwork> </figure> <t>The trust relationships between CSP, uCDN, and dCDN have direct implications for URI Signing. In the case shown in <xreftarget="fig_cdni_env"/>,target="fig_cdni_env" format="default"/>, the CSP has a trust relationship with the uCDN. The delivery of the content may be delegated to a dCDN, which has a relationship with the uCDN but may have no relationship with the CSP.</t> <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 Target CDN URI) provided by the CSP reaches the CDN directly. In the case where the dCDN does not have a trust relationship with the CSP, this means that either an asymmetric public/private key method needs to be used for computing the signed JWT (because the CSP and dCDN are not able to exchange symmetric shared secret keys). Shared keysMUST NOT<bcp14>MUST NOT</bcp14> be redistributed.</t> <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 been verified by the uCDN, the uCDN creates and signs a new Redirection URI, redirecting the UA to the dCDN. Since this new URI can have a new signed JWT, the relationship between the dCDN and CSP is not relevant. Because a relationship between uCDN and dCDN always exists, either asymmetric public/private keys or symmetric shared secret keys can be used for URI Signing with HTTP-based request routing. Note that the signed Redirection URIMUST<bcp14>MUST</bcp14> maintain HTTPS as the scheme if it was present in theoriginaloriginal, and itMAY<bcp14>MAY</bcp14> be upgraded fromhttp:"http:" tohttps:.</t>"https:".</t> <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 mechanism and always contain a private key known only to the entity signing the URI (either CSP or uCDN) and a public key for the verification of the Signed URI. With symmetric keys, the same key is used by both the signing entity for signing the URI and the verifying entity for verifying the Signed URI. Regardless of the type of keys used, the verifying entity has to obtain the key in a manner that allows trust to be placed in the assertions made using that key (either the public or the symmetric key). There are very different requirements (outside the scope of this document) for distributing asymmetric keys and symmetric keys. Key distribution for symmetric keys requires confidentiality to prevent third parties from getting access to the key, since they could then generate valid Signed URIs for unauthorized requests. Key distribution for asymmetric keys does not require confidentiality since public keys can typically be distributed openly (because they cannot be used to sign URIs) and the corresponding private keys are kept secret by the URI signer.</t> <t>Note: While using a symmetric shared key is supported, it isNOT RECOMMENDED.<bcp14>NOT RECOMMENDED</bcp14>. See the <xreftarget="security">Securitytarget="security" format="default">Security Considerations</xref>sectionabout the limitations of shared keys.</t> </section> <sectiontitle="URInumbered="true" toc="default"> <name>URI Signing in anon-CDNI context">Non-CDNI Context</name> <t>While the URI Signing method defined in this document was primarily created for the purpose of allowing URI Signing in CDNI scenarios, i.e., between a uCDN and a dCDN, there is nothing in the defined URI Signing method that precludes it from being used in a non-CDNI context. As such, the described mechanism could be used in a single-CDN scenario such as shown in <xreftarget="fig_single_cdn"/>target="fig_single_cdn" format="default"/> in <xreftarget="background"/>,target="background" format="default"/> for example to allow a CSP that uses different CDNs to only have to implement a single URI Signing mechanism.</t> </section> </section> <section anchor="jwt_profile"title="JWTnumbered="true" toc="default"> <name>JWT Format and ProcessingRequirements">Requirements</name> <t>The concept behind URI Signing is based on embedding a signed <xreftarget="RFC7519">JSONtarget="RFC7519" format="default">JSON Web Token (JWT)</xref> in an <xreftarget="RFC7230">HTTPtarget="RFC7230" format="default">HTTP or HTTPS URI</xref> (see[RFC7230] Section 2.7).<xref target="RFC7230" sectionFormat="of" section="2.7"/>). The signed JWT contains a number of 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> <list style="symbols"> <t>URI<dl> <dt>URI Signing Package (URISigningPackage):The</dt> <dd>The URI attribute that encapsulates all the URI Signing claims in a signed JWT encoded format. This attribute is exposed in the Signed URI as a path-style parameter or a form-styleparameter.</t> </list> </t>parameter. </dd> </dl> <t>The parameter name of the URI Signing Package Attribute is defined in the <xreftarget="metadata">CDNItarget="metadata" format="default">CDNI Metadata</xref>. If the CDNI Metadata interface is not used, or does not include a parameter name for the URI Signing Package Attribute, the parameter name can be set by configuration (out of scope of this document).</t> <t>The URI Signing Package will be found by parsing any path-style parameters and form-style parameters looking for a key name matching the URI Signing Package Attribute. Both parameter stylesMUST<bcp14>MUST</bcp14> be supported to allow flexibility of operation. The first matching parameterSHOULD<bcp14>SHOULD</bcp14> be taken to provide the signed JWT, though providing more than one matching key is undefined behavior. Path-style parameters generated in the form indicated bySection 3.2.7 of<xref target="RFC6570"/>sectionFormat="of" section="3.2.7" format="default"/> and Form-style parameters generated in the form indicated by Sections3.2.8<xref target="RFC6570" section="3.2.8" sectionFormat="bare"/> and3.2.9<xref target="RFC6570" sectionFormat="bare" section="3.2.9"/> of <xref target="RFC6570"/> MUSTformat="default"/> <bcp14>MUST</bcp14> be supported.</t> <t>The following is an example where the URI Signing Package Attribute name is "token" and the signed JWT is "SIGNEDJWT":</t><figure><artwork>http://example.com/media/path?come=data&token=SIGNEDJWT&other=data</artwork></figure><sourcecode type=""><![CDATA[http://example.com/media/path?come=data&token=SIGNEDJWT&other=data]]></sourcecode> <!-- [rfced] Please let us know if a "type" attribute may be added to the sourcecode elements in this document. The allowed types can be found here: https://www.rfc-editor.org/materials/sourcecode-types.txt Note that it is acceptable to leave the type attribute empty. --> <section anchor="jwt_claims"title="JWT Claims">numbered="true" toc="default"> <name>JWT Claims</name> <t>This section identifies the set of claims that can be used to enforce the CSP distribution policy. New claims can be introduced in the future to extend the distribution policy capabilities.</t> <t>In order to provide distribution policy flexibility, the exact subset of claims used in a given signed JWT is a runtime decision. Claim requirements are defined in the <xreftarget="metadata">CDNItarget="metadata" format="default">CDNI Metadata</xref>. If the CDNI Metadata interface is not used, or does not include claim requirements, the claim requirements can be set by configuration (out of scope of this document).</t> <t>The following claims (where the "JSON Web Token Claims" registry claim name is specified in parentheses below) are used to enforce the distribution policies. All of the listed claims are mandatory to implement in a URI Signingimplementation,implementation but are not necessarily mandatory to use in a given signed JWT. (The "optional" and "mandatory" identifiers in square brackets refer to whether or not a given claimMUST<bcp14>MUST</bcp14> be present in a URI Signing JWT.)</t> <t>Note: The time on the entities that generate and verify the signed URIMUST<bcp14>MUST</bcp14> be in sync. In the CDNI case, this means that CSP, uCDN, and dCDN servers need to betime-synchronized.time synchronized. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to use <xreftarget="RFC5905">NTP</xref>target="RFC5905" format="default">NTP</xref> for time synchronization.</t> <t>Note: See the <xreftarget="security">Securitytarget="security" format="default">Security Considerations</xref>sectionon the limitations of using an expiration time andclientClient IP address for distribution policy enforcement.</t> <section anchor="iss_claim"title="Issuernumbered="true" toc="default"> <name>Issuer (iss)claim">Claim</name> <t>Issuer (iss) [optional] - The semantics in <xreftarget="RFC7519"/> Section 4.1.1 MUSTtarget="RFC7519" sectionFormat="of" section="4.1.1" format="default"/> <bcp14>MUST</bcp14> be followed. If this claim is used, itMUST<bcp14>MUST</bcp14> be used to identify the issuer (signer) of the JWT. In particular, the recipient will have already received, in trusted configuration, a mapping of issuer name to one or more keys used to signJWTs,JWTs and must verify that the JWT was signed by one of those keys. If this claim is used and the CDN verifying the signed JWT does not support Issuer verification, or if the Issuer in the signed JWT does not match the list of known acceptable Issuers, or if the Issuer claim does not match the key used to sign the JWT, the CDNMUST<bcp14>MUST</bcp14> reject the request. If the received signed JWT contains an Issuer claim, then any JWT subsequently generated for CDNI redirectionMUST<bcp14>MUST</bcp14> also contain an Issuer claim, and the Issuer valueMUST<bcp14>MUST</bcp14> be updated to identify the redirecting CDN. If the received signed JWT does not contain an Issuer claim, an Issuer claimMAY<bcp14>MAY</bcp14> be added to a signed JWT generated for CDNI redirection.</t> </section> <section anchor="sub_claim"title="Subjectnumbered="true" toc="default"> <name>Subject (sub)claim">Claim</name> <t>Subject (sub) [optional] - The semantics in <xreftarget="RFC7519"/> Section 4.1.2 MUSTtarget="RFC7519" sectionFormat="of" section="4.1.2" format="default"/> <bcp14>MUST</bcp14> be followed. If this claim is used, itMUST<bcp14>MUST</bcp14> be a JSON Web Encryption (<xreftarget="RFC7516">JWE</xref>)target="RFC7516" format="default">JWE</xref>) Object in compact serialization form, because it contains personally identifiable information. This claim contains information about thesubjectSubject (for example, a user or an agent) thatMAY<bcp14>MAY</bcp14> be used to verify the signed JWT. If the received signed JWT contains a Subject claim, then any JWT subsequently generated for CDNI redirectionMUST<bcp14>MUST</bcp14> also contain a Subject claim, and the Subject valueMUST<bcp14>MUST</bcp14> be the same as in the received signed JWT. A signed JWT generated for CDNI redirectionMUST NOT<bcp14>MUST NOT</bcp14> add a Subject claim if no Subject claim existed in the received signed JWT.</t> </section> <section anchor="aud_claim"title="Audiencenumbered="true" toc="default"> <name>Audience (aud)claim">Claim</name> <t>Audience (aud) [optional] - The semantics in <xreftarget="RFC7519"/> Section 4.1.3 MUSTtarget="RFC7519" sectionFormat="of" section="4.1.3" format="default"/> <bcp14>MUST</bcp14> be followed. This claim is used to ensure that the CDN verifying the JWT is an intended recipient of the request. The claimMUST<bcp14>MUST</bcp14> contain an identity belonging to the chain of entities involved in processing the request (e.g., identifying the CSP or any CDN in the chain) that the recipient is configured to use for the processing of this request. A CDNMAY<bcp14>MAY</bcp14> modify the claim as long it can generate a valid signature.</t> </section> <section anchor="exp_claim"title="Expirynumbered="true" toc="default"> <name>Expiry Time (exp)claim">Claim</name> <t>Expiry Time (exp) [optional] - The semantics in <xreftarget="RFC7519"/> Section 4.1.4 MUSTtarget="RFC7519" sectionFormat="of" section="4.1.4" format="default"/> <bcp14>MUST</bcp14> be followed, though URI Signing implementationsMUST NOT<bcp14>MUST NOT</bcp14> allow for anytime synchronizationtime-synchronization "leeway". If this claim is used and the CDN verifying the signed JWT does not support Expiry Time verification, or if the Expiry Time in the signed JWT corresponds to a time equal to or earlier than the time of the content request, the CDNMUST<bcp14>MUST</bcp14> reject the request. If the received signed JWT contains an Expiry Time claim, then any JWT subsequently generated for CDNI redirectionMUST<bcp14>MUST</bcp14> also contain an Expiry Time claim, and the Expiry Time valueMUST<bcp14>MUST</bcp14> be the same as in the received signed JWT. A signed JWT generated for CDNI redirectionMUST NOT<bcp14>MUST NOT</bcp14> add an Expiry Time claim if no Expiry Time claim existed in the received signed JWT.</t> </section> <section anchor="nbf_claim"title="Notnumbered="true" toc="default"> <name>Not Before (nbf)claim">Claim</name> <t>Not Before (nbf) [optional] - The semantics in <xreftarget="RFC7519"/> Section 4.1.5 MUSTtarget="RFC7519" sectionFormat="of" section="4.1.5" format="default"/> <bcp14>MUST</bcp14> be followed, though URI Signing implementationsMUST NOT<bcp14>MUST NOT</bcp14> allow for anytime synchronizationtime-synchronization "leeway". If this claim is used and the CDN verifying the signed JWT does not support Not Before time verification, or if the Not Before time in the signed JWT corresponds to a time later than the time of the content request, the CDNMUST<bcp14>MUST</bcp14> reject the request. If the received signed JWT contains a Not Before time claim, then any JWT subsequently generated for CDNI redirectionMUST<bcp14>MUST</bcp14> also contain a Not Before time claim, and the Not Before time valueMUST<bcp14>MUST</bcp14> be the same as in the received signed JWT. A signed JWT generated for CDNI redirectionMUST NOT<bcp14>MUST NOT</bcp14> add a Not Before time claim if no Not Before time claim existed in the received signed JWT.</t> </section> <section anchor="iat_claim"title="Issuednumbered="true" toc="default"> <name>Issued At (iat)claim">Claim</name> <t>Issued At (iat) [optional] - The semantics in <xreftarget="RFC7519"/> Section 4.1.6 MUSTtarget="RFC7519" sectionFormat="of" section="4.1.6" format="default"/> <bcp14>MUST</bcp14> be followed. If the received signed JWT contains an Issued At claim, then any JWT subsequently generated for CDNI redirectionMUST<bcp14>MUST</bcp14> also contain an Issued At claim, and the Issued At valueMUST<bcp14>MUST</bcp14> be updated to identify the time the new JWT was generated. If the received signed JWT does not contain an Issued At claim, an Issued At claimMAY<bcp14>MAY</bcp14> be added to a signed JWT generated for CDNI redirection.</t> </section> <section anchor="jti_claim"title="JWTnumbered="true" toc="default"> <name>JWT ID (jti)claim">Claim</name> <t>JWT ID (jti) [optional] - The semantics in <xreftarget="RFC7519"/> Section 4.1.7 MUSTtarget="RFC7519" sectionFormat="of" section="4.1.7" format="default"/> <bcp14>MUST</bcp14> be followed. A JWT ID can be used to prevent replay attacks if the CDN stores a list of all previously usedvalues,values and verifies that the value in the current JWT has never been used before. If the signed JWT contains a JWT ID claim and the CDN verifying the signed JWT either does not support JWT ID storage or has previously seen the value used in a request for the same content, then the CDNMUST<bcp14>MUST</bcp14> reject the request. If the received signed JWT contains a JWT ID claim, then any JWT subsequently generated for CDNI redirectionMUST<bcp14>MUST</bcp14> also contain a JWT ID claim, and the valueMUST<bcp14>MUST</bcp14> be the same as in the received signed JWT. If the received signed JWT does not contain a JWT ID claim, a JWT ID claimMUST NOT<bcp14>MUST NOT</bcp14> be added to a signed JWT generated for CDNI redirection. Sizing of the JWT ID is application dependent given the desired security constraints.</t> </section> <section anchor="cdniv_claim"title="CDNInumbered="true" toc="default"> <name>CDNI Claim Set Version (cdniv)claim">Claim</name> <t>CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set Version (cdniv) claim provides a means within a signed JWT to tie the claim set to a specific version of this specification. The cdniv claim is intended to allow changes in and facilitate upgrades across specifications. The type is a JSON integer and the valueMUST<bcp14>MUST</bcp14> be set to"1","1" for this version of the specification. In the absence of this claim, the value is assumed to be "1". For futureversionsversions, this claim will be mandatory. ImplementationsMUST<bcp14>MUST</bcp14> reject signed JWTs with unsupported CDNI Claim Set versions.</t> </section> <section anchor="cdnicrit_claim"title="CDNInumbered="true" toc="default"> <name>CDNI Critical Claims Set (cdnicrit)claim">Claim</name> <t>CDNI Critical Claims Set (cdnicrit) [optional] - The CDNI Critical Claims Set (cdnicrit) claim indicates that extensions to this specification are being used thatMUST<bcp14>MUST</bcp14> be understood and processed. Its value is acomma separatedcomma-separated listing of claims in the Signed JWT that use those extensions. If any of the listed extension claims are not understood and supported by the recipient, then the Signed JWTMUST<bcp14>MUST</bcp14> be rejected. ProducersMUST NOT<bcp14>MUST NOT</bcp14> include claim names defined by this specification, duplicate names, or names that do not occur as claim names within the Signed JWT in the cdnicrit list. ProducersMUST NOT<bcp14>MUST NOT</bcp14> use the empty list "" as the cdnicrit value. RecipientsMAY<bcp14>MAY</bcp14> consider the Signed JWT to be invalid if the cdnicrit list contains any claim names defined by this specification or if any other constraints on its use are violated. This claimMUST<bcp14>MUST</bcp14> be understood and processed by all implementations.</t> </section> <section anchor="cdniip_claim"title="Clientnumbered="true" toc="default"> <name>Client IP Address (cdniip)claim">Claim</name> <t>Client IP Address (cdniip) [optional] - The Client IP Address (cdniip) claim holds an IP address or IP prefix for which the Signed URI is valid. This is represented in CIDRnotation,notation with dotted decimal format for <xreftarget="RFC0791">IPv4target="RFC0791" format="default">IPv4 addresses</xref> or canonical text representation for <xreftarget="RFC5952">IPv6target="RFC5952" format="default">IPv6 addresses</xref>. The requestMUST<bcp14>MUST</bcp14> be rejected if sourced from a client outside the specified IP range. Since theclientClient IP is considered personally identifiableinformationinformation, this fieldMUST<bcp14>MUST</bcp14> be a JSON Web Encryption (<xreftarget="RFC7516">JWE</xref>)target="RFC7516" format="default">JWE</xref>) Object in compact serialization form. If the CDN verifying the signed JWT does not support Client IP verification, or if the Client IP in the signed JWT does not match the source IP address in the content request, the CDNMUST<bcp14>MUST</bcp14> reject the request. The type of this claim is a JSON string that contains the JWE. If the received signed JWT contains a Client IP claim, then any JWT subsequently generated for CDNI redirectionMUST<bcp14>MUST</bcp14> also contain a Client IP claim, and the Client IP valueMUST<bcp14>MUST</bcp14> be the same as in the received signed JWT. A signed JWT generated for CDNI redirectionMUST NOT<bcp14>MUST NOT</bcp14> add a Client IP claim if no Client IP claim existed in the received signed JWT.</t> <t>It should be noted that use of this claim can cause issues, for example, in situations with dual-stack IPv4 and IPv6 networks, MPTCP, QUIC, and mobile clients switching from Wi-Fi to Cellular networks where the client's source address can change, even between address families. This claim exists mainly for legacy feature parityreasons, thereforereasons; therefore, use of this claim should be done judiciously. An example of a reasonable use case would be making a signed JWT for an internal preview of an asset where the end consumer understands that they must be originated from the same IP for the entirety of the session. Using this claim at large isNOT RECOMMENDED.</t><bcp14>NOT RECOMMENDED</bcp14>.</t> </section> <section anchor="cdniuc_claim"title="CDNInumbered="true" toc="default"> <name>CDNI URI Container (cdniuc)claim">Claim</name> <t>URI Container (cdniuc) [mandatory] - The URI Container (cdniuc) holds the URI representation before a URI Signing Package is added. This representation can take one of several forms detailed in <xreftarget="uri_container_forms"/>.target="uri_container_forms" format="default"/>. If the URI Container used in the signed JWT does not match the URI of the content request, the CDN verifying the signed JWTMUST<bcp14>MUST</bcp14> reject the request. When comparing the URI, the percent encoded form as defined in <xreftarget="RFC3986"/> Section 2.1 MUSTtarget="RFC3986" sectionFormat="of" section="2.1" format="default"/> <bcp14>MUST</bcp14> be used. When redirecting a URI, the CDN generating the new signed JWTMAY<bcp14>MAY</bcp14> change the URI Container to comport with the URI being used in the redirection.</t> </section> <section anchor="cdniets_claim"title="CDNInumbered="true" toc="default"> <name>CDNI Expiration Time Setting (cdniets)claim">Claim</name> <t>CDNI Expiration Time Setting (cdniets) [optional] - The CDNI Expiration Time Setting (cdniets) claim provides a means for setting the value of the Expiry Time (exp) claim when generating a subsequent signed JWT in Signed Token Renewal. Its type is a JSON numeric value. It denotes the number of seconds to be added to the time at which the JWT is verified that gives the value of the Expiry Time (exp) claim of the next signed JWT. The CDNI Expiration Time Setting (cdniets)SHOULD NOT<bcp14>SHOULD NOT</bcp14> be used when not using Signed Token Renewal andMUST<bcp14>MUST</bcp14> be present when using Signed Token Renewal.</t> </section> <section anchor="cdnistt_claim"title="CDNInumbered="true" toc="default"> <name>CDNI Signed Token Transport (cdnistt)claim">Claim</name> <t>CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed Token Transport (cdnistt) claim provides a means ofsignallingsignaling the method through which a new signed JWT is transported from the CDN to the UA and vice versa for the purpose of Signed Token Renewal. Its type is a JSON integer. Values for this claim are defined in <xreftarget="sec.IANA.cdnistt"/>.target="sec.IANA.cdnistt" format="default"/>. If using thisclaimclaim, youMUST<bcp14>MUST</bcp14> also specify a CDNI Expiration Time Setting (cdniets) as noted above.</t> </section> <section anchor="cdnistd_claim"title="CDNInumbered="true" toc="default"> <name>CDNI Signed Token Depth (cdnistd)claim">Claim</name> <t>CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token Depth (cdnistd) claim is used to associate a subsequent signed JWT, generated as the result of a CDNI Signed Token Transport claim, with a specific URI subset. Its type is a JSON integer. Signed JWTsMUST NOT<bcp14>MUST NOT</bcp14> use a negative 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 URI with tokens (e.g., an HTTP Cookie Path as described insection 4.1.2.4 of<xreftarget="RFC6265"/>),target="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 considered significant for this association. A CDNI Signed Token Depth of zero means that the clientSHOULD<bcp14>SHOULD</bcp14> be directed to return the token with requests for any path. If the CDNI Signed Token Depth is greater than zero, then the CDNSHOULD<bcp14>SHOULD</bcp14> send the client a token to return for future requests wherein the first CDNI Signed Token Depth segments of the path match the first CDNI Signed Token Depth segments of the signed URI path. This matchingMUST<bcp14>MUST</bcp14> use the URI with the token removed, as specified in <xreftarget="uri_container_forms"/>.</t>target="uri_container_forms" format="default"/>.</t> <t>If the URI path to match contains fewer segments than the CDNI Signed Token Depth claim, a signed JWTMUST NOT<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. If the received signed JWT contains a CDNI Signed Token Depth claim, then any JWT subsequently generated for CDNI redirection or Signed Token TransportMUST<bcp14>MUST</bcp14> also contain a CDNI Signed Token Depth claim, and the valueMUST<bcp14>MUST</bcp14> be the same as in the received signed JWT.</t> </section> <section anchor="uri_container_forms"title="URInumbered="true" toc="default"> <name>URI ContainerForms">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 capabilities.</t> <t>Before comparing a URI with contents of this container, the following stepsMUST<bcp14>MUST</bcp14> be performed:<list style="symbols"> <t>Prior</t> <ul spacing="normal"> <li>Prior to verification, remove the signed JWT from the URI. This removal is only for the purpose of determining if the URI matches; all other purposes will use the original URI. If the signed JWT is terminated by anything other than a sub-delimiter (as defined in <xreftarget="RFC3986"/> Section 2.2),target="RFC3986" section="2.2" sectionFormat="of" format="default"/>), everything from the reserved character (as defined in <xreftarget="RFC3986"/> Section 2.2)target="RFC3986" section="2.2"/>) that precedes the URI Signing Package Attribute to the last character of the signed JWT will be removed, inclusive. Otherwise, everything from the first character of the URI Signing Package Attribute to the sub-delimiter that terminates the signed JWT will be removed,inclusive.</t> <t>Normalizeinclusive.</li> <li>Normalize the URI according to <xreftarget="RFC7230">section 2.7.3</xref>target="RFC7230" sectionFormat="of" section="2.7.3" format="default"/> and Sections <xreftarget="RFC3986"> sections 6.2.2target="RFC3986" section="6.2.2" sectionFormat="bare"/> and6.2.3</xref>.<xref target="RFC3986" section="6.2.3" sectionFormat="bare"/> of <xref target="RFC3986" format="default"/>. This applies to both generation and verification of the signedJWT.</t> </list></t>JWT.</li> </ul> <section anchor="uri_container_forms_hash"title="URInumbered="true" toc="default"> <name>URI Hash Container(hash:)">(hash:)</name> <t>Prefixed with 'hash:', this string is a URL Segment form (<xreftarget="RFC6920"/> Section 5)target="RFC6920" section="5" sectionFormat="of" format="default"/>) of the URI.</t> </section> <section anchor="uri_container_forms_regex"title="URInumbered="true" toc="default"> <name>URI Regular Expression Container(regex:)">(regex:)</name> <t>Prefixed with 'regex:', this string is any regular expression compatible with POSIX (Section 9 of <xreftarget="POSIX.1">POSIX Section 9</xref>target="POSIX.1" format="default"/>) Extended Regular Expressioncompatible regular expressionused to match against the requested URI. These regular expressionsMUST<bcp14>MUST</bcp14> be evaluated in the POSIX locale(<xref target="POSIX.1">POSIX Section 7.2</xref>).(Section 7.2 of <xref target="POSIX.1" format="default"/>). </t> <t>Note: Because '\' has special meaning in JSON <xreftarget="RFC8259"/>target="RFC8259" format="default"/> as the escape character within JSON strings, the regular expression character '\'MUST<bcp14>MUST</bcp14> be escaped as '\\'.</t> <t>An example of a 'regex:' is the following:</t><t> <figure> <artwork><!-- [rfced] The following line in Section 2.1.15.2 exceeds the maximum 69-character width (for sourcecode) by one character. Is it possible to place a line break in this line? Also, please let us know if you would like text to be added, e.g., "An example of a 'regex:' is the following (with a line break added for display purposes only):" Original: [^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)?</artwork> </figure> </t>--> <sourcecode><![CDATA[ [^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)? ]]></sourcecode> <t>Note: Due to computational complexity of executing arbitrary regular expressions, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to only execute after verifying the JWT to ensure its authenticity.</t> </section> </section> </section> <section anchor="jwt_header"title="JWT Header">numbered="true" toc="default"> <name>JWT Header</name> <t>The header of the JWTMAY<bcp14>MAY</bcp14> be passed via the CDNI Metadata interface instead of being included in the URISigningPackage. The header valueMUST<bcp14>MUST</bcp14> be transmitted in the serialized encoded form and prepended to the JWT payload and signature passed in the URISigningPackage prior to verification. This reduces the size of the signed JWT token.</t> </section> </section> <section anchor="uri_signing_token_renewal"title="URInumbered="true" toc="default"> <name>URI Signing TokenRenewal">Renewal</name> <section anchor="token_renewal_intro"title="Overview">numbered="true" toc="default"> <name>Overview</name> <t>For content that is delivered via HTTP in a segmented fashion, such as <xreftarget="MPEG-DASH">MPEG-DASH</xref>target="MPEG-DASH" format="default">MPEG-DASH</xref> or <xreftarget="RFC8216">target="RFC8216" format="default"> HTTP Live Streaming (HLS)</xref>, special provisions need to be made in order to ensure URI Signing can be applied. In general, segmented protocols work by breaking large objects (e.g., videos) into a sequence of small independent segments. Such segments are then referenced by a separate manifest file, which either includes a list of URLs to the segments or specifies an algorithm through which a User Agent can construct the URLs to the segments. Requests for segments therefore originate from the manifest file and, unless the URLs in the manifest file point to the CSP, are not subjected to redirection and URI Signing. This opens up a vulnerability to malicious User Agents sharing the manifest file anddeep-linkingdeep linking to the segments.</t> <t>One method for dealing with this vulnerability would be to include, in the manifest itself, Signed URIs that point to the individual segments. There exist a number of issues with that approach. First, it requires the CDN delivering the manifest to rewrite the manifest file for each User Agent, which would require the CDN to be aware of the exact segmentation protocol used. Secondly, it could also require the expiration time of the Signed URIs to be valid for an extended duration if the content described by the manifest is meant to be consumed in real time. For instance, if the manifest file were to contain a segmented video stream of more than 30 minutes in length, Signed URIs would require to be valid for at least 30 minutes, thereby reducing their effectiveness and that of the URI Signing mechanism in general. For a more detailed analysis of how segmented protocols such as HTTP Adaptive Streaming protocols affect CDNI, see <xreftarget="RFC6983">Modelstarget="RFC6983" format="default">Models for HTTP-Adaptive-Streaming-AwareCDNI</xref>.</t>Content Distribution Network Interconnection (CDNI)</xref>.</t> <t>The method described in this section allows CDNs to use URI Signing for segmented content without having to include the Signed URIs in the manifest files themselves.</t> </section> <section anchor="uri_signing_mechanism"title="Signednumbered="true" toc="default"> <name>Signed Token Renewalmechanism">Mechanism</name> <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 through which subsequent segment requests can be linked together. As part of the JWT verification procedure, the CDN can generate a new signed JWT that the UA can use to do a subsequent request. More specifically, whenever a UA successfully retrieves a segment, it receives, in the HTTP 2xx Successful message, a signed JWT that it can use whenever it requests the next segment. As long as each successive signed JWT is correctly verified before a new one is generated, the model is not broken, and the User Agent can successfully retrieve additional segments. Given the fact that with segmentedprotocols,protocols it is usually not possible to determine a priori which segment will be requested next (i.e., to allow for seeking within the content and for switching to a different representation), the Signed Token Renewal uses the URI Regular Expression Container scoping mechanisms in the URI Container (cdniuc) claim to allow a signed JWT to be valid for more than one URL.</t> <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 an earlier request and use it to retrieve the next segment. The exact mechanism by which the client does this is outside the scope of this document. However, in order to also support legacy UAs that do not include any specific provisions for the handling of signed JWTs, <xreftarget="communicating_token"/>target="communicating_token" format="default"/> defines a mechanism using HTTP Cookies <xreftarget="RFC6265"/>target="RFC6265" format="default"/> that allows such UAs to support the concept of renewing signed JWTs without requiring any additional UA support.</t> <sectiontitle="Required Claims">numbered="true" toc="default"> <name>Required Claims</name> <t>The <xreftarget="cdnistt_claim">cdnistttarget="cdnistt_claim" format="default">cdnistt claim</xref> and <xreftarget="cdniets_claim">cdnietstarget="cdniets_claim" format="default">cdniets claim</xref>MUST<bcp14>MUST</bcp14> both be present for Signed Token Renewal. cdnisttMAY<bcp14>MAY</bcp14> be set to a value of '0' to mean no Signed Token Renewal, but there stillMUST<bcp14>MUST</bcp14> be a corresponding cdniets that verifies as a JSON number. However, if use of Signed Token Renewal is not desired, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to simply omit both.</t> </section> </section> <section anchor="communicating_token"title="Communicatingnumbered="true" toc="default"> <name>Communicating asignedSigned JWTs in Signed Token Renewal</name> <!--[rfced] Should the 's' be removed in this section title? In other words, was singular or plural intended? Current: 3.3. Communicating a Signed JWTs in Signed Token Renewal Perhaps (singular): 3.3. Communicating a Signed JWT in Signed Token Renewal Or (plural): 3.3. Communicating Signed JWTs in Signed TokenRenewal">Renewal --> <t>This section assumes the value of the CDNI Signed Token Transport (cdnistt) claim has been set to 1.</t> <t>When using the Signed Token Renewal mechanism, the signed JWT is transported to the UA via a 'URISigningPackage' cookie added to the HTTP 2xx Successful message along with the content being returned to the UA, or to the HTTP 3xx Redirection message in case the UA is redirected to a different server.</t> <sectiontitle="Supportnumbered="true" toc="default"> <name>Support forcross-domain redirection">Cross-Domain Redirection</name> <t>For security purposes, the use of cross-domain cookies is not supported in some application environments. As a result, the Cookie-based method for transport of the Signed Token described in <xreftarget="communicating_token"/>target="communicating_token" format="default"/> might break if used in combination with an HTTP 3xx Redirection response where the target URL is in a different domain. In such scenarios, Signed Token Renewal of a signed JWTSHOULD<bcp14>SHOULD</bcp14> be communicated via the query string instead, in a similar fashion to how regular signed JWTs (outside of Signed Token Renewal) are communicated. Note the value of the CDNI Signed Token Transport (cdnistt) claimMUST<bcp14>MUST</bcp14> be set to 2.</t> <t>Note that the process described herein only works in cases where both the manifest file and segments constituting the segmented content are delivered from the same domain. In other words, any redirection between different domains needs to be carried out while retrieving the manifest file.</t> </section> </section> </section> <section anchor="cdni_interfaces"title="Relationshipnumbered="true" toc="default"> <name>Relationship with CDNIInterfaces">Interfaces</name> <t>Some of the CDNI Interfaces need enhancements to support URI Signing. A dCDN that supports URI Signing needs to be able to advertise this capability to the uCDN. The uCDN needs to select a dCDN based on such capability when the CSP requires access control to enforce its distribution policy via URI Signing. Also, the uCDN needs to be able to distribute via the CDNI Metadata interface the information necessary to allow the dCDN to verify a Signed URI. Events that pertain to URI Signing (e.g., request denial or delivery after an access authorization decision has been made) need to be included in the logs communicated through the CDNI Logging interface.</t> <section anchor="control"title="CDNInumbered="true" toc="default"> <name>CDNI ControlInterface">Interface</name> <t>URI Signing has no impact on this interface.</t> </section> <section anchor="advertisement"title="CDNInumbered="true" toc="default"> <name>CDNI Footprint & Capabilities AdvertisementInterface">Interface</name> <t>The CDNI Request Routing: Footprint and Capabilities Semantics document <xreftarget="RFC8008"/>target="RFC8008" format="default"/> defines support for advertising CDNI Metadatacapabilities,capabilities via CDNI Payload Type. The CDNI Payload Type registered in <xreftarget="sec.IANA.payload"/>target="sec.IANA.payload" format="default"/> can be used for capability advertisement.</t> </section> <section anchor="redirection"title="CDNInumbered="true" toc="default"> <name>CDNI Request Routing RedirectionInterface">Interface</name> <t>The <xreftarget="RFC7975">CDNItarget="RFC7975" format="default">CDNI Request Routing Redirection Interface</xref> describes the recursive request redirection method. For URI Signing, the uCDN signs the URI provided by the dCDN. URI Signing therefore has no impact on this interface.</t> </section> <section anchor="metadata"title="CDNInumbered="true" toc="default"> <name>CDNI MetadataInterface">Interface</name> <t>The <xreftarget="RFC8006">CDNItarget="RFC8006" format="default">CDNI Metadata Interface</xref> describes the CDNImetadataMetadata distribution needed to enable content acquisition and delivery. For URI Signing, a new CDNImetadataMetadata object is specified.</t> <t>The UriSigning Metadata object contains information to enable URI Signing and verification by a dCDN. The UriSigning properties are defined below.</t><t><list style="empty"><ul empty="true" spacing="normal"> <li> <t>Property:enforce<list style="empty"> <t>Description: URIenforce</t> <ul empty="true" spacing="normal"> <li> <dl> <dt>Description: </dt> <dd>URI Signing enforcement flag. Specifically, this flag indicates if the access to content is subject to URI Signing. URI Signing requires the dCDN to ensure that the URI is signed and verified before delivering content. Otherwise, the dCDN does not perform verification, regardless of whether or not the URI issigned.</t> <t>Type: Boolean</t> <t>Mandatory-to-Specify: No.signed. </dd> <dt>Type: </dt> <dd>Boolean </dd> <dt>Mandatory-to-Specify: </dt> <dd>No. The default istrue.</t> </list></t>true. </dd> </dl> </li> </ul> </li> <li> <t>Property:issuers<list style="empty"> <t>Description: Aissuers</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 becross-referenced.</t> <t>Type: Array of Strings</t> <t>Mandatory-to-Specify: No.cross-referenced. </dd> <dt>Type: </dt> <dd>Array of Strings </dd> <dt>Mandatory-to-Specify: </dt> <dd>No. The default is an empty list. An empty list means that any Issuer in the trusted key store of issuers isacceptable.</t> </list></t>acceptable. </dd> </dl> </li> </ul> </li> <li> <t>Property:package-attribute<list style="empty"> <t>Description: Thepackage-attribute</t> <ul empty="true" spacing="normal"> <li> <dl> <dt>Description: </dt> <dd>The attribute name to use for the URI SigningPackage.</t> <t>Type: String</t> <t>Mandatory-to-Specify: No.Package. </dd> <dt> Type: </dt> <dd>String</dd> <dt>Mandatory-to-Specify:</dt> <dd>No. The default is"URISigningPackage".</t> </list></t>"URISigningPackage".</dd> </dl> </li> </ul> </li> <li> <t>Property:jwt-header<list style="empty"> <t>Description: Thejwt-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 headerpart.</t> <t>Type: String</t> <t>Mandatory-to-Specify: No.part. </dd> <dt>Type: </dt> <dd>String </dd> <dt>Mandatory-to-Specify: </dt> <dd>No. By default, the header is assumed to be included in the JWTtoken.</t> </list></t> </list></t>token. </dd> </dl> </li> </ul> </li> </ul> <t>The following is an example of a URI Signing metadata payload with all default values:</t><figure> <artwork><![CDATA[<sourcecode><![CDATA[ { "generic-metadata-type": "MI.UriSigning" "generic-metadata-value": {} }]]> </artwork> </figure>]]></sourcecode> <t>The following is an example of a URI Signing metadata payload with explicit values:</t><figure> <artwork><![CDATA[<sourcecode><![CDATA[ { "generic-metadata-type": "MI.UriSigning" "generic-metadata-value": { "enforce": true, "issuers": ["csp", "ucdn1", "ucdn2"], "package-attribute": "usp", "jwt-header": { "alg": "ES256", "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0" } } }]]> </artwork> </figure>]]></sourcecode> </section> <section anchor="logging"title="CDNInumbered="true" toc="default"> <name>CDNI LoggingInterface">Interface</name> <t>For URI Signing, the dCDN reports that enforcement of the access control was applied to the request for content delivery. When the request is denied due to enforcement of URI Signing, the reason is logged.</t> <t>The following CDNI Logging field for URI SigningSHOULD<bcp14>SHOULD</bcp14> be supported in the HTTP Request Logging Record as specified in "<xref target="RFC7937" format="title"/>" <xreftarget="RFC7937">CDNI Logging Interface</xref>,target="RFC7937"/> using the new "cdni_http_request_v2" record-type registered in <xreftarget="sec.IANA.record_type.cdni_http_request_v2"/>.</t> <t><list style="symbols">target="sec.IANA.record_type.cdni_http_request_v2" format="default"/>.</t> <ul spacing="normal"> <li> <t>s-uri-signing (mandatory):<list> <t>format: 3DIGIT</t> <t>field</t> <dl> <dt>Format: </dt> <dd>3DIGIT </dd> <dt>Field value:this characterises</dt> <dd>this characterizes the URI Signing verification performed by the Surrogate on the request. The allowed values are registered in <xreftarget="sec.IANA.field.s-uri-signing.values"/>.</t> <t>occurrence: there MUSTtarget="sec.IANA.field.s-uri-signing.values" format="default"/>. </dd> <dt>Occurrence: </dt> <dd>there <bcp14>MUST</bcp14> be zero or exactly one instance of thisfield.</t> </list></t>field. </dd> </dl> </li> <li> <t>s-uri-signing-deny-reason (optional):<list> <t>format: QSTRING</t> <t>field</t> <dl> <dt>Format: </dt> <dd>QSTRING </dd> <dt>Field value:a</dt> <dd>a string for providing further information in case the signed JWT was rejected, e.g., for debuggingpurposes.</t> <t>occurrence: there MUSTpurposes. </dd> <dt>Occurrence: </dt> <dd>there <bcp14>MUST</bcp14> be zero or exactly one instance of thisfield.</t> </list></t> </list></t>field. </dd> </dl> </li> </ul> </section> </section> <section anchor="operation"title="URInumbered="true" toc="default"> <name>URI Signing MessageFlow">Flow</name> <t>URI Signing supports both HTTP-based and DNS-based request routing. <xreftarget="RFC7519">JSONtarget="RFC7519" format="default">JSON Web Token (JWT)</xref> defines a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a Signed JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC).</t> <section anchor="http"title="HTTP Redirection">numbered="true" toc="default"> <name>HTTP Redirection</name> <t>For HTTP-based request routing, a set of information that is unique to a given end user content request is included in a Signed JWT, using key information that is specific to a pair of adjacent CDNI hops (e.g., between the CSP and the uCDN or between the uCDN and a dCDN). This allows a CDNI hop to ascertain the authenticity of a given request received from a previous CDNI hop.</t> <t>The URI Signing method (assuming HTTP redirection, iterative request routing, and a CDN path with two CDNs) includes the following steps:</t> <figureanchor="fig_http_routing" title="HTTP-basedanchor="fig_http_routing"> <name>HTTP-Based Request Routing with URISigning"> <artwork>Signing</name> <artwork name="" type="" align="left" alt=""><![CDATA[ End-User dCDN uCDN CSP | | | | | 1.CDNI FCI interface used to | | | advertise URI Signing capability| | ||------------------->||------------------->| | | | | | | 2.Provides information to verify Signed JWT | | ||<-------------------||<-------------------| | | | | | 3.CDNI Metadata interface used to| | | provide URI Signing attributes| | ||<-------------------||<-------------------| | : : : : : (Later in time) : : : |4.Authorization request | ||------------------------------------------------------------->||------------------------------------------------------------->| | | | [Apply distribution | | | policy] | | | | | | | (ALT: Authorization decision) |5.Request is denied | |<Negative><Negative> ||<-------------------------------------------------------------||<-------------------------------------------------------------| | | | | |6.CSP provides signed URI |<Positive><Positive> ||<-------------------------------------------------------------||<-------------------------------------------------------------| | | | | |7.Content request | | ||---------------------------------------->| [Verifiy|---------------------------------------->| [Verify URI | | | | signature] | | | | | | | (ALT: Verification result) | |8.Request is denied |<Negative>|<Negative>| ||<----------------------------------------||<----------------------------------------| | | | | | |9.Re-sign URI and redirect to<Positive>|<Positive>| | | dCDN (newly signed URI) | ||<----------------------------------------||<----------------------------------------| | | | | | |10.Content request | | ||------------------->||------------------->| [Verify URI | | | | signature] | | | | | | | (ALT: Verification result) | | |11.Request is denied|<Negative><Negative> | ||<-------------------||<-------------------| | | | | | | |12.Content delivery |<Positive><Positive> | ||<-------------------||<-------------------| | | : : : : : (Later in time) : : : |13.CDNI Logging interface to include URI Signing information | ||------------------->| |</artwork>|------------------->| |]]></artwork> </figure><t><list style="numbers"> <t>Using<ol spacing="normal" type="1"><li>Using the CDNI Footprint & Capabilities Advertisement interface, the dCDN advertises its capabilities including URI Signing support to theuCDN.</t> <t>CSPuCDN.</li> <li>CSP provides to the uCDN the information needed to verify signed URIs from that CSP. For example, this information will include one or more keys used forvalidation.</t> <t>Usingvalidation.</li> <li>Using the CDNI Metadata interface, the uCDN communicates to a dCDN the information needed to verify signed URIs from the uCDN for the given CSP. For example, this information may include the URI query string parameter name for the URI Signing Package Attribute in addition to keys used forvalidation.</t> <t>Whenvalidation.</li> <li>When a UA requests a piece of protected content from the CSP, the CSP makes a specific authorization decision for this unique request based on its local distributionpolicy.</t> <t>Ifpolicy.</li> <li>If the authorization decision is negative, the CSP rejects the request and sends an error code (e.g., 403 Forbidden) in the HTTPresponse.</t> <t>Ifresponse.</li> <li>If the authorization decision is positive, the CSP computes a Signed JWT that is based on unique parameters of that request and conveys it to the end user as the URI to use to request thecontent.</t> <t>Oncontent.</li> <li>On receipt of the corresponding content request, the uCDN verifies the Signed JWT in the URI using the information provided by theCSP.</t> <t>IfCSP.</li> <li>If the verification result is negative, the uCDN rejects the request and sends an error code 403 Forbidden in the HTTPresponse.</t> <t>Ifresponse.</li> <li>If the verification result is positive, the uCDN computes a Signed JWT that is based on unique parameters of that request and provides it to the end user as the URI to use to further request the content from thedCDN.</t> <t>OndCDN.</li> <li>On receipt of the corresponding content request, the dCDN verifies the Signed JWT in the signed URI using the information provided by the uCDN in the CDNIMetadata.</t> <t>IfMetadata.</li> <li>If the verification result is negative, the dCDN rejects the request and sends an error code 403 Forbidden in the HTTPresponse.</t> <t>Ifresponse.</li> <li>If the verification result is positive, the dCDN serves the request and delivers thecontent.</t> <t>Atcontent.</li> <li>At a later time, the dCDN reports logging events that include URI Signinginformation.</t> </list></t>information.</li> </ol> <t>With HTTP-based request routing, URI Signing matches well the general chain of trust model of CDNI both with symmetric and asymmetric keys because the key information only needs to be specific to a pair of adjacent CDNI hops.</t> <t>Note: While using a symmetric shared key is supported, it isNOT RECOMMENDED.<bcp14>NOT RECOMMENDED</bcp14>. See the <xreftarget="security">Securitytarget="security" format="default">Security Considerations</xref>sectionabout the limitations of shared keys.</t> </section> <section anchor="dns"title="DNS Redirection">numbered="true" toc="default"> <name>DNS Redirection</name> <t>For DNS-based request routing, the CSP and uCDN must agree on a trust model appropriate to the security requirements of the CSP's particular content. Use of asymmetric public/private keys allows for unlimited distribution of the public key to dCDNs. However, if a shared secret key is required, then the distributionSHOULD<bcp14>SHOULD</bcp14> be performed by the CSP directly.</t> <t>Note: While using a symmetric shared key is supported, it isNOT RECOMMENDED.<bcp14>NOT RECOMMENDED</bcp14>. See the <xreftarget="security">Securitytarget="security" format="default">Security Considerations</xref>sectionabout the limitations of shared keys.</t> <t>The URI Signing method (assuming iterative DNS request routing and a CDN path with two CDNs) includes the following steps.</t> <!-- [rfced] The acronym FCI is not expanded prior to its first use in Figure 3. May we add its definition to the terminolgy section? Perhaps: FCI: the Footprint & Capabilities Advertisement interface --> <!-- [rfced] This document uses "FCI interface" despite "interface" being represented in the acronym itself. May we remove "interface" after both intstances of FCI? --> <figureanchor="fig_dns_routing" title="DNS-basedanchor="fig_dns_routing"> <name>DNS-based Request Routing with URISigning"> <artwork>Signing</name> <artwork name="" type="" align="left" alt=""><![CDATA[ End-User dCDN uCDN CSP | | | | | 1.CDNI FCI interface used to | | | advertise URI Signing capability| | ||------------------->||------------------->| | | | | | | 2.Provides information to verify Signed JWT | | ||<-------------------||<-------------------| | 3.CDNI Metadata interface used to| | | provide URI Signing attributes| | ||<-------------------||<-------------------| | : : : : : (Later in time) : : : |4.Authorization request | ||------------------------------------------------------------->||------------------------------------------------------------->| | | | [Apply distribution | | | policy] | | | | | | | (ALT: Authorization decision) |5.Request is denied | |<Negative><Negative> ||<-------------------------------------------------------------||<-------------------------------------------------------------| | | | | |6.Provides signed URI |<Positive><Positive> ||<-------------------------------------------------------------||<-------------------------------------------------------------| | | | | |7.DNS request | | ||---------------------------------------->||---------------------------------------->| | | | | | |8.Redirect DNS to dCDN | ||<----------------------------------------||<----------------------------------------| | | | | | |9.DNS request | | ||------------------->||------------------->| | | | | | | |10.IP address of Surrogate | ||<-------------------||<-------------------| | | | | | | |11.Content request | | ||------------------->||------------------->| [Verify URI | | | | signature] | | | | | | | (ALT: Verification result) | | |12.Request is denied|<Negative><Negative> | ||<-------------------||<-------------------| | | | | | | |13.Content delivery |<Positive><Positive> | ||<-------------------||<-------------------| | | : : : : : (Later in time) : : : |14.CDNI Logging interface to report URI Signing information | ||------------------->||------------------->| |</artwork>]]></artwork> </figure><t><list style="numbers"> <t>Using<ol spacing="normal" type="1"> <li>Using the CDNI Footprint & Capabilities Advertisement interface, the dCDN advertises its capabilities including URI Signing support to theuCDN.</t> <t>CSPuCDN.</li> <li>CSP provides to the uCDN the information needed to verify Signed JWTs from that CSP. For example, this information will include one or more keys used forvalidation.</t> <t>Usingvalidation.</li> <li>Using the CDNI Metadata interface, the uCDN communicates to a dCDN the information needed to verify Signed JWTs from the CSP (e.g., the URI query string parameter name for the URI Signing Package Attribute). In the case of symmetric shared key, the uCDNMUST NOT<bcp14>MUST NOT</bcp14> share the key with adCDN.</t> <t>WhendCDN.</li> <li>When a UA requests a piece of protected content from the CSP, the CSP makes a specific authorization decision for this unique request based on its local distributionpolicy.</t> <t>Ifpolicy.</li> <li>If the authorization decision is negative, the CSP rejects the request and sends an error code (e.g., 403 Forbidden) in the HTTPresponse.</t> <t>Ifresponse.</li> <li>If the authorization decision is positive, the CSP computes a Signed JWT that is based on unique parameters of that request and includes it in the URI provided to the end user to request thecontent.</t> <t>Endcontent.</li> <li>The end user sends a DNS request to theuCDN.</t> <t>OnuCDN.</li> <li>On receipt of the DNS request, the uCDN redirects the request to thedCDN.</t> <t>EnddCDN.</li> <li>The end user sends a DNS request to thedCDN.</t> <t>OndCDN.</li> <li>On receipt of the DNS request, the dCDN responds with IP address of one of itsSurrogates.</t> <t>OnSurrogates.</li> <li>On receipt of the corresponding content request, the dCDN verifies the Signed JWT in the URI using the information provided by the uCDN in the CDNIMetadata.</t> <t>IfMetadata.</li> <li>If the verification result is negative, the dCDN rejects the request and sends an error code 403 Forbidden in the HTTPresponse.</t> <t>Ifresponse.</li> <li>If the verification result is positive, the dCDN serves the request and delivers thecontent.</t> <t>Atcontent.</li> <li>At a later time, dCDN reports logging events that includes URI Signinginformation.</t> </list></t>information.</li> </ol> <t>With DNS-based request routing, URI Signing matches well the general chain of trust model of CDNI when used with asymmetric keys because the only key information that needs to be distributed across multiple, possibly untrusted, CDNI hops is the public key, which is generally not confidential.</t> <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 because the symmetric key information needs to be distributed across multiple CDNIhops,hops to CDNs with which the CSP may not have a trust relationship. This raises a security concern for applicability of URI Signing with symmetric keys in case of DNS-based inter-CDN request routing. Due to these flaws, this architectureMUST NOT<bcp14>MUST NOT</bcp14> be implemented.</t> <t>Note: While using a symmetric shared key is supported, it isNOT RECOMMENDED.<bcp14>NOT RECOMMENDED</bcp14>. See the <xreftarget="security">Securitytarget="security" format="default">Security Considerations</xref>sectionabout the limitations of shared keys.</t> </section> </section> <section anchor="sec.IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <section anchor="sec.IANA.payload"title="CDNInumbered="true" toc="default"> <name>CDNI PayloadType"> <t>This document requests the registration ofType</name> <t>IANA has registered the following CDNI Payload Type under the IANA "CDNI Payload Types" registry:</t><texttable> <ttcol<table align="center"> <thead> <tr> <th align="left">PayloadType</ttcol> <ttcol align="left">Specification</ttcol> <c>MI.UriSigning</c> <c>RFCthis</c> </texttable> <t>[RFC Editor: Please replace RFCthis with the published RFC number for this document.]</t>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> <section anchor="sec.IANA.payload.UriSigning"title="CDNInumbered="true" toc="default"> <name>CDNI UriSigning PayloadType"> <t>Purpose: TheType</name> <dl> <dt>Purpose: </dt> <dd>The purpose of this payload type is to distinguish UriSigningMIMetadata interface (MI) objects (and any associated capabilityadvertisement).</t> <t>Interface: MI/FCI</t> <t>Encoding: see <xref target="metadata"/></t>advertisement). </dd> <dt>Interface: </dt> <dd>MI/FCI </dd> <dt>Encoding: </dt> <dd>see <xref target="metadata" format="default"/> </dd> </dl> </section> </section> <section anchor="sec.IANA.logging_record"title="CDNInumbered="true" toc="default"> <name>CDNI Logging RecordType"> <t>This document requests the registration ofType</name> <t>IANA has registered the following CDNI Logging record-type under the IANA "CDNI Logging record-types" registry:</t><texttable> <ttcol align="left">record-types</ttcol> <ttcol align="left">Reference</ttcol> <ttcol align="left">Description</ttcol> <c>cdni_http_request_v2</c> <c>RFCthis</c> <c>Extension<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 content delivery using HTTP, to include URI Signinglogging fields</c> </texttable> <t>[RFC Editor: Please replace RFCthis with the published RFC number for this document.]</t>Logging fields</td> </tr> </tbody> </table> <section anchor="sec.IANA.record_type.cdni_http_request_v2"title="CDNInumbered="true" toc="default"> <name>CDNI Logging Record Version 2 forHTTP">HTTP</name> <t>The "cdni_http_request_v2" record-type supports all of the fields supported by the "cdni_http_request_v1" record-type <xreftarget="RFC7937"/>target="RFC7937" format="default"/> plus the two additional fields "s-uri-signing" and "s-uri-signing-deny-reason", registered by this document in <xreftarget="sec.IANA.fields"/>.target="sec.IANA.fields" format="default"/>. The name, format, field value, andoccurenceoccurrence information for the two new fields can be found in <xreftarget="logging"/>target="logging" format="default"/> of this document.</t> </section> </section> <section anchor="sec.IANA.fields"title="CDNInumbered="true" toc="default"> <name>CDNI Logging FieldNames"> <t>This document requests the registration ofNames</name> <t>IANA has registered the following CDNI Logging fields under the IANA "CDNI Logging Field Names" registry:</t><texttable> <ttcol<table align="center"> <thead> <tr> <th align="left">FieldName</ttcol> <ttcol align="left">Reference</ttcol> <c>s-uri-signing</c> <c>RFCthis</c> <c>s-uri-signing-deny-reason</c> <c>RFCthis</c> </texttable> <t>[RFC Editor: Please replace RFCthis with the published RFC number for this document.]</t>Name</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">s-uri-signing</td> <td align="left">RFC 9246</td> </tr> <tr> <td align="left">s-uri-signing-deny-reason</td> <td align="left">RFC 9246</td> </tr> </tbody> </table> </section> <section anchor="sec.IANA.field.s-uri-signing.values"title="CDNInumbered="true" toc="default"> <name>CDNI URI Signing VerificationCode"> <t>The IANA is requested to createCode</name> <t>IANA has created a new "CDNI URI Signing Verification Code"subregistry,subregistry in the "Content Delivery Networks Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing Verification Code" namespace defines the valid values associated with the s-uri-signing CDNI LoggingField.field. The CDNI URI Signing Verification Code is a 3DIGIT value as defined in <xreftarget="logging"/>.target="logging" format="default"/>. Additions to the CDNI URI Signing Verification Code namespace will conform to the "Specification Required" policy as defined in <xreftarget="RFC8126"/>.target="RFC8126" format="default"/>. Updates to this subregistry are expected to be infrequent.</t><texttable> <ttcol align="left">Value</ttcol> <ttcol align="left">Reference</ttcol> <ttcol align="left">Description</ttcol> <c>000</c> <c>RFCthis</c> <c>No<table align="center"> <thead> <tr> <th align="left">Value</th> <th align="left">Reference</th> <th align="left">Description</th> </tr> </thead> <tbody> <tr> <td align="left">000</td> <td align="left">RFC 9246</td> <td align="left">No signed JWT verificationperformed</c> <c>200</c> <c>RFCthis</c> <c>Signedperformed</td> </tr> <tr> <td align="left">200</td> <td align="left">RFC 9246</td> <td align="left">Signed JWT verification performed andverified</c> <c>400</c> <c>RFCthis</c> <c>Signedverified</td> </tr> <tr> <td align="left">400</td> <td align="left">RFC 9246</td> <td align="left">Signed JWT verification performed and rejected because of incorrectsignature</c> <c>401</c> <c>RFCthis</c> <c>Signedsignature</td> </tr> <tr> <td align="left">401</td> <td align="left">RFC 9246</td> <td align="left">Signed JWT verification performed and rejected because of Issuerenforcement</c> <c>402</c> <c>RFCthis</c> <c>Signedenforcement</td> </tr> <tr> <td align="left">402</td> <td align="left">RFC 9246</td> <td align="left">Signed JWT verification performed and rejected because of Subjectenforcement</c> <c>403</c> <c>RFCthis</c> <c>Signedenforcement</td> </tr> <tr> <td align="left">403</td> <td align="left">RFC 9246</td> <td align="left">Signed JWT verification performed and rejected because of Audienceenforcement</c> <c>404</c> <c>RFCthis</c> <c>Signedenforcement</td> </tr> <tr> <td align="left">404</td> <td align="left">RFC 9246</td> <td align="left">Signed JWT verification performed and rejected because of Expiration Timeenforcement</c> <c>405</c> <c>RFCthis</c> <c>Signedenforcement</td> </tr> <tr> <td align="left">405</td> <td align="left">RFC 9246</td> <td align="left">Signed JWT verification performed and rejected because of Not Beforeenforcement</c> <c>406</c> <c>RFCthis</c> <c>Signedenforcement</td> </tr> <tr> <td align="left">406</td> <td align="left">RFC 9246</td> <td align="left">Signed JWT verification performed and rejected because only one of CDNI Signed Token Transport or CDNI Expiration Time Settingpresent.</c> <c>407</c> <c>RFCthis</c> <c>Signedpresent</td> </tr> <tr> <td align="left">407</td> <td align="left">RFC 9246</td> <td align="left">Signed JWT verification performed and rejected because of JWT IDenforcement</c> <c>408</c> <c>RFCthis</c> <c>Signedenforcement</td> </tr> <tr> <td align="left">408</td> <td align="left">RFC 9246</td> <td align="left">Signed JWT verification performed and rejected because of Versionenforcement</c> <c>409</c> <c>RFCthis</c> <c>Signedenforcement</td> </tr> <tr> <td align="left">409</td> <td align="left">RFC 9246</td> <td align="left">Signed JWT verification performed and rejected because of Critical Extensionenforcement</c> <c>410</c> <c>RFCthis</c> <c>Signedenforcement</td> </tr> <tr> <td align="left">410</td> <td align="left">RFC 9246</td> <td align="left">Signed JWT verification performed and rejected because of Client IPenforcement</c> <c>411</c> <c>RFCthis</c> <c>Signedenforcement</td> </tr> <tr> <td align="left">411</td> <td align="left">RFC 9246</td> <td align="left">Signed JWT verification performed and rejected because of URI Containerenforcement</c> <c>500</c> <c>RFCthis</c> <c>Unableenforcement</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 malformedURI</c> </texttable> <t>[RFC Editor: Please replace RFCthis with the published RFC number for this document.]</t>URI</td> </tr> </tbody> </table> </section> <section anchor="sec.IANA.cdnistt"title="CDNInumbered="true" toc="default"> <name>CDNI URI Signing Signed TokenTransport"> <t>The IANA is requested to createTransport</name> <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 <xreftarget="RFC8126"/>.target="RFC8126" format="default"/>. Updates to this subregistry are expected to be infrequent.</t> <t>The following table defines the initial Enforcement Information Elements:</t><texttable> <ttcol align='left'>Value</ttcol> <ttcol align='left'>Description</ttcol> <ttcol align='left'>RFC</ttcol> <c>0</c> <c>Designates<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 notenabled</c> <c>RFCthis</c> <c>1</c> <c>Designatesenabled</td> <td align="left">RFC 9246</td> </tr> <tr> <td align="left">1</td> <td align="left">Designates token transport viacookie</c> <c>RFCthis</c> <c>2</c> <c>Designatescookie</td> <td align="left">RFC 9246</td> </tr> <tr> <td align="left">2</td> <td align="left">Designates token transport via querystring</c> <c>RFCthis</c> </texttable> <t>[RFC Editor: Please replace RFCthis with the published RFC number for this document.]</t>string</td> <td align="left">RFC 9246</td> </tr> </tbody> </table> </section> <section anchor="ClaimsReg"title="JSONnumbered="true" toc="default"> <name>JSON Web Token ClaimsRegistration">Registration</name> <t> This specification registers the followingClaimsclaims in the IANA "JSON Web Token Claims" registry <xreftarget="IANA.JWT.Claims"/>target="IANA.JWT.Claims" format="default"/> established by <xref target="RFC7519"/>. </t> <sectionanchor='ClaimsContents' title='Registry Contents'> <t> <?rfc subcompact="yes"?> <list style="symbols"> <t>Claimanchor="ClaimsContents" numbered="true" toc="default"> <name>Registry Contents</name> <dl spacing="compact"> <dt>Claim Name:<spanx style="verb">cdniv</spanx></t> <t>Claim</dt> <dd> <tt>cdniv</tt> </dd> <dt>Claim Description:CDNI</dt> <dd>CDNI Claim SetVersion</t> <t>ChangeVersion </dd> <dt>Change Controller:IESG</t> <t>Specification</dt> <dd>IESG </dd> <dt>Specification Document(s):<xref target="cdniv_claim"/> of [[ this specification ]]</t> </list> </t> <?rfc subcompact="no"?> <t> <?rfc subcompact="yes"?> <list style="symbols"> <t>Claim</dt> <dd><xref target="cdniv_claim" format="default"/> of </dd> </dl> <dl spacing="compact"> <dt>Claim Name:<spanx style="verb">cdnicrit</spanx></t> <t>Claim</dt> <dd><tt>cdnicrit</tt> </dd> <dt>Claim Description:CDNI</dt> <dd>CDNI Critical ClaimsSet</t> <t>ChangeSet </dd> <dt>Change Controller:IESG</t> <t>Specification</dt> <dd>IESG </dd> <dt>Specification Document(s):<xref target="cdnicrit_claim"/></dt> <dd><xref target="cdnicrit_claim" format="default"/> of[[ this specification ]]</t> </list> </t> <?rfc subcompact="no"?> <t> <?rfc subcompact="yes"?> <list style="symbols"> <t>ClaimRFC 9246 </dd> </dl> <dl spacing="compact"> <dt>Claim Name:<spanx style="verb">cdniip</spanx></t> <t>Claim</dt> <dd><tt>cdniip</tt> </dd> <dt>Claim Description:CDNI</dt> <dd>CDNI IPAddress</t> <t>ChangeAddress </dd> <dt>Change Controller:IESG</t> <t>Specification</dt> <dd>IESG </dd> <dt>Specification Document(s):<xref target="cdniip_claim"/> of [[ this specification ]]</t> </list> </t> <?rfc subcompact="no"?> <t> <?rfc subcompact="yes"?> <list style="symbols"> <t>Claim</dt> <dd><xref target="cdniip_claim" format="default"/> of </dd> </dl> <dl spacing="compact"> <dt>Claim Name:<spanx style="verb">cdniuc</spanx></t> <t>Claim</dt> <dd><tt>cdniuc</tt> </dd> <dt>Claim Description:CDNI</dt> <dd>CDNI URIContainer</t> <t>ChangeContainer </dd> <dt>Change Controller:IESG</t> <t>Specification</dt> <dd>IESG </dd> <dt>Specification Document(s):<xref target="cdniuc_claim"/> of [[ this specification ]]</t> </list> </t> <?rfc subcompact="no"?> <t> <?rfc subcompact="yes"?> <list style="symbols"> <t>Claim</dt> <dd><xref target="cdniuc_claim" format="default"/> of </dd> </dl> <dl spacing="compact"> <dt>Claim Name:<spanx style="verb">cdniets</spanx></t> <t>Claim</dt> <dd><tt>cdniets</tt> </dd> <dt>Claim Description:CDNI</dt> <dd>CDNI Expiration Time Setting for Signed TokenRenewal</t> <t>ChangeRenewal </dd> <dt>Change Controller:IESG</t> <t>Specification</dt> <dd>IESG </dd> <dt>Specification Document(s):<xref target="cdniets_claim"/></dt> <dd><xref target="cdniets_claim" format="default"/> of[[ this specification ]]</t> </list> </t> <?rfc subcompact="no"?> <t> <?rfc subcompact="yes"?> <list style="symbols"> <t>ClaimRFC 9246 </dd> </dl> <dl spacing="compact"> <dt>Claim Name:<spanx style="verb">cdnistt</spanx></t> <t>Claim</dt> <dd><tt>cdnistt</tt> </dd> <dt>Claim Description:CDNI</dt> <dd>CDNI Signed Token Transport Method for Signed TokenRenewal</t> <t>ChangeRenewal </dd> <dt>Change Controller:IESG</t> <t>Specification</dt> <dd>IESG </dd> <dt>Specification Document(s):<xref target="cdnistt_claim"/></dt> <dd><xref target="cdnistt_claim" format="default"/> of[[ this specification ]]</t> </list> </t> <?rfc subcompact="no"?> <t> <?rfc subcompact="yes"?> <list style="symbols"> <t>ClaimRFC 9246 </dd> </dl> <dl spacing="compact"> <dt>Claim Name:<spanx style="verb">cdnistd</spanx></t> <t>Claim</dt> <dd><tt>cdnistd</tt> </dd> <dt>Claim Description:CDNI</dt> <dd>CDNI Signed TokenDepth</t> <t>ChangeDepth </dd> <dt>Change Controller:IESG</t> <t>Specification</dt> <dd>IESG </dd> <dt>Specification Document(s):<xref target="cdnistd_claim"/></dt> <dd><xref target="cdnistd_claim" format="default"/> of[[ this specification ]]</t> </list> </t> <?rfc subcompact="no"?>RFC 9246 </dd> </dl> </section> </section> <section anchor="expertreview"title="Expertnumbered="true" toc="default"> <name>Expert ReviewGuidance">Guidance</name> <t>Generally speaking, we should determine the registration has a rational justification and does not duplicate a previous registration. Early assignment should be permissible as long as there is a reasonable expectation that the specification will become formalized. Expert Reviewers should be empowered to make determinations, but generally speaking they should allow new claims that do not otherwise introduce conflicts with implementation or things that may lead to confusion. They should also follow the guidelines of <xreftarget="RFC8126"/> Section 5target="RFC8126" sectionFormat="of" section="5" format="default"/> when sensible.</t> </section> </section> <section anchor="security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>This document describes the concept of URI Signing and how it can be used to provide access authorization in the case of CDNI. The primary goal of URI Signing is to make sure that only authorized UAs are able to access the content, with a CSP being able to authorize every individual request. It should be noted that URI Signing is not a content protection scheme; if a CSP wants to protect the content itself, other mechanisms, such as DRM, are more appropriate.</t> <t>CDNI URI Signing Signed Tokens leverage JSON Web Tokens andthusthus, guidelines in <xreftarget="RFC8725"/>target="RFC8725" format="default"/> are applicable for all JWT interactions.</t> <t>In general, it holds that the level of protection against illegitimate access can be increased by including more claims in the signed JWT. The current version of this document includes claims for enforcing Issuer, Client IP Address, Not Before time, and ExpirationTime, howeverTime; however, this list can be extended withother,other morecomplex,complex attributes that are able to provide some form of protection against some of the vulnerabilities highlighted below.</t> <t>That said, there are a number of aspects that limit the level of security offered by URI Signing and that anybody implementing URI Signing should be aware of.</t><t><list style="symbols"> <t>Replay<dl> <dt>Replay attacks:A</dt> <dd>A (valid) Signed URI may be used to perform replay attacks. The vulnerability to replay attacks can be reduced by picking a relatively short window between the Not Before time and Expiration Time attributes, although this is limited by the fact that any HTTP-based request needs a window of at least a couple of seconds to prevent sudden network issues from denying legitimate UAs access to the content. One may also reduce exposure to replay attacks by including a unique one-time access ID via the JWT ID attribute (jti claim). Whenever the dCDN receives a request with a given unique ID, it adds that ID to the list of 'used' IDs. In the case an illegitimate UA tries to use the same URI through a replay attack, the dCDN can deny the request based on thealready-usedalready used access ID. This list should be kept bounded. A reasonable approach would be to expire the entries based on the exp claim value. If no exp claim is present, then a simple LRU could be used; however, this would allow values to eventually be reused. <!-- [rfced] In the following sentence, what is the intended expansion for "LRU"? Is "Least Recently Used (LRU) value" correct? Original: If no exp claim is present then a simple LRU could be used, however this would allow values to eventually bereused.</t> <t>Illegitimatereused. Perhaps: If no exp claim is present, then a simple Least Recently Used (LRU) value could be used; however, this would allow values to eventually be reused. --> </dd> <dt>Illegitimate clients behind a NAT:In</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 IPAddressAddress, 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 sophisticatedattacker.</t> </list></t>attacker. </dd> </dl> <t>A shared keydistribureddistributed between CSP and uCDN is more likely to be compromised. Since this key can be used to legitimately sign a URL for content access authorization, it is important to know the implications of a compromised shared key. While using a shared key scheme can be convenient, this architecture isNOT RECOMMENDED<bcp14>NOT RECOMMENDED</bcp14> due to the risks associated. It is included for legacy feature parity and is highly discouraged in new implementations.</t> <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 evaluate prohibitively expensive regular expressions embedded in a URI Container (cdniuc) claim. As a result, compromised keys should be timely revoked in order to prevent exploitation.</t> <t>The URI Container (cdniuc) claim can be given a wildcard value. This, combined with the fact that it is the only mandatory claim, means you can effectively make a skeleton key. Doing this does not sufficiently limit the scope of the JWT and isNOT RECOMMENDED.<bcp14>NOT RECOMMENDED</bcp14>. The only way to prevent such a key from being used after it is distributed is to revoke the signing key so it no longer validates.</t> </section> <sectiontitle="Privacy">numbered="true" toc="default"> <name>Privacy</name> <t>The privacy protection concerns described in "<xref target="RFC7937" format="title"/>" <xreftarget="RFC7937">CDNI Logging Interface</xref>target="RFC7937" /> apply when the client's IP address (cdniip) or Subject (sub) is embedded in the Signed URI. For this reason, the mechanism described in <xreftarget="jwt_profile"/>target="jwt_profile" format="default"/> encrypts the Client IP or Subject before including it in the URI Signing Package (and thus the URL itself).</t> </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 certain 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> <back><references title="Normative References"> <?rfc include='reference.RFC.2119'?> <?rfc include='reference.RFC.8174'?> <?rfc include='reference.RFC.7937'?> <?rfc include='reference.RFC.7230'?> <?rfc include='reference.RFC.8259'?> <?rfc include='reference.RFC.7519'?> <?rfc include='reference.RFC.7516'?> <?rfc include='reference.RFC.8006'?> <?rfc include='reference.RFC.6920'?> <?rfc include='reference.RFC.8126'?> <?rfc include='reference.RFC.0791'?> <?rfc include='reference.RFC.3986'?> <?rfc include='reference.RFC.5952'?> <?rfc include='reference.RFC.6265'?> <?rfc include='reference.RFC.6707'?> <?rfc include='reference.RFC.5905'?> <?rfc include='reference.RFC.6570'?><references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7937.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7516.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8006.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6920.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5952.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6265.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6707.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6570.xml"/> <!-- [POSIX.1] The URL below is correct. Also, there exists https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/ --> <reference anchor="POSIX.1"target="http://pubs.opengroup.org/onlinepubs/9699919799/">target="https://pubs.opengroup.org/onlinepubs/9699919799/"> <front><title>The Open Group<title>IEEE Standard for Information Technology -- Portable Operating System Interface (POSIX(TM)) BaseSpecificationsSpecifications, Issue 7</title><author surname="IEEE"/><author> <organization>The Open Group </organization> </author> <dateday="31" month="Jan"month="January" year="2018"/> </front> <seriesInfo name="IEEE Std"value="1003.1 2018 Edition"/>value="1003.1-2017"/> <refcontent>(Revision of IEEE Std 1003.1-2008) </refcontent> </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'?><references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7336.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7337.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8008.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7975.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6983.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7517.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8216.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8725.xml"/> <reference anchor="IANA.JWT.Claims"target="http://www.iana.org/assignments/jwt">target="https://www.iana.org/assignments/jwt"> <front> <title>JSON Web TokenClaims</title>(JWT)</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> <!-- [rfced] Reference [MPEG-DASH] has been revised in a 2019 version. Should this be used instead of the current 2014 version (which has been withdrawn)? Current: [MPEG-DASH] ISO, "Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment format", ISO/IEC 23009-1:2014, Edition 2, May 2014, <http://www.iso.org/standard/65274.html>. --> <reference anchor="MPEG-DASH"target="http://www.iso.org/standard/65274.html">target="https://www.iso.org/standard/65274.html"> <front> <title>Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segmentformat</title>formats</title> <author> <organization>ISO</organization> </author> <datemonth="05"month="May" year="2014"/> </front> <seriesInfo name="ISO/IEC" value="23009-1:2014"/> <seriesInfo name="Edition" value="2"/> </reference> </references> </references> <sectiontitle="Signedanchor="sup_example" numbered="true" toc="default"> <name>Signed URI PackageExample" anchor="sup_example">Example</name> <t>This section contains three examples of token usage: a simple example with only the required claim present, a complex examplewhichthat demonstrates the full JWT claims set, including an encrypted Client IP Address (cdniip), and one that uses a Signed Token Renewal.</t> <t>Note: All of the examples have whitespace added to improve formatting and readability, but are not present in the generated content.</t> <t>All examples use the following JWK Set <xreftarget="RFC7517"/>:</t> <figure><artwork><![CDATA[target="RFC7517" format="default"/>:</t> <sourcecode><![CDATA[ { "keys": [ { "kty": "EC", "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", "use": "sig", "alg": "ES256", "crv": "P-256", "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA" }, { "kty": "EC", "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", "use": "sig", "alg": "ES256", "crv": "P-256", "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA", "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M" }, { "kty": "oct", "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998", "use": "enc", "alg": "A128GCM", "k": "4uFxxV7fhNmrtiah2d1fFg" } ]}]]></artwork></figure>]]></sourcecode> <t>Note: They are the public signing key, the private signing key, and the shared secretenctyptionencryption key, respectively. The public and private signing keys have the same fingerprint and only vary by the 'd' parameter that is missing from the public signing key.</t> <sectiontitle="Simple Example" anchor="simple_example">anchor="simple_example" numbered="true" toc="default"> <name>Simple Example</name> <t> This example is a simple common usage example containing a minimal subset of claims that the authors find most useful. </t> <t> The JWT Claim Set before signing: </t> <t> Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the URL Segment form (<xreftarget="RFC6920"/> Section 5)target="RFC6920" sectionFormat="of" section="5" format="default"/>) of "http://cdni.example/foo/bar". </t><figure><artwork><![CDATA[<!-- [rfced] The following line in Appendix A.1 exceeds the maximum 69-character width (for sourcecode) by one character. Is it possible to place a line break in this line? Current: "cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" --> <sourcecode><![CDATA[ { "exp": 1646867369, "iss": "uCDN Inc", "cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" }]]></artwork></figure>]]></sourcecode> <t> The signed JWT: </t><figure><artwork><![CDATA[<sourcecode><![CDATA[ eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE2NDY4NjczNjksImlzcyI6InVDRE4gS W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.TaNlJM3D96i_9J9XvlICO6FUIDFTqt3E2Y JkEUOLfcH0b89wYRKTbJ9Yj6h_GRgSoZoQO0cps3yUPcWGK3smCw]]></artwork></figure>]]></sourcecode> </section> <sectiontitle="Complex Example" anchor="complex_example">anchor="complex_example" numbered="true" toc="default"> <name>Complex Example</name> <t> This example uses all fields except for those dealing with Signed Token Renewal, including Client IP Address (cdniip) and Subject(sub)(sub), which areencrpyted.encrypted. This significantly increases the size of the signed JWT token. </t> <t> JWE for Client IP Address (cdniip) of [2001:db8::1/32]: </t><figure><artwork><![CDATA[<sourcecode><![CDATA[ eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..aUDDFEQBIc3nWjOb.bGXWT HPkntmPCKn0pPPNEQ.iyTttnFybO2YBLqwl_YSjA]]></artwork></figure>]]></sourcecode> <t> JWE for Subject (sub) of "UserToken": </t><figure><artwork><![CDATA[<sourcecode><![CDATA[ eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..CLAu80xclc8Bp-Ui.6P1A3 F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g]]></artwork></figure>]]></sourcecode> <t> The JWT Claim Set before signing: </t><figure><artwork><![CDATA[<sourcecode><![CDATA[ { "aud": "dCDN LLC", "sub": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4 QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..CLAu80xclc8B p-Ui.6P1A3F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g", "cdniip": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XY mp4QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..aUDDFEQBI c3nWjOb.bGXWTHPkntmPCKn0pPPNEQ.iyTttnFybO2YBLqwl_YSjA", "cdniv": 1, "exp": 1646867369, "iat": 1646694569, "iss": "uCDN Inc", "jti": "5DAafLhZAfhsbe", "nbf": 1646780969, "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png" }]]></artwork></figure>]]></sourcecode> <t> The signed JWT: </t><figure><artwork><![CDATA[<sourcecode><![CDATA[ eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5Smxib U1pT2lKQk1USTRSME5OSWl3aVlXeG5Jam9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA 0UWtNelpGQjFTVE5rTWpSclVESm9ablp2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T 0NKOS4uQ0xBdTgweGNsYzhCcC1VaS42UDFBM0Y2aXAyRHYuQ29oZHRMTHBnQm5UdlJ KUUNGdXotZyIsImNkbmlpcCI6ImV5SmxibU1pT2lKQk1USTRSME5OSWl3aVlXeG5Ja m9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA0UWtNelpGQjFTVE5rTWpSclVESm9ablp 2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T0NKOS4uYVVEREZFUUJJYzNuV2pPYi5iR 1hXVEhQa250bVBDS24wcFBQTkVRLml5VHR0bkZ5Yk8yWUJMcXdsX1lTakEiLCJjZG5 pdiI6MSwiZXhwIjoxNjQ2ODY3MzY5LCJpYXQiOjE2NDY2OTQ1NjksImlzcyI6InVDR E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE2NDY3ODA5NjksImN kbml1YyI6InJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL1swLTlde zN9XFwucG5nIn0.IjmVX0uD5MYqArc-M08uEsEeoDQn8kuYXZ9HGHDmDDxsHikT0c8 jcX8xYD0z3LzQclMG65i1kT2sRbZ7isUw8w]]></artwork></figure>]]></sourcecode> </section> <sectiontitle="Signedanchor="token_renewal_example" numbered="true" toc="default"> <name>Signed Token RenewalExample" anchor="token_renewal_example">Example</name> <t> This example uses fields for Signed Token Renewal. </t> <t> The JWT Claim Set before signing: </t><figure><artwork><![CDATA[<sourcecode><![CDATA[ { "cdniets": 30, "cdnistt": 1, "cdnistd": 2, "exp": 1646867369, "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" }]]></artwork></figure>]]></sourcecode> <t> The signed JWT: </t><figure><artwork><![CDATA[<sourcecode><![CDATA[ eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua XN0ZCI6MiwiZXhwIjoxNjQ2ODY3MzY5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.tlPvoKw3BCClw4Lx9 PQu7MK6b2IN55ZoCPSaxovGK0zS53Wpb1MbJBow7G8LiGR39h6-2Iq7PWUSr3MdTIz HYw]]></artwork></figure>]]></sourcecode> <t> Once the server verifies the signed JWT it will return a new signed JWT with an updatedexpiry timeExpiry Time (exp) as shown below. Note theexpiry timeExpiry Time is increased by the expiration time setting (cdniets) value. </t> <t> The JWT Claim Set before signing: </t><figure><artwork><![CDATA[<sourcecode><![CDATA[ { "cdniets": 30, "cdnistt": 1, "cdnistd": 2, "exp": 1646867399, "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" }]]></artwork></figure>]]></sourcecode> <t> The signed JWT: </t><figure><artwork><![CDATA[<sourcecode><![CDATA[ eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua XN0ZCI6MiwiZXhwIjoxNjQ2ODY3Mzk5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.ivY5d_fKGd-OHTpUs 8uJUrnHvt-rduzu5H4zM7167pUUAghub53FqDQ5G16jRYX2sY73mA_uLpYDdb-CPts 8FA]]></artwork></figure>]]></sourcecode> </section> </section> <section numbered="false" toc="default"> <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 certain 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 Adaptive Streaming.</t></li> <li><t><contact fullname="Matt Miller"/> provided consultation on JWT usage as well as code to generate working JWT examples.</t></li> </ul> <!--[rfced] Terminology. The following terms are used inconsistently in this document. Please let us know which form, if any, is preferred. signed URI vs. Signed URI issuer vs. Issuer JSON object vs. JSON Web Encryption Object --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. For example, please consider whether the following should be updated: "whitespace" --> </section> </back> </rfc>