Enable token renewal through pathway cloning

[nicoweil]

Tokens renewal was a popular SVTA meeting discussion topic, and we converged on the idea that using Content Steering to provide this functionality would be very convenient. If tokenization is done through query string parameters, we don't need anything more than what we have in the spec already, as we have "URI-REPLACEMENT.PARAMS where we can transport the new token when doing the pathway cloning.

However, when we need to transport the token in the path (as first sub-path after the hostname) - which is the preferred method to secure access to both manifests and segments without rewriting the manifests - this doesn't work anymore, as the pathway cloning would need to provide new paths for the representations. As an example, we would like to transform
https://www.example.com/< OLD-TOKEN >/path/to/content/
into
https://www.example.com/< NEW-TOKEN >/path/to/content/

In the HLS steering spec we would be doing that through URI-REPLACEMENT.PER-VARIANT-URIS and URI-REPLACEMENT.PER-RENDITION-URIS. In the DASH-IF steering spec we don't have an equivalent solution. Please note that we don't want to store < OLD-TOKEN > or < NEW-TOKEN > in the BaseURL element in manifests, as that would imply manifest manipulation per end-user (which we want to avoid).

There are multiple problems to solve here:

• how to transport the tokens through steering server responses: URI-REPLACEMENT.PER-VARIANT-URIS and URI-REPLACEMENT.PER-RENDITION-URIS don't really work well with DASH as multiple representations are grouped in adaptation sets
• the first URI sub-path where we transport < OLD-TOKEN > and < NEW-TOKEN > is not surfaced in the manifests, but just vended to the player with the initial MPD url when the playback session starts. The player would keep it in consideration when crafting the new urls as a consequence of the pathway cloning instructions, so we would need a mechanism (redirect?) to tell the player that it needs to update it with the < NEW-TOKEN > value.

[nicoweil]

The previous "preferred method to secure access to both manifests and segments without rewriting the manifests" statement might actually be not accurate as the token query string can be passed onto the segments urls through UrlQueryInfo without manifest manipulation. That might be an acceptable trade-off.

[haudiobe]

@dsilhavy @wilaw @yreznik @agiladi please check

[haudiobe]

@dsilhavy @wilaw @yreznik @agiladi please check

[nicoweil]

I believe Gwendal Simon at Synamedia has got a working HLS implementation of Common Access Token renewal through pathway cloning (he was talking about it at Demuxed last week). Maybe we could leverage his experience to make some progress on the DASH version of it?

[gwendalsimon]

Indeed, my (short) Demuxed talk extended the idea that we initially discussed in February. I rather focused on the global architecture, based on our chat on the underlying HLS spec of content steering.

We distinguish the Token Generator, the Multi-CDN balancing decision component, and the steering server. The steering server assigns an ID to an end-user at the first connection and does the profiling. This ID will be carried during the session (RELOAD-URI). At each request, the steering server calls the balancing decision component to get the target CDN for this ID, and then calls the token generator to get a specific token for the next TTL. The token renewal by content steering can be on two vehicles:

• query parameters, through PATHWAY-CLONES.URI-REPLACEMENT.PARAMS (see example 9.12 in RFC 8216bis)
• URL in path, through PATHWAY-CLONES.URI-REPLACEMENT.PER-RENDITION-URIS (see example 9.13)

I don't see any implementation for the two other traditional vehicles of token (cookies and HTTP header). But, as mentioned in the original comment, the two existing approaches (query and path) are good.

The Demuxed talk was about the Token Generator. Ideally, we would like this generator to run at the Provider's back-office, which is the one that expectedly deals with authentication of end-users. We suppose that all CDNs can process the token, typically based on Common Access Token. The Token Generator manages the key for signing the token, and it is expected to share the keys with every CDN. It would be a good practice to have different keys across the different CDNs, to limit CDN leeching.

We suggest that, at every request, the steering server calls an API at the provider's back-office, with ID + some extra-parameters collected from the request (e.g. IP:port and User Agent) to allow back office validation + the target CDN (chosen by the balancing algorithm). The steering server gets back the new token, which is tailored to this end-user and to this CDN.

The token would be renewed as frequently as the multi-CDN update (which is typically sub-minute). The good point is that token renewal is usually a complicated task, so service providers are reluctant to do it too frequently. Here, the renewal does not require HTTP redirection, nor player support (besides HLS content steering). The load at the Token Generator can be significant, but it is the price to pay for higher content protection.

Hope it helps,

[haudiobe]

IOP WG 2024/10/29

• continue discussion
• invite CTA WAVE CAT for a presentation in a special session and discuss the relation to DASH functionalities including Content Steering @lpiron - can you help?