Skip to main content

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