draft-ietf-cdni-uri-signing-13.txt   draft-ietf-cdni-uri-signing-14.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: May 3, 2018 Cisco Systems, Inc. Expires: September 6, 2018 Cisco Systems, Inc.
P. Sorber P. Sorber
Comcast Cable Communications March 5, 2018
October 30, 2017
URI Signing for CDN Interconnection (CDNI) URI Signing for CDN Interconnection (CDNI)
draft-ietf-cdni-uri-signing-13 draft-ietf-cdni-uri-signing-14
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 https://datatracker.ietf.org/drafts/current/. Drafts is at http://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 May 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
(https://trustee.ietf.org/license-info) in effect on the date of (http://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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Background and overview on URI Signing . . . . . . . . . 5 1.2. Background and overview on URI Signing . . . . . . . . . 5
1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6 1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6
1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8 1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8
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. URI Container (sub) claim . . . . . . . . . . . . . . 10 2.1.2. Subject (sub) claim . . . . . . . . . . . . . . . . . 10
2.1.3. Client IP (aud) claim . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . 11 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. CDNI Expiration Time Setting (cdniets) claim . . . . 12 2.1.9. Client IP (cdniip) claim . . . . . . . . . . . . . . 12
2.1.10. CDNI Signed Token Transport (cdnistt) claim . . . . . 13 2.1.10. CDNI URI Container (cdniuc) claim . . . . . . . . . . 13
2.1.11. URI Container Forms . . . . . . . . . . . . . . . . . 13 2.1.11. CDNI Expiration Time Setting (cdniets) claim . . . . 13
2.1.11.1. URI Simple Container (uri:) . . . . . . . . . . 13 2.1.12. CDNI Signed Token Transport (cdnistt) claim . . . . . 13
2.1.11.2. URI Pattern Container (uri-pattern:) . . . . . . 13 2.1.13. URI Container Forms . . . . . . . . . . . . . . . . . 14
2.1.11.3. URI Regular Expression Container (uri-regex:) . 14 2.1.13.1. URI Simple Container (uri:) . . . . . . . . . . 14
2.1.11.4. URI Hash Container (uri-hash:) . . . . . . . . . 14 2.1.13.2. URI Regular Expression Container (uri-regex:) . 14
2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.13.3. URI Hash Container (uri-hash:) . . . . . . . . . 14
2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 15
3. URI Signing Token Renewal . . . . . . . . . . . . . . . . . . 15 3. URI Signing Token Renewal . . . . . . . . . . . . . . . . . . 15
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Signed Token Renewal mechanism . . . . . . . . . . . . . 15 3.2. Signed Token Renewal mechanism . . . . . . . . . . . . . 16
3.2.1. Required Claims . . . . . . . . . . . . . . . . . . . 16
3.3. Communicating a signed JWTs in Signed Token Renewal . . . 16 3.3. Communicating a signed JWTs in Signed Token Renewal . . . 16
3.3.1. Support for cross-domain redirection . . . . . . . . 16 3.3.1. Support for cross-domain redirection . . . . . . . . 17
4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 17 4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 17
4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 17 4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 17
4.2. CDNI Footprint & Capabilities Advertisement Interface . . 17 4.2. CDNI Footprint & Capabilities Advertisement Interface . . 18
4.3. CDNI Request Routing Redirection Interface . . . . . . . 17 4.3. CDNI Request Routing Redirection Interface . . . . . . . 18
4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 17 4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 18
4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 19 4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 19
5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 20 5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 21
5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 20 5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 21
5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 23 5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 26 6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 26
6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 26 6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 27
6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 26 6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 27
6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 27 6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 27
6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 27 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 27
6.4. CDNI URI Signing Signed Token Transport . . . . . . . . . 27 6.4. CDNI URI Signing Signed Token Transport . . . . . . . . . 28
6.5. JSON Web Token Claims Registration . . . . . . . . . . . 28 6.5. JSON Web Token Claims Registration . . . . . . . . . . . 28
6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 28 6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 30 11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Signed URI Package Example . . . . . . . . . . . . . 33 Appendix A. Signed URI Package Example . . . . . . . . . . . . . 33
A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 34 A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 34
A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 34 A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 35
A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 35 A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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 29 skipping to change at page 9, line 29
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
the CDNI Metadata (Section 4.4). If the CDNI Metadata interface is the CDNI Metadata (Section 4.4). If the CDNI Metadata interface is
not used, or does not include a parameter name for the URI Signing not used, or does not include a parameter name for the URI Signing
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-
right, for the following sequence:
o a reserved character (as defined in [RFC3986] Section 2.2),
o the URI Signing Package Attribute name,
o if the last character of the URI Singing Package Attribute name is
not a reserved character, an equal symbol ('='),
o and a sequence of non-reserved characters that will be interpreted
as a signed JWT,
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
will not be searched for multiple signed JWTs.
2.1. JWT Claims 2.1. JWT Claims
This section identifies the set of claims that can be used to enforce This section identifies the set of claims that can be used to enforce
the CSP distribution policy. New claims can be introduced in the the CSP distribution policy. New claims can be introduced in the
future to extend the distribution policy capabilities. future to extend the distribution policy capabilities.
In order to provide distribution policy flexibility, the exact subset In order to provide distribution policy flexibility, the exact subset
of claims used in a given signed JWT is a runtime decision. Claim of claims used in a given signed JWT is a runtime decision. Claim
requirements are defined in the CDNI Metadata (Section 4.4) If the requirements are defined in the CDNI Metadata (Section 4.4) If the
CDNI Metadata interface is not used, or does not include claim CDNI Metadata interface is not used, or does not include claim
skipping to change at page 10, line 24 skipping to change at page 10, line 42
the indicated key was provided by said issuer. If the CDN validating the indicated key was provided by said issuer. If the CDN validating
the signed JWT does not support Issuer validation, or if the Issuer the signed JWT does not support Issuer validation, or if the Issuer
in the signed JWT does not match the list of known acceptable in the signed JWT does not match the list of known acceptable
Issuers, the CDN MUST reject the request. If the received signed JWT Issuers, the CDN MUST reject the request. If the received signed JWT
contains an Issuer claim, then any JWT subsequently generated for contains an Issuer claim, then any JWT subsequently generated for
CDNI redirection MUST also contain an Issuer claim, and the Issuer CDNI redirection MUST also contain an Issuer claim, and the Issuer
value MUST be updated to identify the redirecting CDN. If the value MUST be updated to identify the redirecting CDN. If the
received signed JWT does not contain an Issuer claim, an Issuer claim received signed JWT does not contain an Issuer claim, an Issuer claim
MAY be added to a signed JWT generated for CDNI redirection. MAY be added to a signed JWT generated for CDNI redirection.
2.1.2. URI Container (sub) claim 2.1.2. Subject (sub) claim
URI Container (sub) [mandatory] - The semantics in [RFC7519] Subject (sub) [optional] - The semantics in [RFC7519] Section 4.1.2
Section 4.1.2 MUST be followed. Container for holding the URI MUST be followed. If this claim is used, it MUST be a JSON Web
representation before a URI Signing Package is added. This Encryption (JWE [RFC7516]) Object in compact serialization form,
representation can take one of several forms detailed in because it contains personally identifiable information. This claim
Section 2.1.11. If the URI pattern/regex in the signed JWT does not contains information about the subject (for example, a user or an
match the URI of the content request, the CDN validating the signed agent) that MAY be used to validate the signed JWT. If the received
JWT MUST reject the request. When comparing the URI the percent signed JWT contains a Subject claim, then any JWT subsequently
encoded form as defined in [RFC3986] Section 2.1 MUST be used. When generated for CDNI redirection MUST also contain a Subject claim, and
redirecting a URI, the CDN generating the new signed JWT MAY change the Subject value MUST be the same as in the received signed JWT. A
the URI Container to comport with the URI being used in the signed JWT generated for CDNI redirection MUST NOT add a Subject
redirection. claim if no Subject claim existed in the received signed JWT.
2.1.3. Client IP (aud) claim 2.1.3. Audience (aud) claim
Client IP (aud) [optional] - The semantics in [RFC7519] Section 4.1.3 Audience (aud) [optional] - The semantics in [RFC7519] Section 4.1.3
MUST be followed. IP address, or IP prefix, for which the Signed URI MUST be followed. This claim is used to ensure that the CDN that
is valid. This is represented in CIDR notation, with dotted decimal validates the JWT identifies itself with the value in this claim.
format for IPv4 or canonical text representation for IPv6 addresses
[RFC5952]. The request is rejected if sourced from a client outside
of the specified IP range. Since the client IP is considered
personally identifiable information this field MUST be a JSON Web
Encryption (JWE [RFC7516]) Object in compact serialization 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 the
source IP address in the content request, the CDN MUST reject the
request. If the received signed JWT contains a Client IP claim, then
any 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
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
received signed JWT.
2.1.4. Expiry Time (exp) claim 2.1.4. Expiry Time (exp) claim
Expiry Time (exp) [optional] - The semantics in [RFC7519] Expiry Time (exp) [optional] - The semantics in [RFC7519]
Section 4.1.4 MUST be followed, though URI Signing implementations Section 4.1.4 MUST be followed, though URI Signing implementations
MUST NOT allow for any time synchronization "leeway". Note: The time MUST NOT allow for any time synchronization "leeway". Note: The time
on the entities that generate and validate the signed URI SHOULD be on the entities that generate and validate the signed URI SHOULD be
in sync. In the CDNI case, this means that CSP, uCDN, and dCDN in sync. In the CDNI case, this means that CSP, uCDN, and dCDN
servers need to be time-synchronized. It is RECOMMENDED to use NTP servers need to be time-synchronized. It is RECOMMENDED to use NTP
[RFC5905] for time synchronization. If the CDN validating the signed [RFC5905] for time synchronization. If the CDN validating the signed
skipping to change at page 12, line 40 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. CDNI Expiration Time Setting (cdniets) claim 2.1.9. Client IP (cdniip) claim
Client IP (cdniip) [optional] IP address, or IP prefix, for which the
Signed URI is valid. This is represented in CIDR notation, with
dotted decimal format for IPv4 or canonical text representation for
IPv6 addresses [RFC5952]. The request is rejected if sourced from a
client outside of the specified IP range. Since the client IP is
considered personally identifiable information this field MUST be a
JSON Web Encryption (JWE [RFC7516]) Object in compact serialization
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
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
JWE. If the received signed JWT contains a Client IP claim, then any
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
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
received signed JWT.
2.1.10. CDNI URI Container (cdniuc) claim
URI Container (cdniuc) [optional] - Container for holding the URI
representation before a URI Signing Package is added. This
representation can take one of several forms detailed in
Section 2.1.13. If the URI regex in the signed JWT does not match
the URI of the content request, the CDN validating the signed JWT
MUST reject the request. When comparing the URI, the percent encoded
form as defined in [RFC3986] Section 2.1 MUST be used. When
redirecting a URI, the CDN generating the new signed JWT MAY change
the URI Container to comport with the URI being used in the
redirection.
2.1.11. 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. (cdniets) SHOULD NOT be used when not using Signed Token Renewal and
MUST be present when using Signed Token Renewal.
2.1.10. CDNI Signed Token Transport (cdnistt) claim 2.1.12. 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. This document only defines setting its value type is a JSON integer. Values for this claim can be defined in
to '1', which means the signed JWTs are transported via HTTP Cookies Section 6.4. If using this claim you MUST also specify a CDNI
in both directions. Additional values for this claim can be defined Expiration Time Setting (cdniets) as noted above.
in Section 6.4.
2.1.11. URI Container Forms 2.1.13. URI Container Forms
The URI Container (sub) claim takes one of the following forms. More The URI Container (cdniuc) claim takes one of the following forms.
forms may be added in the future to extend the capabilities. More forms may be added in the future to extend the capabilities.
2.1.11.1. URI Simple Container (uri:) Before comparing a URI against this container, the signed JWT must be
removed 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.
2.1.13.1. URI Simple Container (uri:)
When prefixed with 'uri:', the string following 'uri:' is the URI When prefixed with 'uri:', the string following 'uri:' is the URI
that MUST be matched with a simple string match to the requested URI. that MUST be matched with a simple string match to the requested URI.
2.1.11.2. URI Pattern Container (uri-pattern:) 2.1.13.2. URI Regular Expression Container (uri-regex:)
Prefixed with 'uri-pattern:', this string contains one or more URI
Patterns that describes for which content the Signed URI is valid.
Each URI Pattern contains an expression to match against the
requested URI, to check whether the requested content is allowed to
be served. Multiple URI Patterns may be concatenated in a single URI
Pattern by separating them with a semi-colon (';') character. Each
URI Pattern follows the [RFC3986] URI format, including the '://'
that delimits the URI scheme from the hierarchy part. The pattern
may include the special literals:
o ';' - separates individual patterns when the string contains
multiple URI patterns.
o '*' - matches any sequence of characters, including the empty
string.
o '?' - matches exactly one character.
o '$' - used to escape the special literals; MUST be followed by
exactly one of ';', '*', '?', or '$'.
The following is an example of a valid URI Pattern:
*://*/folder/content-83112371/quality_*/segment????.mp4
An example of two concatenated URI Patterns is the following
(whitespace is inserted after the ';' for readability and should not
be present in the actual representation):
http://*/folder/content-83112371/manifest/*.xml;
http://*/folder/content-83112371/quality_*/segment????.mp4
In order to increase the performance of string parsing the URI
Pattern, implementations can check often-used URI Pattern prefixes to
quickly check whether certain URI components can be ignored. For
example, URI Pattern prefixes '*://*/' or '*://*:*' will be used in
case the scheme and authority components of the URI are ignored for
purposes of pattern enforcement.
2.1.11.3. URI Regular Expression Container (uri-regex:)
Prefixed with 'uri-regex:', this string is any PCRE [PCRE839] Prefixed with 'uri-regex:', this string is any PCRE [PCRE839]
compatible regular expression used to match against the requested compatible regular expression used to match against the requested
URI. URI.
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 'uri-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.11.4. URI Hash Container (uri-hash:) 2.1.13.3. URI Hash Container (uri-hash:)
Prefixed with 'uri-hash:', this string is a URL Segment form Prefixed with 'uri-hash:', this string is a URL Segment form
([RFC6920] Section 5) of the URI. ([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
skipping to change at page 16, line 10 skipping to change at page 16, line 21
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
within the content and for switching to a different representation), within the content and for switching to a different representation),
the Signed Token Renewal uses the URI Pattern Container and/or the the Signed Token Renewal uses the URI Regular Expression Container
URI Regular Expression Container scoping mechanisms in the URI scoping mechanisms in the URI Container (cdniuc) claim to allow a
Container (sub) claim to allow a signed JWT to be valid for more than signed JWT to be valid for more than one URL.
one URL.
In order for this renewal of signed JWTs to work, it is necessary for 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 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 of an earlier request and use it to retrieve the next segment. The
exact mechanism by which the client does this depends on the exact exact mechanism by which the client does this depends on the exact
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
The cdnistt claim (Section 2.1.12) and cdniets claim (Section 2.1.11)
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
no Signed Token Renewal, but you still MUST have a corresponding
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.
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
of scope of this document. of scope of this document.
When using the Signed Token Renewal mechanism, the signed JWT is When using the Signed Token Renewal mechanism, the signed JWT is
transported to the UA via a 'URISigningPackage' cookie added to the transported to the UA via a 'URISigningPackage' cookie added to the
HTTP 2xx Successful message along with the content being returned to HTTP 2xx Successful message along with the content being returned to
the UA, or to the HTTP 3xx Redirection message in case the UA is the UA, or to the HTTP 3xx Redirection message in case the UA is
skipping to change at page 20, line 12 skipping to change at page 20, line 32
+ "400" : signed JWT validation performed and rejected because + "400" : signed JWT validation performed and rejected because
of incorrect signature of incorrect signature
+ "401" : signed JWT validation performed and rejected because + "401" : signed JWT validation performed and rejected because
of Expiration Time enforcement of Expiration Time enforcement
+ "402" : signed JWT validation performed and rejected because + "402" : signed JWT validation performed and rejected because
of Client IP enforcement of Client IP enforcement
+ "403" : signed JWT validation performed and rejected because + "403" : signed JWT validation performed and rejected because
of URI Pattern enforcement of URI Regular Expression enforcement
+ "404" : signed JWT validation performed and rejected because + "404" : signed JWT validation performed and rejected because
of Issuer enforcement of Issuer enforcement
+ "405" : signed JWT validation performed and rejected because + "405" : signed JWT validation performed and rejected because
of Not Before enforcement of Not Before enforcement
+ "500" : unable to perform signed JWT validation because of + "500" : unable to perform signed JWT validation because of
malformed URI malformed URI
skipping to change at page 28, line 8 skipping to change at page 28, line 21
Transport" subregistry in the "Content Delivery Networks Transport" subregistry in the "Content Delivery Networks
Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing
Signed Token Transport" namespace defines the valid values that may Signed Token Transport" namespace defines the valid values that may
be in the Signed Token Transport (cdnistt) JWT claim. Additions to be in the Signed Token Transport (cdnistt) JWT claim. Additions to
the Signed Token Transport namespace conform to the "Specification the Signed Token Transport namespace conform to the "Specification
Required" policy as defined in [RFC5226]. Required" policy as defined in [RFC5226].
The following table defines the initial Enforcement Information The following table defines the initial Enforcement Information
Elements: Elements:
+-------+---------------------------------------+---------+ +-------+-------------------------------------------+---------+
| Value | Description | RFC | | Value | Description | RFC |
+-------+---------------------------------------+---------+ +-------+-------------------------------------------+---------+
| 1 | Designates token transport via cookie | RFCthis | | 0 | Designates token transport is not enabled | RFCthis |
+-------+---------------------------------------+---------+ | 1 | Designates token transport via cookie | RFCthis |
+-------+-------------------------------------------+---------+
[RFC Editor: Please replace RFCthis with the published RFC number for [RFC Editor: Please replace RFCthis with the published RFC number for
this document.] this document.]
[Ed Note: are there any special instructions to the designated expert [Ed Note: are there any special instructions to the designated expert
reviewer?] reviewer?]
6.5. JSON Web Token Claims Registration 6.5. JSON Web Token Claims Registration
This specification registers the following Claims in the IANA "JSON This specification registers the following Claims in the IANA "JSON
skipping to change at page 28, line 34 skipping to change at page 28, 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: "cdniip"
o Claim Description: CDNI IP Address
o Change Controller: IESG
o Specification Document(s): Section 2.1.9 of [[ this specification
]]
o Claim Name: "cdniuc"
o Claim Description: CDNI URI Container
o Change Controller: IESG
o Specification Document(s): Section 2.1.10 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.9 of [[ this specification o Specification Document(s): Section 2.1.11 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.10 of [[ this specification o Specification Document(s): Section 2.1.12 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 30, line 5 skipping to change at page 30, line 26
based on Client IP Address and illegitimate users being able to based on Client IP Address and illegitimate users being able to
access the content. One way to reduce exposure to this kind of 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 attack is to not only check for Client IP but also for other
attributes, e.g., attributes that can be found in HTTP headers. attributes, e.g., attributes that can be found in HTTP headers.
The shared key between CSP and uCDN may be distributed to dCDNs - The shared key between CSP and uCDN may be distributed to dCDNs -
including cascaded CDNs. Since this key can be used to legitimately including cascaded CDNs. Since this key can be used to legitimately
sign a URL for content access authorization, it is important to know sign a URL for content access authorization, it is important to know
the implications of a compromised shared key. the implications of a compromised shared key.
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
cdniuc claim. As a result, compromised keys should be timely revoked
in order to prevent exploitation.
8. Privacy 8. Privacy
The privacy protection concerns described in CDNI Logging Interface The privacy protection concerns described in CDNI Logging Interface
[RFC7937] apply when the client's IP address (aud) is embedded in the [RFC7937] apply when the client's IP address (cdniip) is embedded in
Signed URI. For this reason, the mechanism described in Section 2 the Signed URI. For this reason, the mechanism described in
encrypts the Client IP before including it in the URI Signing Package Section 2 encrypts the Client IP before including it in the URI
(and thus the URL itself). Signing Package (and thus the URL itself).
9. Acknowledgements 9. Acknowledgements
The authors would like to thank the following people for their The authors would like to thank the following people for their
contributions in reviewing this document and providing feedback: contributions in reviewing this document and providing feedback:
Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan
York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana
Oprescu, Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris Oprescu, Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris
Lemmons. Lemmons.
skipping to change at page 30, line 41 skipping to change at page 31, line 24
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, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2119>. 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, DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5226>. 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>.
skipping to change at page 31, line 20 skipping to change at page 32, line 8
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, DOI 10.17487/RFC7937, August 2016, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7937>. 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 12 skipping to change at page 32, line 47
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, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5952>. 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, DOI 10.17487/RFC7337, August 2014, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7337>. 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, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7517>. 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, DOI 10.17487/RFC7975, October 2016, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7975>. 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>.
Appendix A. Signed URI Package Example Appendix A. Signed URI Package Example
This section contains three examples of token usage: a simple example This section contains three examples of token usage: a simple example
with only the required claim present, a complex example which with only the required claim present, a complex example which
demonstrates the full JWT claims set, including an encrypted Client demonstrates the full JWT claims set, including an encrypted Client
IP (aud), and one that uses a Signed Token Renewal. IP (cdniip), and one that uses a Signed Token Renewal.
Note: All of the examples have whitespace added to improve formatting Note: All of the examples have whitespace added to improve formatting
and readability, but are not present in the generated content. and readability, but are not present in the generated content.
All examples use the following JWK Set [RFC7517]: All examples use the following JWK Set [RFC7517]:
{ "keys": [ { "keys": [
{ {
"kty": "EC", "kty": "EC",
"kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0",
skipping to change at page 34, line 9 skipping to change at page 34, line 46
} }
]} ]}
Note: They are the public signing key, the private signing key, and Note: They are the public signing key, the private signing key, and
the shared secret enctyption key, respectively. The public and the shared secret enctyption key, respectively. The public and
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 the simplest possible example containing the only This example is a simple common usage example containing a minimal
required field (sub). subset of claims that the authors find most useful.
The JWT Claim Set before signing: The JWT Claim Set before signing:
{ {
"sub": "uri:http://cdni.example/foo/bar/baz" "exp": 1474243500,
"iss": "uCDN Inc",
"cdniuc": "uri:http://cdni.example/foo/bar"
} }
The signed JWT: The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJzdWIiOiJ1cmk6aHR0cDovL2NkbmkuZXhhbXBsZ dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE0NzQyNDM1MDAsImlzcyI6InVDRE4gS
S9mb28vYmFyL2JheiJ9.LTizGd7zCb17Qp_80ClGApLCieRIq3dCjcRckNfLqiJ4BT W5jIiwiY2RuaXVjIjoidXJpOmh0dHA6Ly9jZG5pLmV4YW1wbGUvZm9vL2JhciJ9.4W
GSfVXoDtm0Z6L5Jx4EmwM1w-WkznNajUy11iMAcA xfA1ogQfeVLJYDtxrhilYctGR2KIIa1br5L6ZETTpn18_cNmsjQE4D7Cxs3tbbWAnI
gVSIdcNVwBneluta5g
A.2. Complex Example A.2. Complex Example
This example uses all optional fields except for those dealing with This example uses all fields except for those dealing with Signed
Signed Token Renewal, including Client IP (aud) which is encrpyted. Token Renewal, including Client IP (cdniip) and Subject (sub) which
This significantly increases the size of the signed JWT token. are encrpyted. This significantly increases the size of the signed
JWT token.
JWE for client IP (aud) of [2001:db8::1/32]: JWE for Client IP (cdniip) of [2001:db8::1/32]:
eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj
g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..oGLsnF8fLlFcUXK0.KFfBB g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..hHQn6LM8Km95O0IE.KgJiy
H_FPYFu-RBFBR3rhQ.6_MVaa4t7JiVX2IgUkZ3jA DRsW7QBQsDJrmS7Hg.cXRZ8sMJ8PKz3fnj6VXgvw
JWE for Subject (sub) of "UserToken":
eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj
g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..ZH1hpBqhB8rgr3fD.3iEkR
iaFkgwG.nzyjp7bZ3SJlYcDWv9irrQ
The JWT Claim Set before signing: The JWT Claim Set before signing:
{ {
"aud": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm "aud": "dCDN LLC",
dm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..oGLsnF8fLlFc "sub": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm
UXK0.KFfBBH_FPYFu-RBFBR3rhQ.6_MVaa4t7JiVX2IgUkZ3jA", dm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..ZH1hpBqhB8rg
r3fD.3iEkRiaFkgwG.nzyjp7bZ3SJlYcDWv9irrQ",
"cdniip": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQM
mhmdm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..hHQn6LM8K
m95O0IE.KgJiyDRsW7QBQsDJrmS7Hg.cXRZ8sMJ8PKz3fnj6VXgvw",
"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,
"sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.png" "cdniuc": "uri-regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png"
} }
The signed JWT: The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJleUpoYkdjaU9pSmthWElpTENKcmFXU dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5SmhiR
WlPaUptTFZkaWFuaENRek5rVUhWSk0yUXlOR3RRTW1obWRtOXpOMUY2TmpnNFZWUnB 2NpT2lKa2FYSWlMQ0pyYVdRaU9pSm1MVmRpYW5oQ1F6TmtVSFZKTTJReU5HdFFNbWh
ObUZDTUdoT09UazRJaXdpWlc1aklqb2lRVEV5T0VkRFRTSjkuLm9HTHNuRjhmTGxGY tZG05ek4xRjZOamc0VlZScE5tRkNNR2hPT1RrNElpd2laVzVqSWpvaVFURXlPRWREV
1VYSzAuS0ZmQkJIX0ZQWUZ1LVJCRkJSM3JoUS42X01WYWE0dDdKaVZYMklnVWtaM2p FNKOS4uWkgxaHBCcWhCOHJncjNmRC4zaUVrUmlhRmtnd0cubnp5anA3YlozU0psWWN
BIiwiY2RuaXYiOjEsImV4cCI6MTQ3NDI0MzUwMCwiaWF0IjoxNDc0MjQzMjAwLCJpc EV3Y5aXJyUSIsImNkbmlpcCI6ImV5SmhiR2NpT2lKa2FYSWlMQ0pyYVdRaU9pSm1MV
3MiOiJ1Q0ROIEluYyIsImp0aSI6IjVEQWFmTGhaQWZoc2JlIiwibmJmIjoxNDc0MjQ mRpYW5oQ1F6TmtVSFZKTTJReU5HdFFNbWhtZG05ek4xRjZOamc0VlZScE5tRkNNR2h
zMjAwLCJzdWIiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGFtcGxlL2Zvby9iY PT1RrNElpd2laVzVqSWpvaVFURXlPRWREVFNKOS4uaEhRbjZMTThLbTk1TzBJRS5LZ
XIvYmF6L1swLTldezN9XFwucG5nIn0.r2FiSdfnGRw_RC2roGwh4LEYlfsWGF972-M 0ppeURSc1c3UUJRc0RKcm1TN0hnLmNYUlo4c01KOFBLejNmbmo2VlhndnciLCJjZG5
f3He_LhGr2_3eRXP0jP_OFPj5NEtTZFY4PX_iD7vPD12_HPDJCQ pdiI6MSwiZXhwIjoxNDc0MjQzNTAwLCJpYXQiOjE0NzQyNDMyMDAsImlzcyI6InVDR
E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE0NzQyNDMyMDAsImN
kbml1YyI6InVyaS1yZWdleDpodHRwOi8vY2RuaVxcLmV4YW1wbGUvZm9vL2Jhci9bM
C05XXszfVxcLnBuZyJ9.3sKwFFMy7Hlbur1RzkeI0wDKerYXcrmBdfwJG7NP3TWS7a
s52f8-F-wOFzFEIoX2UX3Z5Dinl6lbCQ__-pBgZw
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,
"exp": 1474243500, "exp": 1474243500,
"sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.ts" "cdniuc": "uri-regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts"
} }
The signed JWT: The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiZXhwI dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiZXhwI
joxNDc0MjQzNTAwLCJzdWIiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGFtcGx joxNDc0MjQzNTAwLCJjZG5pdWMiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGF
lL2Zvby9iYXIvYmF6L1swLTldezN9XFwudHMifQ.VYF7Eqk1WhRWdvDVUx5mXDJaS- tcGxlL2Zvby9iYXIvWzAtOV17M31cXC50cyJ9.fL4S6f4FovPls_N-JBap7CKGsQsi
r6jbjgiYuwIEAYmbLWsF2dUDohrV70sz7TC09n-oNf_ws4eeH_A6AnvF4FTQ Xhds2nFhz3EnIOVfDlrTt3mw6AA6SsHnc2fu6bqZP_3YOdwOYFYjDPTYfg
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,
"exp": 1474243530, "exp": 1474243530,
"sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.ts" "cdniuc": "uri-regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts"
} }
The signed JWT: The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiZXhwI dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiZXhwI
joxNDc0MjQzNTMwLCJzdWIiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGFtcGx joxNDc0MjQzNTMwLCJjZG5pdWMiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGF
lL2Zvby9iYXIvYmF6L1swLTldezN9XFwudHMifQ.zzXhYg6b7_8MylW-RS97qZv3hQ tcGxlL2Zvby9iYXIvWzAtOV17M31cXC50cyJ9.Zi-Xq-0ZrZ5uL2F5YCxZMXWWnaM6
QlYg-TxhC-wigdB4moxlFEjndDvv0EDxl42faQaE39BCHZq7H-DXVpBrhxTw wS9-x9eRu5UC6WgbMBQ0yH7lJNe7UG_5Ge-QPuRggm9tz1AF4S_Ty8H9Ig
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 36, line 31 skipping to change at page 38, line 4
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
Comcast Cable Communications
1401 Wynkoop Street, Suite 300
Denver, CO 80202
United States
Phone: +1 720 502 3785 Email: sorber@apache.org
Email: phillip_sorber@comcast.com
 End of changes. 68 change blocks. 
189 lines changed or deleted 241 lines changed or added

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