diff --git a/rfc9246.xml b/rfc9246.xml index c4e02fd..bb00fe5 100644 --- a/rfc9246.xml +++ b/rfc9246.xml @@ -53,7 +53,7 @@ -example +jwt,json,token,cdn,url,http,hls,dash This document describes how the concept of URI Signing supports the @@ -181,7 +181,7 @@ title) for use on https://www.rfc-editor.org/search. --> to a CDN, creating a Target CDN URI (2) (alternatively, the Target CDN URI itself is embedded in the HTML). The Target CDN URI is the Signed URI, which may include the IP address of the UA and/or a time - window. The signed URI always contains a signed JWT generated by the + window. The Signed URI always contains a signed JWT generated by the CSP using a shared secret or private key. Once the UA receives the response with the Signed URI, it sends a new HTTP request using the Signed URI to the CDN (3). Upon receiving the request, the CDN @@ -362,11 +362,14 @@ title) for use on https://www.rfc-editor.org/search. --> The following is an example where the URI Signing Package Attribute name is "token" and the signed JWT is "SIGNEDJWT": - + @@ -390,7 +393,7 @@ Note that it is acceptable to leave the type attribute empty. "mandatory" identifiers in square brackets refer to whether or not a given claim MUST be present in a URI Signing JWT.) Note: The time on the entities that generate and - verify the signed URI MUST be in sync. In the CDNI case, this + verify the Signed URI MUST be 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 for time synchronization. @@ -405,8 +408,8 @@ Note that it is acceptable to leave the type attribute empty. Issuer (iss) [optional] - The semantics in MUST be followed. If this claim is used, it MUST be used to identify the - issuer (signer) of the JWT. In particular, the recipient will have already - received, in trusted configuration, a mapping of issuer name to one or more + Issuer (signer) of the JWT. In particular, the recipient will have already + received, in trusted configuration, a mapping of Issuer name to one or more keys used to sign JWTs and must verify that the JWT was signed by one of those keys. If this claim is used and the CDN verifying the signed JWT does not support Issuer verification, or if the @@ -620,7 +623,7 @@ sectionFormat="of" section="4.1.7" format="default"/> MUST be fo 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 CDN SHOULD send the client a token to return for future requests wherein the first CDNI Signed Token Depth segments of the path match the first - CDNI Signed Token Depth segments of the signed URI path. This matching MUST use the URI with the + CDNI Signed Token Depth segments of the Signed URI path. This matching MUST use the URI with the token removed, as specified in . 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 @@ -676,9 +679,12 @@ purposes only):" Original: [^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)? + +Changed below. + --> Note: Due to computational complexity of executing arbitrary regular expressions, it is RECOMMENDED to only execute after verifying the JWT to ensure its authenticity. @@ -761,7 +767,7 @@ Original:
- Communicating a Signed JWTs in Signed Token Renewal + Communicating a Signed JWT in Signed Token Renewal This section assumes the value of the CDNI Signed Token Transport (cdnistt) claim has been set to 1. @@ -949,14 +958,14 @@ in the JWT token. The following is an example of a URI Signing metadata payload with all default values: - The following is an example of a URI Signing metadata payload with explicit values: - | |<-------------------------------------------------------------| | | | | - |6.CSP provides signed URI | | + |6.CSP provides Signed URI | | |<-------------------------------------------------------------| | | | | |7.Content request | | | - |---------------------------------------->| [Verify URI | + |---------------------------------------->| [Verify URI | | | | signature] | | | | | | | (ALT: Verification result) | @@ -1094,7 +1103,7 @@ in the JWT token. |<----------------------------------------| | | | | | |9.Re-sign URI and redirect to | | - | dCDN (newly signed URI) | | + | dCDN (newly Signed URI) | | |<----------------------------------------| | | | | | |10.Content request | | | @@ -1116,11 +1125,11 @@ in the JWT token. interface, the dCDN advertises its capabilities including URI Signing support to the uCDN.
  • CSP provides to the uCDN the information needed to - verify signed URIs from that CSP. For example, this + verify Signed URIs from that CSP. For example, this information will include one or more keys used for validation.
  • Using the CDNI Metadata interface, the uCDN communicates to a dCDN the information needed to - verify signed URIs from the uCDN for the given + verify Signed URIs from the uCDN for the given CSP. For example, this information may include the URI query string parameter name for the URI Signing Package Attribute in addition to keys used for validation.
    • @@ -1146,7 +1155,7 @@ in the JWT token. provides it to the end user as the URI to use to further request the content from the dCDN.
  • On receipt of the corresponding content request, the - dCDN verifies the Signed JWT in the signed URI using the + dCDN verifies the Signed JWT in the Signed URI using the information provided by the uCDN in the CDNI Metadata.
  • If the verification result is negative, the dCDN rejects the @@ -1185,6 +1194,8 @@ in the JWT token. @@ -1192,6 +1203,9 @@ Perhaps:
    DNS-based Request Routing with URI Signing @@ -1218,7 +1232,7 @@ intstances of FCI? |5.Request is denied | | | |<-------------------------------------------------------------| | | | | - |6.Provides signed URI | | + |6.Provides Signed URI | | |<-------------------------------------------------------------| | | | | |7.DNS request | | | @@ -1787,6 +1801,8 @@ of RFC 9246 @@ -1908,6 +1927,8 @@ Perhaps: this be used instead of the current 2014 version (which has been withdrawn)? +Yes. + Current: [MPEG-DASH] ISO, "Information technology - Dynamic adaptive streaming @@ -1935,10 +1956,10 @@ Current: This section contains three examples of token usage: a simple example with only the required claim present, a complex example that demonstrates the full JWT claims set, including an encrypted Client IP Address (cdniip), and one that uses a Signed Token Renewal. - Note: All of the examples have whitespace added to improve formatting and readability, + Note: All of the examples have empty space added to improve formatting and readability, but are not present in the generated content. All examples use the following JWK Set : - - @@ -2039,7 +2065,7 @@ F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g The JWT Claim Set before signing: - The JWT Claim Set before signing: - The JWT Claim Set before signing: -