Liaison statement
Liaison Statement to IETF on URI signing
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2015-11-02 |
From Group | ISO-IEC-JTC1-SC29-WG11 |
From Contact | Shinji Watanabe |
To Group | cdni |
To Contacts | Francois Le Faucheur <flefauch@cisco.com> Daryl Malas <d.malas@cablelabs.com> Kevin Ma <kevin.j.ma@ericsson.com> |
Cc | Barry Leiba <barryleiba@computer.org> Ben Campbell <ben@nostrum.com> Content Delivery Networks Interconnection Discussion List <cdni@ietf.org> Alissa Cooper <alissa@cooperw.in> Francois Le Faucheur <flefauch@cisco.com> Kevin Ma <kevin.j.ma@ericsson.com> Stephan Wenger <stewe@stewe.org> Daryl Malas <d.malas@cablelabs.com> |
Response Contact | Watanabe Shinji <watanabe@itscj.ipsj.or.jp> |
Purpose | For information |
Attachments |
29n153811 htm
29n153811 |
Liaisons referring to this one |
Response to request for information on URI Signing 2015-11-02
|
Body |
At the 113th MPEG meeting MPEG experts took note of the new draft "URI Signing for HTTP Adaptive Streaming". This document specifically addresses the use case of segmented content in the context of URI Signing. MPEG experts progressed regarding the integration of URI Signing extension for segmented content in MPEG DASH. In discussion we had several comments and observations that MPEG experts would like to share with the IETF CDNI working group. MPEG welcome comments and feedback on the reported progress. Integrated workflow MPEG experts reached consensus on recommending the following steps for the integration of URI Signing extension for segmented content and client authentication and authorisation scheme (Example of such a scheme is the Online Multimedia Authorization Protocol (OMAP) publicly available online). 1. The service provider choses a given client authentication and authorisation scheme to protect the access to the MPD. The application around the DASH client takes care of implementing the protocol in order to successfully receive the MPD. 2. The initial segment access token is provided either in the HTTP response of the MPD or within the MPD itself. 3. The MPD contains appropriate instructions which signal to the DASH client where the segment access token must be extracted from, e.g. either from HTTP header of segment responses. In addition, this signalling instructs the DASH client to insert this segment token back in segment requests as a query string parameter. Note that MPEG included this generic mechanism of transparent parameter passing in an ongoing amendment of MPEG DASH part 1. This document should reach publication in the course of 2016. 4. The segment access token is not meant to be validated by the authorization provider but solely by the CDN to guarantee an easily scalable and stateless validation. To this end, MPEG experts acknowledged the need of a parameter functionally equivalent to the Path Pattern defined in the URI Signing for HTTP Adaptive Streaming. As a result, the URI Signing for HTTP Adaptive Streaming seems to fulfil the identified requirements and will be considered for further work. Furthermore, here are comments from MPEG experts on the URI Signing for HTTP Adaptive Streaming draft. Long-term tokens (into sentences) Some DASH services may use long-term tokens to request segments, where long-term typically means couple of hours to several days. In this scenario, additional tokens (not URI Signed Token) are sent along to enforce client authentication. As a result, refreshing the URI Signed Token at every request may seem superfluous. MPEG experts would like to know the opinion of the IETF CDNI working group on this scenario and whether the validation mechanism could be adapted, e.g. by signalling when the CDN must regenerate a new URI Signed Token. Name collision MPEG experts understand that the name URISigningPackage, as a query string, as an HTTP header parameter or in a cookie, constitutes a normative aspect of the URI Signing specification. MPEG experts would like to know whether the IETF CDNI working group has decided the appropriate approach to prevent name collision. Consecutive tokens According to the URI Signing for HTTP Adaptive Streaming draft, the server may issue multiple tokens and delivered them in consecutive HTTP requests. It does not seem that there is a dependency between the tokens. Could IETF expert confirm that a token issued at time t does not invalidate a token issued prior to time t ? MPEG kindly asks the IETF CDNI working group to consider the above observations and welcome further collaboration on this topic. Our future meetings: - DASH Ad-hoc meetings, 21 February 2016, San Diego, CA - The 114th MPEG meeting, 22 - 26 February 2016, San Diego, CA |