Subject: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-21.txt

From: [email-masked]
Date: Thu, 11 Feb 2021 11:31:51 -0800

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-21.txt
	Pages           : 41
	Date            : 2021-02-11

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 are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-21
https://datatracker.ietf.org/doc/html/draft-ietf-cdni-uri-signing-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-uri-signing-21

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Chris Lemmons <[email-masked]>
Date: Fri, 12 Feb 2021 09:24:48 -0700

The latest document replaces the path parsing logic with this:

> URI Signing Package (URISigningPackage): The URI attribute that encapsulates all the URI Signing claims in a signed JWT encoded format.  This attribute is exposed in the Signed URI as a path-style parameter or a form-style parameter.

Unfortunately, that doesn't give implementers any idea what needs to
be parsed. I read through the conversation on last-call with mnot
(https://mailarchive.ietf.org/arch/msg/last-call/yIhgGSja7_OoFXK_SGQUuhMdO2o/),
especially with regard to BCP190. I also read through RFC6570 and
you're right, it doesn't work for our use case because it's generating
URI, not consuming them. And it's for precisely this reason that we
need to be specific in what is accepted.

As near as I can tell, there is actually no standard anywhere that
describes "path-style parameters". And there are multiple methods for
defining "form-style parameters", some more recent than others and in
varying levels of use generally on the Internet. How can a document
have a MUST requirement that requires parsing a specific structure
that isn't specified anywhere or even widely agreed upon?

On Thu, Feb 11, 2021 at 12:32 PM <[email-masked]> wrote:
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni