Authentication scheme for MOQT using Common Access Tokens

1.1. Overview of the authentication workflow

• An end-user logs-in to a distribution service. The service authenticates the user (via username/password, OAuth, 2FA or another method). The methods involved in this authentication step lie outside the scope of this draft.¶

• Based upon the identity and permissions granted to that end-user, the service generates a token. A token is a data structure that has been serialized into a byte array. The token encodes information such as the user's ID, constraints on how and when they can access the MOQT distribution network and contraints on the actions they can take once connected. The token may be signed to make it tamper-resistent.¶

• The token is given in the clear to the end-user, along with a URL to connect to the edge relay of a MOQT distribution network.¶

• The end-user client application provides the token to the MOQT distribution relay when it connects. This connection may be established over WebTransport or raw QUIC.¶

• The relay decrypts the token upon receipt and validates the signature, using secrets previously shared between the content distributor and the distribution network. Based upon claims conveyed in the token, relay will accept or reject the conneciton.¶

• If the relay accepts the connection, then the client will take a series of MOQT actions: ANNOUNCE, SUBSCRIBE_ANNOUNCES, SUBSCRIBE or FETCH. For each of these, it will supply the token it received using the AUTHENTICATION parameter.¶

• As an alternative to this workflow, the distribution service may vend multiple tokens to the client. The client may use one of those tokens to establish the initial conneciton and others to authenticate its actions.¶

2.1. moqt claim

The "moqt" claim is defined by the following CDDL:¶

$$Claims-Set-Claims //= (moqt-label => moqt-value)
moqt-label = XXX TODO - how do we register this?
moqt-value = [ + moqt-object ]

TODO - need CDDL valid definition. The moqt token needs to encode multiple instances of 4 actions, currently¶

• 0 - ANNOUNCE¶

• 1 - SUBSCRIBE_ANNOUNCES¶

• 2 - PUBLISH¶

• 3 - FETCH¶

For each action, we need to communicate the permission¶

• 0 - Allowed for all Namespaces and Names¶

• 1 - Allowed with an exact match¶

• 2 - Allowed with a prefix match¶

For permissions options 1 & 2, we also need to specify the prefix as a byte string.¶

• Prefix - byte string¶

Specifying a permission type of 2 or 3 and then not supplying a byte string, or supplying a 0 length byte string is equivalent to Blocking that action.¶

As an alternative to carrying two attributes values for each action, we could code these into a single number to save wire size.¶

Permits
* example.com/bob

Prohibits
* example.com
* example.com/bob/123
* example.com/alice
* example.com/bob/logs
* alternate/example.com/bob
* 12345

Permits
* example.com/bob
* example.com/bob/123
* example.com/bob/logs

Prohibits
* example.com
* example.com/alice
* alternate/example.com/bob
* 12345

3.1. Appending a token as a query parameter

The query parameter name SHOULD be "CAT" (case-sensitive) and the query parameter value SHOULD be the Base64 encoded [BASE64] token. If more than one token is transferred, then the sequential query parameter names "CAT1", "CAT2" .. "CATN" SHOULD be used.¶

3.2. Embedding a token in a PATH

The token SHOULD span only a single PATH component and the component SHOULD be prefixed with the string "CAT-". If more than one token is transferred, then they SHOULD occupy different components and SHOULD carry sequential prefixes of "CAT1", "CAT2" .. "CATN".¶

3.3. Usage with WebTransport

With a WebTransport connection, the token can be transferred as a query parameter or as part of the PATH.¶

Example of a single token in a query arg:¶

• https://example.com/service?CAT=oRkBDqMAoQBlaHR0cHMDoQFoL2NvbnRlbnQIoQBlLm0zdTg=¶

Example of multiple tokens in query args:¶

• https://example.com/service?CAT1=oRkBDqMAoQBlaHR0cHMDoQFoL2NvbnRlbnQIoQBlLm0zdTg= &CAT2=IHNramRoZmtjc2pkaGYgc2pkaCBhaCBzIGFzS0pEIDthbGtqIA==¶

Example of a single token in the PATH¶

• https://example.com/service/CAT-oRkBDqMAoQBlaHR0cHMDoQFoL2NvbnRlbnQIoQBlLm0zdTg=/¶

Example of multiple tokens in the PATH:¶

• https://example.com/service/CAT1-oRkBDqMAoQBlaHR0cHMDoQFoL2NvbnRlbnQIoQBlLm0zdTg=/CAT2-IHN ramRoZmtjc2pkaGYgc2pkaCBhaCBzIGFzS0pEIDthbGtqIA==/¶

3.4. Usage with Native QUIC

With a native QUIC connection, the query components and PATH are transmitted via the "PATH" parameter in the CLIENT_SETUP message.¶

Example of a single token in a query arg:¶

• moqt://203.0.113.0:4443 PATH parameter in the CLIENT_SETUP message = "service?CAT=oRkBDqMAoQBlaHR0cHMDoQFoL2NvbnRlbnQIoQBlLm0zdTg="¶

Example of multiple tokens in query args:¶

• moqt://203.0.113.0:4443 PATH parameter in the CLIENT_SETUP message = "service?CAT1=oRkBDqMAoQBlaHR0cHMDoQFoL2NvbnRlbnQIoQBlLm0zdTg= &CAT2=IHNramRoZmtjc2pkaGYgc2pkaCBhaCBzIGFzS0pEIDthbGtqIA=="¶

Example of a single token in the PATH¶

• moqt://203.0.113.0:4443 PATH parameter in the CLIENT_SETUP message = "service/CAT-oRkBDqMAoQBlaHR0cHMDoQFoL2NvbnRlbnQIoQBlLm0zdTg=/"¶

Example of multiple tokens in the PATH:¶

• moqt://203.0.113.0:4443 PATH parameter in the CLIENT_SETUP message = "service/CAT1-oRkBDqMAoQBlaHR0cHMDoQFoL2NvbnRlbnQIoQBlLm0zdTg=/CAT2-IHN ramRoZmtjc2pkaGYgc2pkaCBhaCBzIGFzS0pEIDthbGtqIA==/"¶