Re: [CDNi] Notes from today's Informal Metadata Meeting

[Kevin J Ma <[e-mail]>]

wrt: 
> Authentication for Acquisition
> The current Source object contains a placeholder for authentication. We
> discussed a simple username/password based authentication method in this
> context and agreed to name the auth object "CredentialsAuth". This object
> could be used for HTTP Basic, FTP, or other transfer methods that require
> a username and password.

Note: there was also discussion of other possible authentication methods
      (e.g., scp identity file, or ssl mutual auth client cert), but the
      basic username/password seemed like the bare minimum in lieu of any
      firm requirements.

There is an obvious security concern with passing credentials through the
metadata interface, especially if the uCDN is going to point the dCDN at
not its own caches/origin, but at a further upstream cache/origin, and is
thus propogating credentials that it received from a CDN further upstream
which has no relationship with that dCDN.  If this is a concern for the
operators or anyone in the WG at large, it would be good to have input?

An alternative would be to have an AuthID pointer that identifies some type
of authentication credentials that were delivered out-of-band?

--  Kevin J. Ma

> -----Original Message-----
> From: Matt Caulfield (mcaulfie) [mailto:[e-mail]]
> Sent: Thursday, August 01, 2013 5:01 PM
> To: [e-mail]
> Cc: Kent Leung (kleung); Kevin J Ma; Brandenburg, R. (Ray) van
> ([e-mail]); Rob Murray ([e-mail])
> Subject: Notes from today's Informal Metadata Meeting
> 
> Attendees: Matt Caulfield, Kent Leung, Kevin Ma, Ray van Brandenburg, Rob
> Murray
> 
> "Mandatory-to-enforce"
> The metadata draft defines a property in the GenericMetadata object for
> indicating that a particular piece of metadata is mandatory to enforce. We
> discussed whether or not there is ever a case where this flag would be set
> to false and came up with a few examples related to optional optimizations
> that a CSP may desire but are not strictly required. We also questioned
> whether or not the value of this property should be static (i.e. defined
> by the RFC or standard which also defines the metadata it corresponds to).
> For example, the URI signing draft defines a new metadata object for URI
> signing. Should the CSP/uCDN be allowed to make URI signing mandatory to
> enforce for some content but not other content? Or should mandatory to
> enforce be defined by the URI signing draft as always "true" for URI
> signing metadata? We felt that mandatory-to-enforce SHOULD be static and
> its value SHOULD be taken from the same standard which defines the
> corresponding metadata.
> --> Matt to clarify this point in the Metadata draft
> 
> IANA Registries
> The IANA Considerations section in the Metadata draft is not yet filled
> in. We discussed the required registries for Metadata - such as a registry
> for GenericMetadata types, Protocol types, Location types, etc.
> --> Kevin to identify and fill in IANA Considerations
> 
> Authentication for Acquisition
> The current Source object contains a placeholder for authentication. We
> discussed a simple username/password based authentication method in this
> context and agreed to name the auth object "CredentialsAuth". This object
> could be used for HTTP Basic, FTP, or other transfer methods that require
> a username and password. The Source object could point to a
> CredentialsAuth object or to any other type of Auth object yet to be
> defined. As such, an IANA registry is planned for tracking Auth methods.
> --> Matt to add CredentialsAuth object to Metadata
> 
> Authentication for Delivery
> We were unsure what sort of authentication, if any, should be supported by
> the base metadata draft. We agreed to send a separate email to the list
> inquiring on this topic.
> --> Matt to send email on expect authentication techniques
> 
> Query Parameters Modification
> In the working group meeting on Tuesday, it was noted that the current
> ability to remove query parameters when caching a resource is not
> sufficient for base interoperability. Instead a more flexible scheme is
> needed which instructs a dCDN to remove certain query parameters before
> caching, acquiring, or looking up metadata for a piece of a content.
> --> Matt to update query parameter modification text
> 
> Acquisition Source object
> We discussed some ambiguity in the Source object section. It is not
> currently clear how a dCDN should really use a Source object to acquire
> content from the uCDN, especially for the HTTP redirection case.
> --> Matt to clarify Source section
> 
> Editors notes
> A number of editors notes identify missing areas of the draft.
> --> Above items either address or obviate all current editors notes