Conversation
wilaw
left a comment
wilaw
left a comment
There was a problem hiding this comment.
Thank you for this PR. It is a much needed addition to the draft.
I think there are several sections where we can simplify both the catalog entries and the workflow. Also can remove a bunch of informative prose from this PR. Plus the workflow needs to be refined and we need to tell the players how to extract tokens from query args, which is likely to be the most common way of supplying tokens to players.
draft-ietf-moq-msf.md
Outdated
| Location: R Required: Optional JSON Type: Array | ||
|
|
||
| An array of strings indicating the authorization mechanisms supported by the | ||
| publisher for accessing tracks in this catalog. Subscribers MUST authenticate | ||
| using one of the advertised schemes before accessing protected tracks. |
There was a problem hiding this comment.
Why is this necessary? The player can inspect the tracks and determine the same information. I think we can do without this redundant information in the root of the catalog.
draft-ietf-moq-msf.md
Outdated
| For CAT authentication (scheme "cat"), the object MAY contain: | ||
|
|
||
| | Field | Type | Description | | ||
| |:===============|:========|:==============================================| | ||
| | actions | Array | Required MOQT action codes (0-8) | | ||
| | revalInterval | Number | Token revalidation interval in seconds | | ||
| | dpopRequired | Boolean | Whether DPoP proof binding is required | |
There was a problem hiding this comment.
The player is not going to construct its own CAT token, therefore I don't think it needs this information. The internals of the CAT token are opaque to the player. It only needs to be told which token to apply to which track, and also whether it needs to apply the CAT token to the relay when establishing the initial connection. The current proposal does not provide this information.
| tokens and present them to relays. Relays use these tokens to authorize whether | ||
| an end subscriber is permitted to receive content and whether an original publisher | ||
| is permitted to send content. |
There was a problem hiding this comment.
The CAT token can also authorize the initial establishment of the MOQT or WebTransport connection.
draft-ietf-moq-msf.md
Outdated
|
|
||
| End subscribers discover authorization requirements by parsing the catalog: | ||
|
|
||
| 1. Check if `authSchemes` is present at the catalog root level |
draft-ietf-moq-msf.md
Outdated
| Original publishers and end subscribers may obtain authorization tokens from | ||
| multiple sources, including the catalog's `authInfo` field or as a parameter | ||
| in the connection URI. These tokens can be presented either in the connection |
There was a problem hiding this comment.
We need to define a standard way for transmitting tokens to the player. It will most likely be via query args in the URL, combined with the variable syntax proposed in the Boulder interim.
https://example.com/moqt#my-protected-stream--catalog&token1=12345&token2=6789
In catalog for a track entry:
"bitrate": 15000000,
"authInfo": {
"cat": %token1%
},
There was a problem hiding this comment.
Agree. I have another PR addressing this and happy to update this section once that PR lands.
| * **Per-operation**: Tokens may be included in individual control messages | ||
| using the AUTHORIZATION TOKEN message parameter. For end subscribers, this | ||
| applies to SUBSCRIBE, SUBSCRIBE_NAMESPACE, FETCH, and REQUEST_UPDATE messages. For original | ||
| publishers, this applies to PUBLISH and PUBLISH_NAMESPACE messages. When a track's catalog entry includes an |
There was a problem hiding this comment.
Is this a normative 'may' ?
I think we can simplify things by saying that any time a token is matched with a track, that it should then be provided for ALL control messages which accept token parameters and are associated with that track.
draft-ietf-moq-msf.md
Outdated
| If a relay requires authorization and no token is provided in SETUP, the | ||
| endpoint MUST provide valid authorization in each individual control message | ||
| that requires it. |
There was a problem hiding this comment.
Even if a token is sent during SETUP, it (or its alias) MUST still be resent in all subsequent messages which require token auth.
draft-ietf-moq-msf.md
Outdated
| When an endpoint includes an AUTHORIZATION TOKEN parameter in an individual | ||
| control message, that token overrides any token previously established in the | ||
| SETUP message for that specific operation. This override mechanism enables | ||
| several use cases: |
There was a problem hiding this comment.
I don't think the MOQT currently works like this. Tokens supplied during setup are not automatically applied to subsequent messages in that session.
draft-ietf-moq-msf.md
Outdated
| * **Scope refinement**: A SETUP token may authorize a broad namespace while | ||
| a per-message token authorizes access to a specific track with elevated | ||
| privileges. | ||
|
|
||
| * **Token refresh**: When a SETUP token approaches expiration, endpoints can | ||
| include fresh tokens in subsequent control messages without re-establishing | ||
| the session. | ||
|
|
||
| * **Mixed authorization**: Different tracks within a session may require | ||
| different authorization schemes or token issuers. | ||
|
|
||
| The following MOQT control messages accept the AUTHORIZATION TOKEN parameter: | ||
|
|
||
| | Message | Direction | Use Case | | ||
| |:===================== |:=================== |:===================================== | | ||
| | SUBSCRIBE | Subscriber to Relay | Authorize track subscription | | ||
| | SUBSCRIBE_NAMESPACE | Subscriber to Relay | Authorize namespace subscription | | ||
| | FETCH | Subscriber to Relay | Authorize object fetch | | ||
| | REQUEST_UPDATE | Subscriber to Relay | Authorize update request | | ||
| | PUBLISH | Publisher to Relay | Authorize content publication | | ||
| | PUBLISH_NAMESPACE | Publisher to Relay | Authorize namespace publication | | ||
|
|
||
| When a control message includes an AUTHORIZATION TOKEN, the relay MUST use | ||
| that token for authorization decisions related to that message, regardless | ||
| of any token provided in the SETUP exchange. The SETUP token remains in | ||
| effect for subsequent operations that do not include their own token. | ||
|
|
||
| The specific token format and placement depends on the authorization scheme: | ||
|
|
||
| * **Privacy Pass**: Tokens are included in MOQT control messages | ||
| (SUBSCRIBE, FETCH, PUBLISH, PUBLISH_NAMESPACE) via the AUTHORIZATION TOKEN | ||
| parameter with auth_scheme 0x01. Connection-level tokens may be included in | ||
| the SETUP message. See {{PrivacyPassAuth}} for details. | ||
|
|
||
| * **CAT**: Tokens are supplied via MOQT's AUTHORIZATION TOKEN parameter. | ||
| When DPoP is required, each operation includes a fresh DPoP proof JWT | ||
| bound to the endpoint's public key. See {{CATAuth}} for details. |
There was a problem hiding this comment.
This whole section is just informative and is repeating information already supplied in MOQT draft, C4M draft and Privacy pass draft. We should remove it from the MSF draft.
draft-ietf-moq-msf.md
Outdated
| ### Relay Authorization Enforcement | ||
|
|
||
| Relays enforce authorization for both content consumption and content publishing. | ||
|
|
||
| For end subscribers requesting content via SUBSCRIBE or FETCH, relays MUST: | ||
|
|
||
| 1. Verify the subscriber has presented valid credentials | ||
| 2. Validate the token cryptographically | ||
| 3. Check that the token scope authorizes the requested operation | ||
| 4. Check that the token scope covers the requested namespace and track | ||
| 5. For CAT with revalidation, enforce the moqt-reval interval | ||
| 6. Reject requests that fail any validation step | ||
|
|
||
| For original publishers sending content via PUBLISH or PUBLISH_NAMESPACE, relays MUST: | ||
|
|
||
| 1. Verify the publisher has presented valid credentials | ||
| 2. Validate the token cryptographically | ||
| 3. Check that the token scope authorizes publishing to the namespace or track | ||
| 4. Reject announcements or publications that fail any validation step | ||
|
|
||
| Relays SHOULD return an appropriate error if authorization fails. |
There was a problem hiding this comment.
Again, this is repeating info that is supplied in the MOQT, C4M and PP specs. We should nto include it here.
What we should include are some instructions for a MSF player on what to do when a token is rejected by the relay and an authentication error is returned.
3 participants
Fixes #119