[CDNi] Comments on draft 16

["Kolev, Nikola" <[e-mail]>]

Hello,

I am not sure what the protocol for providing feedback to this memo is so I have included it in this email below. Please let me know what the preferred method is and I would resubmit.

Thanks,
Nikola Kolev

(Re)
2.1.2.  Subject (sub) claim

   Subject (sub) [optional] - The semantics in [RFC7519] Section 4.1.2
   MUST be followed.  If this claim is used, it MUST be a JSON Web
   Encryption (JWE [RFC7516]) Object in compact serialization form,
   because it contains personally identifiable information.

Comment: Why? The subject claim does not necessarily need to contain PII. Also, it would be better that the specification leaves this claim's encoding to "service providers" which may choose a "more optimal", than JWE, encoding scheme even in the case where the claim carries PII and (some portion of) the claim is encrypted.

(Re)
2.1.4.  Expiry Time (exp) claim

   Expiry Time (exp) [optional] - The semantics in [RFC7519]
   Section 4.1.4 MUST be followed, though URI Signing implementations
   .. .. or if the Expiry Time in
   the signed JWT corresponds to a time earlier than the time of the
   content request, the CDN MUST reject the request. .. .. ..

Comment: If I am not mistaken the `exp` claim carries **on** or after semantics. Hence the memo should read not just **earlier**, as on should result in rejection as well.

(Re)
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.


Comment: Should be specified as list. Same as the `crit` header claim, https://tools.ietf.org/html/rfc7515#section-4.1.11. "Its value is a comma separated..." could be misinterpreted as a StringOrURI carrying a CSV value.

(Re)
2.1.11.  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.15.  If the URI regex ..

Comment: URI regex is only one of the forms that the claim can assume.

(Re)
6.4.  CDNI URI Signing Signed Token Transport

   The "CDNI URI Signing Signed Token Transport" namespace defines the
   valid values that may be in the Signed Token Transport (cdnistt) JWT
   claim.

   The following table defines the initial Enforcement Information
   Elements:

    +-------+-------------------------------------------+---------+
    | Value | Description                               | RFC     |
    +-------+-------------------------------------------+---------+
    | 0     | Designates token transport is not enabled | RFCthis |
    | 1     | Designates token transport via cookie     | RFCthis |
    +-------+-------------------------------------------+---------+

Comment/Question: I would imagine a system where the CDN is not the authority that handles token renewals, but instead the CDN sends the user agent back to the original token issuer. Can the working group consider this architecture and expand the list of “token transport” mechanisms, to include for example HTTP redirects?