Auth Cookies Not Specified

[fluffy]

This is a placeholder that we need to sort out how Auth and auth tokens work in MoQ.

Requirements:

1. Can control what users can connect to a relay.
2. Can control if a user can publish to a given namespace.
3. Can control if a user can subscribe to a given namespace.
4. Can update auth for long lived track that is longer than token lifetime
5. Design that allows for relay to validate tokens locally
6. As much as possible, reuse approaches used for existing systems

What am I missing on requirements

[wilaw]

For point [6], we might consider support for CTA 5007 - Common Access Token (CAT), a standard (soon) published by the CTA. This is a CBOR token for compactness, with many claim fields as well a boolean operations for composite claims. It is likely to become a popular standard for OTT content, so harmonizing MoQT with that side of the industry brings some efficiency gains.

For additional requirements, support both symmetric and asymmetric ciphers.

[gwendalsimon]

1. Can control what users can connect to a relay.
2. Can control if a user can publish to a given namespace.
3. Can control if a user can subscribe to a given namespace.

It can be made even more specific to track name level. For example no access to UHD video track for some users. Or watch the video but no access to some associated chatrooms or premium metadata tracks.

4. Can update auth for long lived track that is longer than token lifetime
5. Design that allows for relay to validate tokens locally

Relay may also generate tokens locally. It is especially useful for token renewal (or update).

6. As much as possible, reuse approaches used for existing systems

+1 on Common Access Token (CAT).

What am I missing on requirements

Note sure if it would require a separate Issue, but the question of watermark can also be raised. Today's OTT watermarking solutions are based on some WM tokens, which are some forms of auth tokens.

[martinduke]

Parked for next hybrid Interim.