Re: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-22.txt

[Chris Lemmons <[e-mail]>]

Agreed, and your version uses even fewer words, which I like. And the
only reason not to reference 3.2.9 is an error on my part. It should
be included. It feels slightly odd to include a normative reference
parenthetically, but it's not wrong. It definitely reads better.

On Wed, Nov 10, 2021 at 11:06 AM Kevin Ma <[e-mail]> wrote:
>
> note: we could also use direct section references...
>
> On Wed, Nov 10, 2021 at 1:05 PM Kevin Ma <[e-mail]> wrote:
>>
>> Thanks for the text Chris,
>>
>>   Is there a reason to only reference 3.2.8 and not 3.2.9 for form-style parameters?
>>
>>   There is some redundancy in the MUSTs.  What about:
>>
>> The URI Signing Package will be found by parsing any path-style parameters [RFC6570] and form-style parameters [RFC6570] looking for a key name matching the URI Signing Package Attribute.  Both path-style parameters (generated in the form indicated by Section 3.2.7 of [RFC6570]) and form-style parameters (generated in the form indicated by Sections 3.2.8 and 3.2.9 of [RFC6570]) MUST be supported.  The first matching parameter SHOULD be taken to provide the signed JWT, though providing more than one matching key is undefined behavior.
>>
>> thanx!
>>
>> --  Kevin J. Ma
>>
>> On Wed, Nov 10, 2021 at 2:38 AM Chris Lemmons <[e-mail]> wrote:
>>>
>>> To save a click, here's the text:
>>>
>>> The URI Signing Package will be found by parsing any path-style parameters and
>>> form-style parameters looking for a key name matching the URI Signing
>>> Package Attribute.
>>> Both parameter styles MUST be supported to allow flexibility of operation.
>>> The first matching parameter SHOULD be taken to provide the signed
>>> JWT, though providing
>>> more than one matching key is undefined behavior. Path-style
>>> parameters generated in the
>>> form indicated by Section 3.2.7 of [RFC6570] MUST be supported.
>>> Form-style parameters generated in the form indicated by Section 3.2.8
>>> of [RFC6570]
>>> MUST be supported.
>>>
>>> The last two sentences are what I'm proposing we add. This was the
>>> simplest variation I could come up with that doesn't add a whole bunch
>>> of construction rules to this document, but provides at least one
>>> clear MUST-accept implementation for each style that allows a dCDN to
>>> be certain that it knows how to find the URIs.
>>>
>>> On Tue, Nov 9, 2021 at 8:46 AM Phil Sorber <[e-mail]> wrote:
>>> >
>>> > Thanks, I merged two of these, but I think we should have a little more time to think on #72 before we merge it, just because it's been so debated and I don't want to keep changing it.
>>> >
>>> > On Tue, Nov 9, 2021 at 1:01 AM Chris Lemmons <[e-mail]> wrote:
>>> >>
>>> >> Fixes for nits, regrettably also including the same ones you just
>>> >> fixed in 69: https://github.com/PSUdaemon/URISigningSpec/pull/70
>>> >>
>>> >> Updates that I _think_ fix the weird figure text? I'm not certain this
>>> >> is the best way to do it, but the existing way looks odd. Look at the
>>> >> diff linked earlier and check out the figure titles.
>>> >> https://github.com/PSUdaemon/URISigningSpec/pull/71
>>> >>
>>> >> The much-belated text I promised a while back on 6570:
>>> >> https://github.com/PSUdaemon/URISigningSpec/pull/72
>>> >>
>>> >> On Mon, Nov 8, 2021 at 7:55 PM Phil Sorber <[e-mail]> wrote:
>>> >> >
>>> >> > https://github.com/PSUdaemon/URISigningSpec/pull/69
>>> >> >
>>> >> > On Sat, Nov 6, 2021 at 10:02 PM Kevin Ma <[e-mail]> wrote:
>>> >> >>
>>> >> >> Hi Phil,
>>> >> >>
>>> >> >>   Thanks for getting the updated draft out.  A couple typos/nits:
>>> >> >>
>>> >> >>   - section 2.1.10: "for example in" -> "for example, in"
>>> >> >>   - section 3.2.1: "MAY bt" -> "MAY be"
>>> >> >>   - section 4: "after and access" -> "after an access"
>>> >> >>   - section 4.4: remove "against the key issuer with"
>>> >> >>   - section 5.2: "Sigbned" -> "Signed"
>>> >> >>
>>> >> >> --  Kevin J. Ma
>>> >> >>
>>> >> >>
>>> >> >> On Mon, Oct 25, 2021 at 7:12 PM <[e-mail]> wrote:
>>> >> >>>
>>> >> >>>
>>> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> >> >>> This draft is a work item of the Content Delivery Networks Interconnection WG of the IETF.
>>> >> >>>
>>> >> >>>         Title           : URI Signing for Content Delivery Network Interconnection (CDNI)
>>> >> >>>         Authors         : Ray van Brandenburg
>>> >> >>>                           Kent Leung
>>> >> >>>                           Phil Sorber
>>> >> >>>         Filename        : draft-ietf-cdni-uri-signing-22.txt
>>> >> >>>         Pages           : 42
>>> >> >>>         Date            : 2021-10-25
>>> >> >>>
>>> >> >>> Abstract:
>>> >> >>>    This document describes how the concept of URI Signing supports the
>>> >> >>>    content access control requirements of Content Delivery Network
>>> >> >>>    Interconnection (CDNI) and proposes a URI Signing method as a JSON
>>> >> >>>    Web Token (JWT) profile.
>>> >> >>>
>>> >> >>>    The proposed URI Signing method specifies the information needed to
>>> >> >>>    be included in the URI to transmit the signed JWT, as well as the
>>> >> >>>    claims needed by the signed JWT to authorize a User Agent (UA).  The
>>> >> >>>    mechanism described can be used both in CDNI and single Content
>>> >> >>>    Delivery Network (CDN) scenarios.
>>> >> >>>
>>> >> >>>
>>> >> >>> The IETF datatracker status page for this draft is:
>>> >> >>> https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/
>>> >> >>>
>>> >> >>> There is also an htmlized version available at:
>>> >> >>> https://datatracker.ietf.org/doc/html/draft-ietf-cdni-uri-signing-22
>>> >> >>>
>>> >> >>> A diff from the previous version is available at:
>>> >> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-uri-signing-22
>>> >> >>>
>>> >> >>>
>>> >> >>> Internet-Drafts are also available by anonymous FTP at:
>>> >> >>> ftp://ftp.ietf.org/internet-drafts/
>>> >> >>>
>>> >> >>>
>>> >> >>> _______________________________________________
>>> >> >>> CDNi mailing list
>>> >> >>> [e-mail]
>>> >> >>> https://www.ietf.org/mailman/listinfo/cdni
>>> >> >
>>> >> > _______________________________________________
>>> >> > CDNi mailing list
>>> >> > [e-mail]
>>> >> > https://www.ietf.org/mailman/listinfo/cdni