draft-ietf-cdni-uri-signing-14.txt   draft-ietf-cdni-uri-signing-15.txt 
CDNI R. van Brandenburg CDNI R. van Brandenburg
Internet-Draft Tiledmedia Internet-Draft Tiledmedia
Intended status: Standards Track K. Leung Intended status: Standards Track K. Leung
Expires: September 6, 2018 Cisco Systems, Inc. Expires: April 25, 2019 Cisco Systems, Inc.
P. Sorber P. Sorber
March 5, 2018 Apple, Inc.
October 22, 2018
URI Signing for CDN Interconnection (CDNI) URI Signing for CDN Interconnection (CDNI)
draft-ietf-cdni-uri-signing-14 draft-ietf-cdni-uri-signing-15
Abstract Abstract
This document describes how the concept of URI signing supports the This document describes how the concept of URI signing supports the
content access control requirements of CDNI and proposes a URI content access control requirements of CDNI and proposes a URI
signing method as a JSON Web Token (JWT) [RFC7519] profile. signing method as a JSON Web Token (JWT) [RFC7519] profile.
The proposed URI signing method specifies the information needed to The proposed URI signing method specifies the information needed to
be included in the URI to transmit the signed JWT as well as the be included in the URI to transmit the signed JWT as well as the
claims needed by the signed JWT to authorize a UA. The mechanism claims needed by the signed JWT to authorize a UA. The mechanism
described can be used both in CDNI and single CDN scenarios. described can be used both in CDNI and single CDN scenarios.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 27 skipping to change at page 2, line 28
2. JWT Format and Processing Requirements . . . . . . . . . . . 9 2. JWT Format and Processing Requirements . . . . . . . . . . . 9
2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 10 2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 10
2.1.2. Subject (sub) claim . . . . . . . . . . . . . . . . . 10 2.1.2. Subject (sub) claim . . . . . . . . . . . . . . . . . 10
2.1.3. Audience (aud) claim . . . . . . . . . . . . . . . . 11 2.1.3. Audience (aud) claim . . . . . . . . . . . . . . . . 11
2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 11 2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 11
2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11 2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11
2.1.6. Issued At (iat) claim . . . . . . . . . . . . . . . . 12 2.1.6. Issued At (iat) claim . . . . . . . . . . . . . . . . 12
2.1.7. Nonce (jti) claim . . . . . . . . . . . . . . . . . . 12 2.1.7. Nonce (jti) claim . . . . . . . . . . . . . . . . . . 12
2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12 2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12
2.1.9. Client IP (cdniip) claim . . . . . . . . . . . . . . 12 2.1.9. CDNI Critical Claims Set (cdnicrit) claim . . . . . . 12
2.1.10. CDNI URI Container (cdniuc) claim . . . . . . . . . . 13 2.1.10. Client IP (cdniip) claim . . . . . . . . . . . . . . 13
2.1.11. CDNI Expiration Time Setting (cdniets) claim . . . . 13 2.1.11. CDNI URI Container (cdniuc) claim . . . . . . . . . . 13
2.1.12. CDNI Signed Token Transport (cdnistt) claim . . . . . 13 2.1.12. CDNI Expiration Time Setting (cdniets) claim . . . . 13
2.1.13. URI Container Forms . . . . . . . . . . . . . . . . . 14 2.1.13. CDNI Signed Token Transport (cdnistt) claim . . . . . 14
2.1.13.1. URI Simple Container (uri:) . . . . . . . . . . 14 2.1.14. CDNI Signed Token Depth (cdnistd) claim . . . . . . . 14
2.1.13.2. URI Regular Expression Container (uri-regex:) . 14 2.1.15. URI Container Forms . . . . . . . . . . . . . . . . . 15
2.1.13.3. URI Hash Container (uri-hash:) . . . . . . . . . 14 2.1.15.1. URI Hash Container (hash:) . . . . . . . . . . . 15
2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 15 2.1.15.2. URI Regular Expression Container (regex:) . . . 15
3. URI Signing Token Renewal . . . . . . . . . . . . . . . . . . 15 2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 3. URI Signing Token Renewal . . . . . . . . . . . . . . . . . . 16
3.2. Signed Token Renewal mechanism . . . . . . . . . . . . . 16 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1. Required Claims . . . . . . . . . . . . . . . . . . . 16 3.2. Signed Token Renewal mechanism . . . . . . . . . . . . . 17
3.3. Communicating a signed JWTs in Signed Token Renewal . . . 16 3.2.1. Required Claims . . . . . . . . . . . . . . . . . . . 17
3.3.1. Support for cross-domain redirection . . . . . . . . 17 3.3. Communicating a signed JWTs in Signed Token Renewal . . . 17
4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 17 3.3.1. Support for cross-domain redirection . . . . . . . . 18
4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 17 4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 18
4.2. CDNI Footprint & Capabilities Advertisement Interface . . 18 4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 18
4.3. CDNI Request Routing Redirection Interface . . . . . . . 18 4.2. CDNI Footprint & Capabilities Advertisement Interface . . 19
4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 18 4.3. CDNI Request Routing Redirection Interface . . . . . . . 19
4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 19 4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 19
5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 21 4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 20
5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 21 5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 22
5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 23 5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 24
6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 27 6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 27
6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 27 6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 28
6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 27 6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 28
6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 27 6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 28
6.4. CDNI URI Signing Signed Token Transport . . . . . . . . . 28 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 28
6.5. JSON Web Token Claims Registration . . . . . . . . . . . 28 6.4. CDNI URI Signing Signed Token Transport . . . . . . . . . 29
6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 28 6.5. JSON Web Token Claims Registration . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 29
8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Signed URI Package Example . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . 33
A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 34 Appendix A. Signed URI Package Example . . . . . . . . . . . . . 35
A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 35 A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 36
A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 36 A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This document describes the concept of URI Signing and how it can be This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of redirection used to provide access authorization in the case of redirection
between interconnected CDNs (CDNI) and between a Content Service between interconnected CDNs (CDNI) and between a Content Service
Provider (CSP) and a CDN. The primary goal of URI Signing is to make Provider (CSP) and a CDN. The primary goal of URI Signing is to make
sure that only authorized User Agents (UAs) are able to access the sure that only authorized User Agents (UAs) are able to access the
content, with a CSP being able to authorize every individual request. content, with a CSP being able to authorize every individual request.
It should be noted that URI Signing is not a content protection It should be noted that URI Signing is not a content protection
skipping to change at page 9, line 11 skipping to change at page 9, line 11
e.g., between a uCDN and a dCDN or between a CSP and a dCDN, there is e.g., between a uCDN and a dCDN or between a CSP and a dCDN, there is
nothing in the defined URI Signing method that precludes it from nothing in the defined URI Signing method that precludes it from
being used in a non-CDNI context. As such, the described mechanism being used in a non-CDNI context. As such, the described mechanism
could be used in a single-CDN scenario such as shown in Figure 1 in could be used in a single-CDN scenario such as shown in Figure 1 in
Section 1.2, for example to allow a CSP that uses different CDNs to Section 1.2, for example to allow a CSP that uses different CDNs to
only have to implement a single URI Signing mechanism. only have to implement a single URI Signing mechanism.
2. JWT Format and Processing Requirements 2. JWT Format and Processing Requirements
The concept behind URI Signing is based on embedding a signed JSON The concept behind URI Signing is based on embedding a signed JSON
Web Token (JWT) [RFC7519] in the UA request: The signed JWT contains Web Token (JWT) [RFC7519] in an http or https URI [RFC7230] (section
a number of claims that can be validated to ensure the UA has 2.7). The signed JWT contains a number of claims that can be
legitimate access to the content. validated to ensure the UA has legitimate access to the content.
This document specifies the following attribute for embedding a This document specifies the following attribute for embedding a
signed JWT in a Target CDN URI or Redirection URI: signed JWT in a Target CDN URI or Redirection URI:
o URI Signing Package (URISigningPackage): The URI attribute that o URI Signing Package (URISigningPackage): The URI attribute that
encapsulates all the URI Signing claims in a signed JWT encoded encapsulates all the URI Signing claims in a signed JWT encoded
format. This attribute is exposed in the Signed URI as a URI format. This attribute is exposed in the Signed URI as a URI
query parameter or as a URL path parameter. query parameter or as a URL path parameter.
The parameter name of the URI Signing Package Attribute is defined in The parameter name of the URI Signing Package Attribute is defined in
skipping to change at page 9, line 36 skipping to change at page 9, line 36
Package Attribute, the parameter name can be set by configuration Package Attribute, the parameter name can be set by configuration
(out of scope of this document). (out of scope of this document).
The URI Signing Package will be found by searching the URI, left-to- The URI Signing Package will be found by searching the URI, left-to-
right, for the following sequence: right, for the following sequence:
o a reserved character (as defined in [RFC3986] Section 2.2), o a reserved character (as defined in [RFC3986] Section 2.2),
o the URI Signing Package Attribute name, o the URI Signing Package Attribute name,
o if the last character of the URI Singing Package Attribute name is o if the last character of the URI Signing Package Attribute name is
not a reserved character, an equal symbol ('='), not a reserved character, an equal symbol ('='),
o and a sequence of non-reserved characters that will be interpreted o and a sequence of non-reserved characters that will be interpreted
as a signed JWT, as a signed JWT,
o terminated by either a reserved character or the end of the URI. o terminated by either a reserved character or the end of the URI.
The first such match will be taken to provide the signed JWT; the URI The first such match will be taken to provide the signed JWT; the URI
will not be searched for multiple signed JWTs. will not be searched for multiple signed JWTs.
skipping to change at page 10, line 19 skipping to change at page 10, line 19
requirements, the claim requirements can be set by configuration (out requirements, the claim requirements can be set by configuration (out
of scope of this document). of scope of this document).
The following claims (where the "JSON Web Token Claims" registry The following claims (where the "JSON Web Token Claims" registry
claim name is specified in parenthesis below) are used to enforce the claim name is specified in parenthesis below) are used to enforce the
distribution policies. All of the listed claims are mandatory to distribution policies. All of the listed claims are mandatory to
implement in a URI Signing implementation, but are not mandatory to implement in a URI Signing implementation, but are not mandatory to
use in a given signed JWT. (The "optional" and "mandatory" use in a given signed JWT. (The "optional" and "mandatory"
identifiers in square brackets refer to whether or not a given claim identifiers in square brackets refer to whether or not a given claim
MUST be present in a URI Signing JWT.) A CDN MUST be able to parse MUST be present in a URI Signing JWT.) A CDN MUST be able to parse
and process all of the claims listed below. If the signed JWT and process all of the claims listed below.
contains any other claims which the CDN does not understand (i.e., is
unable to parse and process), the CDN MUST reject the request.
Note: See the Security Considerations (Section 7) section on the Note: See the Security Considerations (Section 7) section on the
limitations of using an expiration time and client IP address for limitations of using an expiration time and client IP address for
distribution policy enforcement. distribution policy enforcement.
2.1.1. Issuer (iss) claim 2.1.1. Issuer (iss) claim
Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1 Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1
MUST be followed. This claim MAY be used to validate authorization MUST be followed. This claim MAY be used to validate authorization
of the issuer of a signed JWT and also MAY be used to confirm that of the issuer of a signed JWT and also MAY be used to confirm that
skipping to change at page 12, line 46 skipping to change at page 12, line 46
CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set
Version (cdniv) claim provides a means within a signed JWT to tie the Version (cdniv) claim provides a means within a signed JWT to tie the
claim set to a specific version of a specificiation. This is claim set to a specific version of a specificiation. This is
intended to allow changes in and facilitate upgrades across intended to allow changes in and facilitate upgrades across
specifications. The type is JSON integer and the value MUST be set specifications. The type is JSON integer and the value MUST be set
to "1", for this version of the specification. In the absence of to "1", for this version of the specification. In the absence of
this claim, the value is assumed to be "1". For future versions this this claim, the value is assumed to be "1". For future versions this
claim will be mandatory. Implementations MUST reject signed JWTs claim will be mandatory. Implementations MUST reject signed JWTs
with unsupported CDNI Claim Set versions. with unsupported CDNI Claim Set versions.
2.1.9. Client IP (cdniip) claim 2.1.9. CDNI Critical Claims Set (cdnicrit) claim
CDNI Critical Claims Set (cdnicrit) [optional] - The cdnicrit claim
indicates that extensions to this specification are being used that
MUST be understood and processed. Its value is a comma separated
listing of claims in the Signed JWT that use those extensions. If
any of the listed extension claims are not understood and supported
by the recipient, then the Signed JWT is invalid. Producers MUST NOT
include claim names defined by this specification, duplicate names,
or names that do not occur as claim names within the Signed JWT in
the cdnicrit list. Producers MUST NOT use the empty list "" as the
cdnicrit value. Recipients MAY consider the Signed JWT to be invalid
if the cdnicrit list contains any claim names defined by this
specification or if any other constraints on its use are violated.
This claim MUST be understood and processed by implementations.
2.1.10. Client IP (cdniip) claim
Client IP (cdniip) [optional] IP address, or IP prefix, for which the Client IP (cdniip) [optional] IP address, or IP prefix, for which the
Signed URI is valid. This is represented in CIDR notation, with Signed URI is valid. This is represented in CIDR notation, with
dotted decimal format for IPv4 or canonical text representation for dotted decimal format for IPv4 or canonical text representation for
IPv6 addresses [RFC5952]. The request is rejected if sourced from a IPv6 addresses [RFC5952]. The request is rejected if sourced from a
client outside of the specified IP range. Since the client IP is client outside of the specified IP range. Since the client IP is
considered personally identifiable information this field MUST be a considered personally identifiable information this field MUST be a
JSON Web Encryption (JWE [RFC7516]) Object in compact serialization JSON Web Encryption (JWE [RFC7516]) Object in compact serialization
form. If the CDN validating the signed JWT does not support Client form. If the CDN validating the signed JWT does not support Client
IP validation, or if the Client IP in the signed JWT does not match IP validation, or if the Client IP in the signed JWT does not match
the source IP address in the content request, the CDN MUST reject the the source IP address in the content request, the CDN MUST reject the
request. The type of this claim is a JSON string that contains 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 JWE. If the received signed JWT contains a Client IP claim, then any
JWT subsequently generated for CDNI redirection MUST also contain a JWT subsequently generated for CDNI redirection MUST also contain a
Client IP claim, and the Client IP value MUST be the same as in the Client IP claim, and the Client IP value MUST be the same as in the
received signed JWT. A signed JWT generated for CDNI redirection received signed JWT. A signed JWT generated for CDNI redirection
MUST NOT add a Client IP claim if no Client IP claim existed in the MUST NOT add a Client IP claim if no Client IP claim existed in the
received signed JWT. received signed JWT.
2.1.10. CDNI URI Container (cdniuc) claim 2.1.11. CDNI URI Container (cdniuc) claim
URI Container (cdniuc) [optional] - Container for holding the URI URI Container (cdniuc) [optional] - Container for holding the URI
representation before a URI Signing Package is added. This representation before a URI Signing Package is added. This
representation can take one of several forms detailed in representation can take one of several forms detailed in
Section 2.1.13. If the URI regex in the signed JWT does not match Section 2.1.15. If the URI regex in the signed JWT does not match
the URI of the content request, the CDN validating the signed JWT the URI of the content request, the CDN validating the signed JWT
MUST reject the request. When comparing the URI, the percent encoded MUST reject the request. When comparing the URI, the percent encoded
form as defined in [RFC3986] Section 2.1 MUST be used. When form as defined in [RFC3986] Section 2.1 MUST be used. When
redirecting a URI, the CDN generating the new signed JWT MAY change redirecting a URI, the CDN generating the new signed JWT MAY change
the URI Container to comport with the URI being used in the the URI Container to comport with the URI being used in the
redirection. redirection.
2.1.11. CDNI Expiration Time Setting (cdniets) claim 2.1.12. CDNI Expiration Time Setting (cdniets) claim
CDNI Expiration Time Setting (cdniets) [optional] - The CDNI CDNI Expiration Time Setting (cdniets) [optional] - The CDNI
Expiration Time Setting (cdniets) claim provides a means for setting Expiration Time Setting (cdniets) claim provides a means for setting
the value of the Expiry Time (exp) claim when generating a subsequent the value of the Expiry Time (exp) claim when generating a subsequent
signed JWT in Signed Token Renewal. Its type is a JSON numeric 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 value. It denotes the number of seconds to be added to the time at
which the JWT is validated that gives the value of the Expiry Time which the JWT is validated that gives the value of the Expiry Time
(exp) claim of the next signed JWT. The CDNI Expiration Time Setting (exp) claim of the next signed JWT. The CDNI Expiration Time Setting
(cdniets) SHOULD NOT be used when not using Signed Token Renewal and (cdniets) SHOULD NOT be used when not using Signed Token Renewal and
MUST be present when using Signed Token Renewal. MUST be present when using Signed Token Renewal.
2.1.12. CDNI Signed Token Transport (cdnistt) claim 2.1.13. CDNI Signed Token Transport (cdnistt) claim
CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed
Token Transport (cdnistt) claim provides a means of signalling the Token Transport (cdnistt) claim provides a means of signalling the
method through which a new signed JWT is transported from the CDN to 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 the UA and vice versa for the purpose of Signed Token Renewal. Its
type is a JSON integer. Values for this claim can be defined in type is a JSON integer. Values for this claim can be defined in
Section 6.4. If using this claim you MUST also specify a CDNI Section 6.4. If using this claim you MUST also specify a CDNI
Expiration Time Setting (cdniets) as noted above. Expiration Time Setting (cdniets) as noted above.
2.1.13. URI Container Forms 2.1.14. CDNI Signed Token Depth (cdnistd) claim
CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token
Depth (cdnistd) claim is used to associate a subsequent signed JWT
generated as the result of a CDNI Signed Token Transport claim with a
specific URI subset. Its type is a JSON integer. Signed JWTs MUST
NOT use a negative value for the CDNI Signed Token Depth claim.
If the transport used for Signed Token Transport allows the CDN to
associate the path component of a URI with tokens, the CDNI Signed
Token Depth value is the number of path segments that should be
considered significant for this association. A CDNI Signed Token
Depth of zero means that the client SHOULD be directed to return the
token with requests for any path. If the CDNI Signed Token Depth is
greater than zero, then the client SHOULD be directed to return the
token for future requests wherein the first CDNI Signed Token Depth
segments of the path match the first CDNI Signed Token Depth segments
of the signed URI path. This matching MUST use the URI with the
token removed, as specified in Section 2.1.15.
If the URI path to match contains fewer segments than the CDNI Signed
Token Depth claim, a signed JWT MUST NOT be generated for the
purposes of Signed Token Renewal. If the CDNI Signed Token Depth
claim is omitted, it means the same thing as if its value were zero.
If the received signed JWT contains a CDNI Signed Token Depth claim,
then any JWT subsequently generated for CDNI redirection or Signed
Token Transport MUST also contain a CDNI Signed Token Depth claim,
and the value MUST be the same as in the received signed JWT.
2.1.15. URI Container Forms
The URI Container (cdniuc) claim takes one of the following forms. The URI Container (cdniuc) claim takes one of the following forms.
More forms may be added in the future to extend the capabilities. More forms may be added in the future to extend the capabilities.
Before comparing a URI against this container, the signed JWT must be Before utilizing a URI with this container, the following steps MUST
removed from the URI. This removal is only for the purpose of be performed:
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 definined in [RFC3986] Section 2.2), everything
from the reserved character (as defined in [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.
2.1.13.1. URI Simple Container (uri:) o Prior to validation, 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 definined
in [RFC3986] Section 2.2), everything from the reserved character
(as defined in [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.
When prefixed with 'uri:', the string following 'uri:' is the URI o Normalize the URI according to section 2.7.3 [RFC7230] and
that MUST be matched with a simple string match to the requested URI. [RFC3986] sections 6.2.2 and 6.2.3. This applies to both
generation and validation of the signed JWT.
2.1.13.2. URI Regular Expression Container (uri-regex:) 2.1.15.1. URI Hash Container (hash:)
Prefixed with 'uri-regex:', this string is any PCRE [PCRE839] Prefixed with 'hash:', this string is a URL Segment form ([RFC6920]
compatible regular expression used to match against the requested Section 5) of the URI.
URI.
2.1.15.2. URI Regular Expression Container (regex:)
Prefixed with 'regex:', this string is any POSIX [POSIX.1] Section 9
Extended Regular Expression compatible regular expression used to
match against the requested URI. These regular expressions MUST be
evaluated in the POSIX locale (POSIX [POSIX.1] Section 7.2).
Note: Because '\' has special meaning in JSON [RFC7159] as the escape Note: Because '\' has special meaning in JSON [RFC7159] as the escape
character within JSON strings, the regular expression character '\' character within JSON strings, the regular expression character '\'
MUST be escaped as '\\'. MUST be escaped as '\\'.
An example of a 'uri-regex:' is the following: An example of a 'regex:' is the following:
[^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\?.*)? [^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)?
Note: Due to computational complexity of executing arbitrary regular Note: Due to computational complexity of executing arbitrary regular
expressions, it is RECOMMENDED to only execute after validating the expressions, it is RECOMMENDED to only execute after validating the
JWT to ensure its authenticity. JWT to ensure its authenticity.
2.1.13.3. URI Hash Container (uri-hash:)
Prefixed with 'uri-hash:', this string is a URL Segment form
([RFC6920] Section 5) of the URI.
2.2. JWT Header 2.2. JWT Header
The header of the JWT MAY be passed via the CDNI Metadata interface The header of the JWT MAY be passed via the CDNI Metadata interface
instead of being included in the URISigningPackage. The header value instead of being included in the URISigningPackage. The header value
must be transmitted in the serialized encoded form and prepended to must be transmitted in the serialized encoded form and prepended to
the JWT payload and signature passed in the URISigningPackage prior the JWT payload and signature passed in the URISigningPackage prior
to validation. This reduces the size of the signed JWT token. to validation. This reduces the size of the signed JWT token.
3. URI Signing Token Renewal 3. URI Signing Token Renewal
skipping to change at page 16, line 8 skipping to change at page 17, line 8
segmented protocols such as HTTP Adaptive Streaming protocols affect segmented protocols such as HTTP Adaptive Streaming protocols affect
CDNI, see Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. CDNI, see Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983].
The method described in this section allows CDNs to use URI Signing The method described in this section allows CDNs to use URI Signing
for segmented content without having to include the Signed URIs in for segmented content without having to include the Signed URIs in
the manifest files themselves. the manifest files themselves.
3.2. Signed Token Renewal mechanism 3.2. Signed Token Renewal mechanism
In order to allow for effective access control of segmented content, In order to allow for effective access control of segmented content,
the URI signing scheme defined in this section is based on a the URI signing mechanism defined in this section is based on a
mechanism through which subsequent segment requests can be linked method through which subsequent segment requests can be linked
together. As part of the JWT validation procedure, the CDN can together. As part of the JWT validation procedure, the CDN can
generate a new signed JWT that the UA can use to do a subsequent generate a new signed JWT that the UA can use to do a subsequent
request. More specifically, whenever a UA successfully retrieves a request. More specifically, whenever a UA successfully retrieves a
segment, it receives, in the HTTP 2xx Successful message, a signed segment, it receives, in the HTTP 2xx Successful message, a signed
JWT that it can use whenever it requests the next segment. As long JWT that it can use whenever it requests the next segment. As long
as each successive signed JWT is correctly validated before a new one as each successive signed JWT is correctly validated before a new one
is generated, the model is not broken and the User Agent can is generated, the model is not broken and the User Agent can
successfully retrieve additional segments. Given the fact that with successfully retrieve additional segments. Given the fact that with
segmented protocols, it is usually not possible to determine a priori segmented protocols, it is usually not possible to determine a priori
which segment will be requested next (i.e., to allow for seeking which segment will be requested next (i.e., to allow for seeking
skipping to change at page 16, line 39 skipping to change at page 17, line 39
segmented protocol and since this document is only concerned with the segmented protocol and since this document is only concerned with the
generation and validation of incoming request, this process is generation and validation of incoming request, this process is
outside the scope of this document. However, in order to also outside the scope of this document. However, in order to also
support legacy UAs that do not include any specific provisions for support legacy UAs that do not include any specific provisions for
the handling of signed JWTs, the folowing section defines a mechanism the handling of signed JWTs, the folowing section defines a mechanism
using HTTP Cookies that allows such UAs to support the concept of using HTTP Cookies that allows such UAs to support the concept of
renewing signed JWTs without requiring any support on the UA side. renewing signed JWTs without requiring any support on the UA side.
3.2.1. Required Claims 3.2.1. Required Claims
The cdnistt claim (Section 2.1.12) and cdniets claim (Section 2.1.11) The cdnistt claim (Section 2.1.13) and cdniets claim (Section 2.1.12)
MUST both be present to utilize Signed token Renewal. Either one MUST both be present to utilize Signed token Renewal. Either one
MUST NOT appear alone. You MAY set cdnistt to a value of '0' to mean MUST NOT appear alone. You MAY set cdnistt to a value of '0' to mean
no Signed Token Renewal, but you still MUST have a corresponding no Signed Token Renewal, but you still MUST have a corresponding
cdniets that validates as a JSON number. However, if you do not want cdniets that validates as a JSON number. However, if you do not want
to use Signed Token Renewal, it is RECOMMENDED to simply omit both. to use Signed Token Renewal, it is RECOMMENDED to simply omit both.
3.3. Communicating a signed JWTs in Signed Token Renewal 3.3. Communicating a signed JWTs in Signed Token Renewal
This section assumes the value of the CDNI Signed Token Transport This section assumes the value of the CDNI Signed Token Transport
(cdnistt) claim has been set to 1. Other values of cdnistt are out (cdnistt) claim has been set to 1. Other values of cdnistt are out
skipping to change at page 28, line 48 skipping to change at page 29, line 48
[RFC7519]. [RFC7519].
6.5.1. Registry Contents 6.5.1. Registry Contents
o Claim Name: "cdniv" o Claim Name: "cdniv"
o Claim Description: CDNI Claim Set Version o Claim Description: CDNI Claim Set Version
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.1.8 of [[ this specification o Specification Document(s): Section 2.1.8 of [[ this specification
]] ]]
o Claim Name: "cdnicrit"
o Claim Description: CDNI Critical Claims Set
o Change Controller: IESG
o Specification Document(s): Section 2.1.9 of [[ this specification
]]
o Claim Name: "cdniip" o Claim Name: "cdniip"
o Claim Description: CDNI IP Address o Claim Description: CDNI IP Address
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.1.9 of [[ this specification o Specification Document(s): Section 2.1.10 of [[ this specification
]] ]]
o Claim Name: "cdniuc" o Claim Name: "cdniuc"
o Claim Description: CDNI URI Container o Claim Description: CDNI URI Container
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.1.10 of [[ this specification o Specification Document(s): Section 2.1.11 of [[ this specification
]] ]]
o Claim Name: "cdniets" o Claim Name: "cdniets"
o Claim Description: CDNI Expiration Time Setting for Signed Token o Claim Description: CDNI Expiration Time Setting for Signed Token
Renewal Renewal
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.1.11 of [[ this specification o Specification Document(s): Section 2.1.12 of [[ this specification
]] ]]
o Claim Name: "cdnistt" o Claim Name: "cdnistt"
o Claim Description: CDNI Signed Token Transport Method for Signed o Claim Description: CDNI Signed Token Transport Method for Signed
Token Renewal Token Renewal
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.1.12 of [[ this specification o Specification Document(s): Section 2.1.13 of [[ this specification
]] ]]
7. Security Considerations 7. Security Considerations
This document describes the concept of URI Signing and how it can be This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of CDNI. The used to provide access authorization in the case of CDNI. The
primary goal of URI Signing is to make sure that only authorized UAs 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 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 every individual request. It should be noted that URI Signing is not
a content protection scheme; if a CSP wants to protect the content a content protection scheme; if a CSP wants to protect the content
skipping to change at page 31, line 24 skipping to change at page 32, line 26
o Matt Miller provided consultation on JWT usage as well as code to o Matt Miller provided consultation on JWT usage as well as code to
generate working JWT examples. generate working JWT examples.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, <https://www.rfc- DOI 10.17487/RFC5226, May 2008,
editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<https://www.rfc-editor.org/info/rfc6920>. <https://www.rfc-editor.org/info/rfc6920>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>. 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015, RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>. <https://www.rfc-editor.org/info/rfc7516>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed.,
and R. Peterkofsky, "Content Distribution Network and R. Peterkofsky, "Content Distribution Network
Interconnection (CDNI) Logging Interface", RFC 7937, Interconnection (CDNI) Logging Interface", RFC 7937,
DOI 10.17487/RFC7937, August 2016, <https://www.rfc- DOI 10.17487/RFC7937, August 2016,
editor.org/info/rfc7937>. <https://www.rfc-editor.org/info/rfc7937>.
[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"Content Delivery Network Interconnection (CDNI) "Content Delivery Network Interconnection (CDNI)
Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
<https://www.rfc-editor.org/info/rfc8006>. <https://www.rfc-editor.org/info/rfc8006>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 32, line 32 skipping to change at page 33, line 36
[IANA.JWT.Claims] [IANA.JWT.Claims]
IANA, "JSON Web Token Claims", IANA, "JSON Web Token Claims",
<http://www.iana.org/assignments/jwt>. <http://www.iana.org/assignments/jwt>.
[MPEG-DASH] [MPEG-DASH]
ISO, "Information technology -- Dynamic adaptive streaming ISO, "Information technology -- Dynamic adaptive streaming
over HTTP (DASH) -- Part 1: Media presentation description over HTTP (DASH) -- Part 1: Media presentation description
and segment format", ISO/IEC 23009-1:2014, Edition 2, 05 and segment format", ISO/IEC 23009-1:2014, Edition 2, 05
2014, <http://www.iso.org/standard/65274.html>. 2014, <http://www.iso.org/standard/65274.html>.
[PCRE839] Hazel, P., "Perl Compatible Regular Expressions", [POSIX.1] IEEE, "The Open Group Base Specifications Issue 7", IEEE
Version 8.39, June 2016, <http://www.pcre.org/>. Std 1003.1 2018 Edition, Jan 2018,
<http://pubs.opengroup.org/onlinepubs/9699919799/>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, <https://www.rfc- DOI 10.17487/RFC5952, August 2010,
editor.org/info/rfc5952>. <https://www.rfc-editor.org/info/rfc5952>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <https://www.rfc-editor.org/info/rfc6707>. 2012, <https://www.rfc-editor.org/info/rfc6707>.
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F.,
and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware
Content Distribution Network Interconnection (CDNI)", Content Distribution Network Interconnection (CDNI)",
RFC 6983, DOI 10.17487/RFC6983, July 2013, RFC 6983, DOI 10.17487/RFC6983, July 2013,
<https://www.rfc-editor.org/info/rfc6983>. <https://www.rfc-editor.org/info/rfc6983>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Framework for Content Distribution Network "Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
August 2014, <https://www.rfc-editor.org/info/rfc7336>. August 2014, <https://www.rfc-editor.org/info/rfc7336>.
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
Network Interconnection (CDNI) Requirements", RFC 7337, Network Interconnection (CDNI) Requirements", RFC 7337,
DOI 10.17487/RFC7337, August 2014, <https://www.rfc- DOI 10.17487/RFC7337, August 2014,
editor.org/info/rfc7337>. <https://www.rfc-editor.org/info/rfc7337>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015, <https://www.rfc- DOI 10.17487/RFC7517, May 2015,
editor.org/info/rfc7517>. <https://www.rfc-editor.org/info/rfc7517>.
[RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed.,
"Request Routing Redirection Interface for Content "Request Routing Redirection Interface for Content
Delivery Network (CDN) Interconnection", RFC 7975, Delivery Network (CDN) Interconnection", RFC 7975,
DOI 10.17487/RFC7975, October 2016, <https://www.rfc- DOI 10.17487/RFC7975, October 2016,
editor.org/info/rfc7975>. <https://www.rfc-editor.org/info/rfc7975>.
[RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
R., and K. Ma, "Content Delivery Network Interconnection R., and K. Ma, "Content Delivery Network Interconnection
(CDNI) Request Routing: Footprint and Capabilities (CDNI) Request Routing: Footprint and Capabilities
Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
<https://www.rfc-editor.org/info/rfc8008>. <https://www.rfc-editor.org/info/rfc8008>.
[RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming",
RFC 8216, DOI 10.17487/RFC8216, August 2017, RFC 8216, DOI 10.17487/RFC8216, August 2017,
<https://www.rfc-editor.org/info/rfc8216>. <https://www.rfc-editor.org/info/rfc8216>.
skipping to change at page 35, line 5 skipping to change at page 36, line 12
private signing keys have the same fingerprint and only vary by the private signing keys have the same fingerprint and only vary by the
'd' parameter that is missing from the public signing key. 'd' parameter that is missing from the public signing key.
A.1. Simple Example A.1. Simple Example
This example is a simple common usage example containing a minimal This example is a simple common usage example containing a minimal
subset of claims that the authors find most useful. subset of claims that the authors find most useful.
The JWT Claim Set before signing: The JWT Claim Set before signing:
{ Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the
"exp": 1474243500, URL Segment form ([RFC6920] Section 5) of "http://cdni.example/foo/
"iss": "uCDN Inc", bar".
"cdniuc": "uri:http://cdni.example/foo/bar"
} {
"exp": 1474243500,
"iss": "uCDN Inc",
"cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY"
}
The signed JWT: The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE0NzQyNDM1MDAsImlzcyI6InVDRE4gS dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE0NzQyNDM1MDAsImlzcyI6InVDRE4gS
W5jIiwiY2RuaXVjIjoidXJpOmh0dHA6Ly9jZG5pLmV4YW1wbGUvZm9vL2JhciJ9.4W W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV
xfA1ogQfeVLJYDtxrhilYctGR2KIIa1br5L6ZETTpn18_cNmsjQE4D7Cxs3tbbWAnI wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.qzzAB9akC-HoEzQrkOoODWjMC0PEZRrmWz
gVSIdcNVwBneluta5g 2rSMcpLtvxyxVodlB2xcpl4J4ABhLLOJzgzL9B39TljTqZApSOpQ
A.2. Complex Example A.2. Complex Example
This example uses all fields except for those dealing with Signed This example uses all fields except for those dealing with Signed
Token Renewal, including Client IP (cdniip) and Subject (sub) which Token Renewal, including Client IP (cdniip) and Subject (sub) which
are encrpyted. This significantly increases the size of the signed are encrpyted. This significantly increases the size of the signed
JWT token. JWT token.
JWE for Client IP (cdniip) of [2001:db8::1/32]: JWE for Client IP (cdniip) of [2001:db8::1/32]:
eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST
g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..hHQn6LM8Km95O0IE.KgJiy NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..SuzoOnfg-GVh-BOc.wQ9iS
DRsW7QBQsDJrmS7Hg.cXRZ8sMJ8PKz3fnj6VXgvw R1sTj-A04CiDmvcgg.9Ts_cIEUw6Yc6U5HaH1UPQ
JWE for Subject (sub) of "UserToken": JWE for Subject (sub) of "UserToken":
eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST
g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..ZH1hpBqhB8rgr3fD.3iEkR NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..XsJ7ySeChORSIojp.R1U8E
iaFkgwG.nzyjp7bZ3SJlYcDWv9irrQ SGU2NnW.DWR8pTbeCwQZca6SitfX_g
The JWT Claim Set before signing: The JWT Claim Set before signing:
{ {
"aud": "dCDN LLC", "aud": "dCDN LLC",
"sub": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm "sub": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4
dm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..ZH1hpBqhB8rg QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..XsJ7ySeChORS
r3fD.3iEkRiaFkgwG.nzyjp7bZ3SJlYcDWv9irrQ", Iojp.R1U8ESGU2NnW.DWR8pTbeCwQZca6SitfX_g",
"cdniip": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQM "cdniip": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XY
mhmdm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..hHQn6LM8K mp4QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..SuzoOnfg-
m95O0IE.KgJiyDRsW7QBQsDJrmS7Hg.cXRZ8sMJ8PKz3fnj6VXgvw", GVh-BOc.wQ9iSR1sTj-A04CiDmvcgg.9Ts_cIEUw6Yc6U5HaH1UPQ",
"cdniv": 1, "cdniv": 1,
"exp": 1474243500, "exp": 1474243500,
"iat": 1474243200, "iat": 1474243200,
"iss": "uCDN Inc", "iss": "uCDN Inc",
"jti": "5DAafLhZAfhsbe", "jti": "5DAafLhZAfhsbe",
"nbf": 1474243200, "nbf": 1474243200,
"cdniuc": "uri-regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png" "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png"
} }
The signed JWT: The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5SmhiR dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5Smxib
2NpT2lKa2FYSWlMQ0pyYVdRaU9pSm1MVmRpYW5oQ1F6TmtVSFZKTTJReU5HdFFNbWh U1pT2lKQk1USTRSME5OSWl3aVlXeG5Jam9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA
tZG05ek4xRjZOamc0VlZScE5tRkNNR2hPT1RrNElpd2laVzVqSWpvaVFURXlPRWREV 0UWtNelpGQjFTVE5rTWpSclVESm9ablp2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T
FNKOS4uWkgxaHBCcWhCOHJncjNmRC4zaUVrUmlhRmtnd0cubnp5anA3YlozU0psWWN 0NKOS4uWHNKN3lTZUNoT1JTSW9qcC5SMVU4RVNHVTJOblcuRFdSOHBUYmVDd1FaY2E
EV3Y5aXJyUSIsImNkbmlpcCI6ImV5SmhiR2NpT2lKa2FYSWlMQ0pyYVdRaU9pSm1MV 2U2l0ZlhfZyIsImNkbmlpcCI6ImV5SmxibU1pT2lKQk1USTRSME5OSWl3aVlXeG5Ja
mRpYW5oQ1F6TmtVSFZKTTJReU5HdFFNbWhtZG05ek4xRjZOamc0VlZScE5tRkNNR2h m9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA0UWtNelpGQjFTVE5rTWpSclVESm9ablp
PT1RrNElpd2laVzVqSWpvaVFURXlPRWREVFNKOS4uaEhRbjZMTThLbTk1TzBJRS5LZ 2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T0NKOS4uU3V6b09uZmctR1ZoLUJPYy53U
0ppeURSc1c3UUJRc0RKcm1TN0hnLmNYUlo4c01KOFBLejNmbmo2VlhndnciLCJjZG5 TlpU1Ixc1RqLUEwNENpRG12Y2dnLjlUc19jSUVVdzZZYzZVNUhhSDFVUFEiLCJjZG5
pdiI6MSwiZXhwIjoxNDc0MjQzNTAwLCJpYXQiOjE0NzQyNDMyMDAsImlzcyI6InVDR pdiI6MSwiZXhwIjoxNDc0MjQzNTAwLCJpYXQiOjE0NzQyNDMyMDAsImlzcyI6InVDR
E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE0NzQyNDMyMDAsImN E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE0NzQyNDMyMDAsImN
kbml1YyI6InVyaS1yZWdleDpodHRwOi8vY2RuaVxcLmV4YW1wbGUvZm9vL2Jhci9bM kbml1YyI6InJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL1swLTlde
C05XXszfVxcLnBuZyJ9.3sKwFFMy7Hlbur1RzkeI0wDKerYXcrmBdfwJG7NP3TWS7a zN9XFwucG5nIn0.XEi1NeP8Lzh6ECcbp6EoqYlnJGikaGp6F3lIJ7ZJt3bim6tOtuD
s52f8-F-wOFzFEIoX2UX3Z5Dinl6lbCQ__-pBgZw pCQxmEQxobzIpWOCNdpB8kvxM_s95brKjNQ
A.3. Signed Token Renewal Example A.3. Signed Token Renewal Example
This example uses fields for Signed Token Renewal. This example uses fields for Signed Token Renewal.
The JWT Claim Set before signing: The JWT Claim Set before signing:
{ {
"cdniets": 30, "cdniets": 30,
"cdnistt": 1, "cdnistt": 1,
"cdnistd": 2,
"exp": 1474243500, "exp": 1474243500,
"cdniuc": "uri-regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts"
} }
The signed JWT: The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiZXhwI dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua
joxNDc0MjQzNTAwLCJjZG5pdWMiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGF XN0ZCI6MiwiZXhwIjoxNDc0MjQzNTAwLCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R
tcGxlL2Zvby9iYXIvWzAtOV17M31cXC50cyJ9.fL4S6f4FovPls_N-JBap7CKGsQsi uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.wsSvwxY8mtRax7HK_
Xhds2nFhz3EnIOVfDlrTt3mw6AA6SsHnc2fu6bqZP_3YOdwOYFYjDPTYfg dro_l6m-mM-HYdeaUoTSgVS5XTIhXBsCPsYQncsradmgmOWHDDOxsSMVVTjHe5E5YH
ZlQ
Once the server validates the signed JWT it will return a new signed Once the server validates the signed JWT it will return a new signed
JWT with an updated expiry time (exp) as shown below. Note the JWT with an updated expiry time (exp) as shown below. Note the
expiry time is increased by the expiration time setting (cdniets) expiry time is increased by the expiration time setting (cdniets)
value. value.
The JWT Claim Set before signing: The JWT Claim Set before signing:
{ {
"cdniets": 30, "cdniets": 30,
"cdnistt": 1, "cdnistt": 1,
"cdnistd": 2,
"exp": 1474243530, "exp": 1474243530,
"cdniuc": "uri-regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts"
} }
The signed JWT: The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiZXhwI dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua
joxNDc0MjQzNTMwLCJjZG5pdWMiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGF XN0ZCI6MiwiZXhwIjoxNDc0MjQzNTMwLCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R
tcGxlL2Zvby9iYXIvWzAtOV17M31cXC50cyJ9.Zi-Xq-0ZrZ5uL2F5YCxZMXWWnaM6 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.SITeoIVZ8-yeE_GBV
wS9-x9eRu5UC6WgbMBQ0yH7lJNe7UG_5Ge-QPuRggm9tz1AF4S_Ty8H9Ig jYEo1P2LN-EId1gEJ6baR3Au7Dzh2o_O7LhH3k6wHY081sYMdXHucB0P5ocp-r7gqe
ruQ
Authors' Addresses Authors' Addresses
Ray van Brandenburg Ray van Brandenburg
Tiledmedia Tiledmedia
Anna van Buerenplein 1 Anna van Buerenplein 1
Den Haag 2595DA Den Haag 2595DA
The Netherlands The Netherlands
Phone: +31 88 866 7000 Phone: +31 88 866 7000
skipping to change at page 37, line 43 skipping to change at page 39, line 4
Authors' Addresses Authors' Addresses
Ray van Brandenburg Ray van Brandenburg
Tiledmedia Tiledmedia
Anna van Buerenplein 1 Anna van Buerenplein 1
Den Haag 2595DA Den Haag 2595DA
The Netherlands The Netherlands
Phone: +31 88 866 7000 Phone: +31 88 866 7000
Email: ray@tiledmedia.com Email: ray@tiledmedia.com
Kent Leung Kent Leung
Cisco Systems, Inc. Cisco Systems, Inc.
3625 Cisco Way 3625 Cisco Way
San Jose, CA 95134 San Jose, CA 95134
United States United States
Phone: +1 408 526 5030 Phone: +1 408 526 5030
Email: kleung@cisco.com Email: kleung@cisco.com
Phil Sorber Phil Sorber
Apple, Inc.
1800 Wazee Street
Suite 410
Denver, CO 80202
United States
Email: sorber@apache.org Email: sorber@apple.com
 End of changes. 59 change blocks. 
156 lines changed or deleted 228 lines changed or added

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