Add support for CTA-WAVE Common Access Token

[msanmart-akamai]

The CTA Common Access Token (CAT) is a CBOR Web Token (CWT) defined by this spec draft. The token workflow requires the participation of the player in the renewal workflow of the token. During a request, and if the CAT in use is about to expire, a new CAT will be generated by the CDN and sent along with the requested media object (a redirect can also be used), after its reception the player will need to switch to the new CAT in a timely manner. For a detailed description of the renewal workflow please see section 4.2. Access an Asset with Renewal of the Token and 6. CAT Replay (catreplay) claim)

[wilaw]

Akamai will be producing a demo for NAB with will issue the following renewal response header of the form

Common-Access-Token = 0oRLogEmBEZhYmMxMjOgWJKlAW9jZG4uZXhhbXBsZS5uZXQEGmVT8g8ZAQ6hA6EBcS9w YXRoL3RvL2NvbnRlbnQvGQEVoQSCGQEzoWhMb2NhdGlvboJ4Jmh0dHBzOi8vYnJhbmQuZXhhbXBsZS5jb20vYXV0aD9 yZXR1cm492HkAGQEWpAABARkBLAIYHgNzQ29tbW9uLUFjY2Vzcy1Ub2tlblhAhyECB-xZFONtEf_13joBNk33X3wb2dr 4EijtLiQJCZV1eIK3pYdOb25T1-Kx5WZliWr9t1lTDoAM8TfQVbmZow

If the player see's this response header, it should extract the new CAT token and then use it for future requests with a customer request header (CORS permissions assumed) of the same name and value.

Example:

Player given a https://example.com/segment1.mp4?CAT=123456abc It make a GET request, without any custom headers, then receives back a custom header in the response

Common-Access-Token = 333xyz

It should then add this header for all future requests under that manifest path , so next request would be

GET https://example.com/segment1.mp4?CAT=123456abc with Common-Access-Token = 333xyz as a request header.

CDN would look first for the Common-Access-Token request header. If it finds it, it will not waste any resources processing the query arg token and will ignore it.

[dsilhavy]

@msanmart-akamai @wilaw Based on your description I added basic support here: https://github.com/Dash-Industry-Forum/dash.js/pull/4419. Can you check the pull request against your server endpoint? I only tested with a quick local setup. Note that you need to add Common-Access-Token to Access-Control-Expose-Headers for a JavaScript client to be able to extract the header from the response.

Example:

Some follow-up questions

• Are the tokens expiring? Or are they valid until the player sees a new Common-Access-Token?
• Is there one valid token per host? Or does the subpath also play role? For instance can there be different tokens for https://example.com/a/ and https://example.com/b/?
• What is the relation to Annex I of the DASH spec? The implementation I did here seems very "simple" and can probably easily be added on the application side using network interceptors exposed by the player.

[ZmGorynych]

For headers output, Annex I needs a minor fix (it forces a prefix to the header name, for security purposes). For query parameters Annex I is workable as is, as well as HLS (using their query parameter mechanism.

[msanmart-akamai]

My comments below.

From: Daniel Silhavy @.> Reply-To: "Dash-Industry-Forum/dash.js" @.> Date: Thursday, March 14, 2024 at 8:59 AM To: "Dash-Industry-Forum/dash.js" @.> Cc: "San-Martin, Marcelo" @.>, Mention @.***> Subject: Re: [Dash-Industry-Forum/dash.js] Add support for CTA-WAVE Common Access Token (Issue #4395)

@msanmart-akamaihttps://urldefense.com/v3/__https:/github.com/msanmart-akamai__;!!GjvTz_vk!VpxDDnzH1o6nMvffRsOiFM8Rk42GHXyAZkAdszzuGaFFFczvdSmV1fVENLuOKw7wPpKBlFcgodfRBMJpaOgAx_U$ @wilawhttps://urldefense.com/v3/__https:/github.com/wilaw__;!!GjvTz_vk!VpxDDnzH1o6nMvffRsOiFM8Rk42GHXyAZkAdszzuGaFFFczvdSmV1fVENLuOKw7wPpKBlFcgodfRBMJpB1UDJXc$ Based on your description I added basic support here: #4419https://urldefense.com/v3/__https:/github.com/Dash-Industry-Forum/dash.js/pull/4419__;!!GjvTz_vk!VpxDDnzH1o6nMvffRsOiFM8Rk42GHXyAZkAdszzuGaFFFczvdSmV1fVENLuOKw7wPpKBlFcgodfRBMJpPHuhIco$. Can you check the pull request against your server endpoint? I only tested with a quick local setup. Note that you need to add Common-Access-Token to Access-Control-Expose-Headers for a JavaScript client to be able to extract the header from the response.

Example: Bildschirmfoto.2024-03-14.um.16.40.16.png (view on web)https://urldefense.com/v3/__https:/github.com/Dash-Industry-Forum/dash.js/assets/2427039/3f97890b-86a3-428e-a8bb-d84b541ff604__;!!GjvTz_vk!VpxDDnzH1o6nMvffRsOiFM8Rk42GHXyAZkAdszzuGaFFFczvdSmV1fVENLuOKw7wPpKBlFcgodfRBMJpTMZ0QoQ$

Some follow-up questions

• Are the tokens expiring? Or are they valid until the player sees a new Common-Access-Token? • Yes the token expires, this is a CWT token an it has an expiration claim “exp”. The player does not need to take an action on this claim. The CDN will add a Common-Access-Token header when the token needs to be renewed (close to the expire time) and just on time for the player to use it.

• Is there one valid token per host? Or does the subpath also play role? For instance can there be different tokens for https://example.com/a/ and https://example.com/b/? • The player should use the token as-is, if there are different URI to be considered the token will be able to accommodate that (using the “or” or “and” claims). Again, the player does not need to know or act on these claims.

• What is the relation to Annex I of the DASH spec? The implementatiom I did here seem very "simple" and can probably easily be added on the application side using network interceptors exposed by the player. • We were thinking that the player should by default support the token, but it is good to know about the interceptors. Thanks for your help, Marcelo

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/Dash-Industry-Forum/dash.js/issues/4395*issuecomment-1997791327__;Iw!!GjvTz_vk!VpxDDnzH1o6nMvffRsOiFM8Rk42GHXyAZkAdszzuGaFFFczvdSmV1fVENLuOKw7wPpKBlFcgodfRBMJp5tVUBVU$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AX5223LJENFZKAB6YZUCPDTYYHCMHAVCNFSM6AAAAABD4Z4U6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXG44TCMZSG4__;!!GjvTz_vk!VpxDDnzH1o6nMvffRsOiFM8Rk42GHXyAZkAdszzuGaFFFczvdSmV1fVENLuOKw7wPpKBlFcgodfRBMJpKetDnC4$. You are receiving this because you were mentioned.Message ID: @.***>

[dsilhavy]

Changes have been merged to development closing this isuse for now. Please let me know in case anything does not work as expected.

[wilaw]

@dsilhavy - here is some feedback today from Shubham Verekar, who is testing this:

---

I have tested this out. Below is my observation.

Once the renewed CAT token is received via response header (Common-Access-Token) i.e., say for master request, the token is correctly forwarded in subsequent request header (Common-Access-Token) for init.mp4 requests. However, I do not see token being forwarded for segment requests. (.m4s) due to which the segment request fails.

Expectation: IMO the token should have been forwarded even for segment requests.

Regards, Shubham

[dsilhavy]

Thanks @wilaw

1. Can you share the teststream with me?
2. Is the segment request going to a different BaseURL than the init request?

[dsilhavy]

The issue is probably causes by a bug in the code that overrides the token with a null value in case the next response does not contain a token header. Potential fix here: https://github.com/Dash-Industry-Forum/dash.js/pull/4434

[dsilhavy]

Changes are merged and available on https://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html. Can you please check again.

[dsilhavy]

Closing this as the fixes applied in #4434 seem to have fixed the issue