Subject: [CDNi] New Liaison Statement, "Liaison Statement to IETF on URI signing"

From: Liaison Statement Management Tool <[email-masked]>
Date: Mon, 02 Nov 2015 20:12:27 -0800

Title: Liaison Statement to IETF on URI signing
Submission Date: 2015-11-02
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1434/

From:  (Shinji Watanabe <[email-masked]>)
To:  (Francois Le Faucheur <[email-masked]>,Daryl Malas <[email-masked]>,Kevin Ma <[email-masked]>)
Cc: 
Response Contacts: Watanabe Shinji <[email-masked]>
Technical Contacts: 
Purpose: For information

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

Attachments:

    29n153811
    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-11-02-iso-iec-jtc1-sc29-wg11-cdni-liaison-statement-to-ietf-on-uri-signing-attachment-1.doc

    29n153811 htm
    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-11-02-iso-iec-jtc1-sc29-wg11-cdni-liaison-statement-to-ietf-on-uri-signing-attachment-2.htm

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 3 Nov 2015 07:53:32 +0000

Colleagues,

My 2p (¥3.7) inline

> On 3 Nov 2015, at 04:12, Liaison Statement Management Tool <[email-masked]> wrote:
> 

I wonder if MPEG also considered setting the token in a cookie, e.g. on the MPD response? For the situations where it works* it’s a better option than query parameters IMO and means the client doesn’t have to do anything special to have the token inserted on every request as the HTTP stack will do that as part of HTTP.

*cookies don’t work in all environments, e.g. blockers on browsers or clients where the player has an independent cookie jar to the rest of the app/browser but if you’re going to do something like insert the token into the request using special client handling anyway, you could do the same for a cookie and have the benefit of only having to do it once rather than once per segment.

> 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…

A single token can be given a long expiry time so I’m not completely certain what the MPEG use case is. That provides a long time in which a token could be passed to someone else, which drove the idea of changing the token from the CDN side on every segment which reduces the exposure time to the minimum possible. It seems that what MPEG is asking for is the ability to tune the exposure time.

IMO it sounds a nice knob to have in theory, but I’m wondering why someone would actually tune it in practice. Generating tokens is pretty cheap, it’s basically a single call to a SHA hash function. I think it also increases the implementation complexity significantly. With a long use single token or with re-writing the token on every segment the CDN can process each request independently. With a token that changes after a variable number of segments, the CDN now needs to keep state about how many times it has seen the token already and needs to co-ordinate that state across the CDN in case some of the requests go to different surrogates, etc. 

It sounds like a lot of complexity for little real benefit IMO.
 
> 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 bet…

In the 3 token implementations I am familiar with tokens are completely independent and a token issued at time t does not invalidate a token issued prior to time t.

Ben

> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 3 Nov 2015 08:58:30 +0000

Hi all,

I've added my comments below.

Ray

>*cookies don’t work in all environments, e.g. blockers on browsers or clients where the player has an independent cookie jar to the rest of the app/browser but if you’re going to do something like i…

Agreed. 

My feeling is you'd want both a cookie-based as well as a query parameter-based solution. The cookie-based version for legacy clients, and a query-based version in cases where cookie's don't work. In the uri-signing-for-HAS draft I've added a flag to allow the CDN/CSP to communicate which mechanism should be applied.

>It sounds like a lot of complexity for little real benefit IMO.

Fully agree.

(One way to implement it would be to have some sort of Expiration Time Threshold to indicate when the CDN should refresh the token, but that would result in all kinds of issues, such as effectively having variable token lengths which will cause issues in cases of prolonged pause)

>> 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 expert…

The current base URI signing spec already allows overriding the URISigningPackage query string parameter based on e.g. Metadata. In case of DASH, and clients having to know this name, I think the best solution would be to just convey it in the MPD.

>In the 3 token implementations I am familiar with tokens are completely independent and a token issued at time t does not invalidate a token issued prior to time t.

Agreed. Apart from having to keep and synchronise state across nodes, I don't see how you could even implement it. 

>>    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-11-02-iso-iec-jtc1-sc29-wg11-cdni-liaison-statement-to-ietf-on-uri-signing-attachment-2.htm
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 3 Nov 2015 11:18:42 +0000

Ray,

I wouldn't signal to the CDN whether it should expect the token in a cookie or a query param, if it was me I'd spec it so the CDN has to support both and a rule for which of cookie or query param to use if both are present.

Ben

> On 3 Nov 2015, at 08:58, Brandenburg, R. (Ray) van <[email-masked]> wrote:
> 
> Hi all,
>

---

From: "c^" <[email-masked]>
Date: Tue, 3 Nov 2015 21:21:16 +0900

Cookie use also creates other dependencies when using MSE such as
crossdomain/CORS which can be problematic in certain deployments.

Query string based is more portable...

WRT generating tokens being 'cheap'; consider the flash crowds associated
with news events on live streams. Token generation in these circumstance is
very different to the moderate peak:mean in on-demand video workflows. The
trade off being an extended time limited token being 'good enough'...

I can go into some of these considerations further off list...

CraigT

--
c%5e
On 3 Nov 2015 20:20, "Ben Niven-Jenkins" <[email-masked]> wrote:

> Ray,
>
> I wouldn't signal to the CDN whether it should expect the token in a
> cookie or a query param, if it was me I'd spec it so the CDN has to support
> both and a rule for which of cookie or query param to use if both are
> present.
>
> Ben
>
> >> On 03/11/15 08:53, "CDNi on behalf of Ben Niven-Jenkins" <
> [email-masked] on behalf of [email-masked]> wrote:
> >>
> >> Colleagues,
> >>
> >> My 2p (¥3.7) inline
> >>
> >>
> >>> 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.
> >>
> >> I wonder if MPEG also considered setting the token in a cookie, e.g. on
> the MPD response? For the situations where it works* it’s a better option
> than query parameters IMO and means the client doesn’t have to do anything
> special to have the token inserted on every request as the HTTP stack will
> do that as part of HTTP.
> >>
> >> *cookies don’t work in all environments, e.g. blockers on browsers or
> clients where the player has an independent cookie jar to the rest of the
> app/browser but if you’re going to do something like insert the token into
> the request using special client handling anyway, you could do the same for
> a cookie and have the benefit of only having to do it once rather than once
> per segment.
> >
> > Agreed.
> >
> > My feeling is you'd want both a cookie-based as well as a query
> parameter-based solution. The cookie-based version for legacy clients, and
> a query-based version in cases where cookie's don't work. In the
> uri-signing-for-HAS draft I've added a flag to allow the CDN/CSP to
> communicate which mechanism should be applied.
> >
> >>
> >>> 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.
> >>>
> >>>
> >>> 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.
> >>
> >> A single token can be given a long expiry time so I’m not completely
> certain what the MPEG use case is. That provides a long time in which a
> token could be passed to someone else, which drove the idea of changing the
> token from the CDN side on every segment which reduces the exposure time to
> the minimum possible. It seems that what MPEG is asking for is the ability
> to tune the exposure time.
> >>
> >> IMO it sounds a nice knob to have in theory, but I’m wondering why
> someone would actually tune it in practice. Generating tokens is pretty
> cheap, it’s basically a single call to a SHA hash function. I think it also
> increases the implementation complexity significantly. With a long use
> single token or with re-writing the token on every segment the CDN can
> process each request independently. With a token that changes after a
> variable number of segments, the CDN now needs to keep state about how many
> times it has seen the token already and needs to co-ordinate that state
> across the CDN in case some of the requests go to different surrogates, etc.
> >>
> > (One way to implement it would be to have some sort of Expiration Time
> Threshold to indicate when the CDN should refresh the token, but that would
> result in all kinds of issues, such as effectively having variable token
> lengths which will cause issues in cases of prolonged pause)
> >
> >>
> >>> 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.
> >
> > The current base URI signing spec already allows overriding the
> URISigningPackage query string parameter based on e.g. Metadata. In case of
> DASH, and clients having to know this name, I think the best solution would
> be to just convey it in the MPD.
> >
> >>>
> >>> 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 ?
> >>
> >> In the 3 token implementations I am familiar with tokens are completely
> independent and a token issued at time t does not invalidate a token issued
> prior to time t.
> >
> > Agreed. Apart from having to keep and synchronise state across nodes, I
> don't see how you could even implement it.
> >
> >>
> >> Ben
> >>
> >>>
> >>>
> >>> MPEG kindly asks the IETF CDNI working group to consider the above
> observations and welcome further collaboration on this topic.
> >>>
> >>>
> >>>
> >>> Our future meetings:
> > This message may contain information that is not intended for you. If
> you are not the addressee or if this message was sent to you by mistake,
> you are requested to inform the sender and delete the message. TNO accepts
> no liability for the content of this e-mail, for the manner in which you
> use it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 4 Nov 2015 18:11:54 +0000

Craig,

> On 3 Nov 2015, at 12:21, c^ <[email-masked]> wrote:
> 
> Cookie use also creates other dependencies when using MSE such as crossdomain/CORS which can be problematic in certain deployments.
> 
But not without its own set of issues. There is no single answer here IMO. BTW I wasn’t trying to suggest that MPEG avoid query parameters and use cookies instead but to ponder whether they’d considered cookies as part of the solution space as if it was considered and discounted I’d be interested in what led to that choice.

> WRT generating tokens being 'cheap'; consider the flash crowds associated with news events on live streams. Token generation in these circumstance is very different to the moderate peak:mean in on-demand video workflows.
> 
Sure but such flash crowds put stress on the whole delivery chain and I highly suspect that the overhead of generating tokens will not be the weakest link that causes a flash crowd to impact a streaming service.

> The trade off being an extended time limited token being 'good enough'…
> 
That was part of my point. If one has the option to create a long lived single token and one has the option to chain tokens on each request then I’m struggling to understand what benefit there is to having a third option that is somewhere in the middle.
> I can go into some of these considerations further off list…
> 
I’d certainly be interested in discussing this stuff more either on or off list.

Ben

> CraigT
> 
> --
> c%5e
> 
> On 3 Nov 2015 20:20, "Ben Niven-Jenkins" <[email-masked] <mailto:[email-masked]>> wrote:
> Ray,
> 
> > On 3 Nov 2015, at 08:58, Brandenburg, R. (Ray) van <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hi all,
> >
> >> On 03/11/15 08:53, "CDNi on behalf of Ben Niven-Jenkins" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> Colleagues,
> >>
> >> My 2p (¥3.7) inline
> >>
> >>
> >>> On 3 Nov 2015, at 04:12, Liaison Statement Management Tool <[email-masked] <mailto:[email-masked]>> wrote:
> >>>
> >>>  https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-11-02-iso-iec-jtc1-sc29-wg11-cdni-liaison-statement-to-ietf-on-uri-signing-attachment-1.doc <https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-11-02-iso-iec-jtc1-sc29-wg11-cdni-liaison-statement-to-ietf-on-uri-signing-attachment-1.doc>
> >>>
> >>>  29n153811 htm
> >>>  https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-11-02-iso-iec-jtc1-sc29-wg11-cdni-liaison-statement-to-ietf-on-uri-signing-attachment-2.htm <https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-11-02-iso-iec-jtc1-sc29-wg11-cdni-liaison-statement-to-ietf-on-uri-signing-attachment-2.htm>
> >>>
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/cdni <https://www.ietf.org/mailman/listinfo/cdni>
> >>
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/cdni <https://www.ietf.org/mailman/listinfo/cdni>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cdni <https://www.ietf.org/mailman/listinfo/cdni>