]> Akamai

wilaw@akamai.com

Comcast

Chris_Lemmons@comcast.com

Synamedia

gsimon@synamedia.com

Cisco

snandaku@cisco.com

Media Over QUIC media over quic authorization common access token CAT A token-based authorization scheme for use with Media Over QUIC Transport. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Media Over QUIC mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This draft introduces a token-based authorization scheme for use with MOQT . The scheme protects access to the relay during session establishment and also contrains the actions which the client may take once connected. This draft defines version 1 of this specification.

Overview of the authorization 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 edge relay is part of a trusted MOQT distribution network. It has previously shared secrets with the distribution service, so that this relay is entitled to decrypt related tokens and to validate signatures.
• 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. Based upon claims conveyed in the token, the relay accepts or rejects the connection.
• If the relay accepts the connection, then the client will take a series of MOQT actions: PUBLISH_NAMESPACE, SUBSCRIBE_NAMESPACE, 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 authorize its actions.

| | | (offline/pre-setup) | | | | | 1. Login/Authenticate | | |<----------------------->| | | | | | 2. Generate C4M Token | | | + Relay URL | | |<------------------------| | | | | | 3. Connect to Relay with Token | |-------------------------------------------------->| | | | | | 4. Validate Token | | |<----------------------->| | | (previously shared | | | secrets) | | | | | 5. Accept/Reject Connection | |<--------------------------------------------------| | | | | 6. MOQT Actions with Token Authorization | |<------------------------------------------------->| | (PUBLISH_NAMESPACE, SUBSCRIBE, PUBLISH, FETCH)| | | | | | 7. Revalidate Token | | |<----------------------->| | | (if moqt-reval set, | | | repeats at interval | | | e.g., every 5 min) | ]]>

Token format This draft uses a single token format, namely the Common Access Token (CAT) . The token is supplied as a byte array. When it must be cast to a string for inclusion in a URL, it is Base64 encoded . To provide control over the MOQT actions, this draft defines a new CBOR Web Token (CWT) Claim called "moqt". Use of the moqt claim is optional for clients. Support for processing the moqt claim is mandatory for relays. The default for all actions is "Blocked" and this does not need to be communicated in the token. As soon as a token is provided, all actions are explicitly blocked unless explicitly enabled.

moqt claim The "moqt" claim is defined by the following CDDL: moqt-value) moqt-label = TBD_MOQT moqt-value = [ + moqt-scope ] moqt-scope = [ moqt-actions, ? [ + moqt-ns-match ], ? moqt-track-match ] moqt-actions = [ + moqt-action ] moqt-action = int moqt-ns-match = bin-match / nil moqt-track-match = bin-match bin-match = bstr / [ match-type, match-value ] match-type = prefix-match / suffix-match match-value = bstr prefix-match = 1 suffix-match = 2 ]]> The "moqt" claim bounds the scope of MOQT actions for which the token can provide access. It is an array of action scopes. Each scope is an array with three elements: an array of integers that identifies the actions, an array of match objects for the namespace, and a match object for the track name. The actions are integers defined as follows:

Action	Key	Reference
CLIENT_SETUP	0	Section 9.3
SERVER_SETUP	1	Section 9.3
PUBLISH_NAMESPACE	2	Section 9.20
SUBSCRIBE_NAMESPACE	3	Section 9.25
SUBSCRIBE	4	Section 9.9
REQUEST_UPDATE	5	Section 9.11
PUBLISH	6	Section 9.13
FETCH	7	Section 9.16
TRACK_STATUS	8	Section 9.19

The scope of the moqt claim is limited to the actions provided in the array. Any action not present in the array is not authorized by moqt claim. When a match object is a byte string, it is an exact match. When a match object is an array, the first element is the match type and the second is the match value. Matches are performed bytewise against the corresponding field of the Full Track Name (as defined in Section 2.4.1 of ). The first namespace match object is applied to the first field in the Track Namespace, and so on. The match for the track name is matched against the Track Name. Exact matches must match exactly, prefix matches must match the beginning of the byte string, and suffix matches must match the end of the byte string. The track namespace match and track name match are optional. If the length of the scope array is two, then no track name match is performed at all and the scope of the token includes all track names. If the length is one, the scope includes all namespaces as well as no matching is performed. The list of actions is mandatory. A nil match object is special: it only matches the end of the list of namespaces. This allows the scope to be limited to a precise namespace length. If the list of namespace match objects does not end with a nil match object, then the scope includes all longer namespaces that start with fields that match. Note that nil MUST only appear as the last element in the namespace match array; placing nil elsewhere is invalid. No normalization is applied to the values against which to match; it is performed bytewise.

Text examples of permissions to help with CDDL construction

Notation Used in Examples Full Track Names in this draft are represented using Extended Diagnostic Notation (EDN) as defined in as an array with two elements: an array of namespace fields and a track name. Example: Allow with an exact match [['example','com'],'/bob'] Example: Allow with a prefix match [['example','com'],'/bob'] Example: Allow namespaces starting with ['example','com'] (any length) with exact track name '/bob' Example: Allow namespaces starting with ['example','com'] with any track name Example: Allow with a prefix match on an individual namespace element This example shows how to use a prefix match within a specific namespace field. The second namespace element must start with 'user-'. Example: Allow with a suffix match on track name This example demonstrates suffix matching, which matches the end of a byte string.

Multiple actions Multiple actions may be communicated within the same token, with different permissions. This can be facilitated by the logical claims defined in or simply by defining multiple limits, depending on the required restrictions. In both cases, the order in which limits are declared and evaluated is unimportant. The evaluation stops after the first acceptable result is discovered.

Example of evaluating multiple actions in the same token:

• (1) PUBLISH (Allow with a prefix match on track name) [['example','com'], '/bob*']
• (2) PUBLISH (Allow with an exact match) [['example','com'], '/logs/12345/bob']

Evaluating [['example','com'],'/bob/123'] would succeed on test 1 and test 2 would never be evaluated. Evaluating [['example','com'],'/logs/12345/bob'] would fail on test 1 but then succeed on test 2. Evaluating [['example','com'],''] would fail on test 1 and on test 2. In addition, the entire token expires at 2025-05-02T21:57:24+00:00.

Example of evaluating multiple actions with related claims: If there are other claims that depend on which MOQT limit applies, a logical claim is required: This provides access to the same tracks as the previous example, but in this case, the token is valid for publishing logs up to 10 minutes after the time at which the publishing of the bob track expires.

moqt-reval claim The "moqt-reval" claim is defined by the following CDDL: moqt-reval-value) moqt-reval-label = TBD_MOQT_REVAL moqt-reval-value = number ]]> The "moqt-reval" claim indicates that the token must be revalidated for ongoing streams. If the token is no longer acceptable, the actions authorized by it MUST NOT be permitted to continue. The "moqt-reval-value" is a revalidation interval, expressed in seconds. It provides an upper bound on how long a token may be considered acceptable for an ongoing stream. A revalidator MAY revalidate sooner. If the revalidation interval is smaller than the recipient is prepared or able to revalidate, the recipient MUST reject the token. If a recipient is unable to revalidate tokens, it MUST reject all tokens with a "moqt-reval" claim. A token can be revalidated by simply validating it again, just as if it were new. However, since some claims, signatures, MACs, and other attributes that could contribute to unacceptability may be incapable of changing acceptability in the duration, a revalidator may optimize by skipping some of the checks as long as the outcome of the validation is the same. Revalidators SHOULD skip reverifying MACs and signatures when the list of acceptable issuer keys is unchanged. When the value of this claim is zero, the token MUST NOT be revalidated. This is the default behaviour when the claim is not present. This claim MUST NOT be used outside of a base claimset. If used within a composition claims, the token is not well-formed. The claim key for this claim is TBD_MOQT_REVAL and the claim value is a number. Recipients MUST support this claim. This claim is OPTIONAL for issuers.

DPoP Integration with CAT for MOQT This section defines the use of CAT's Demonstrating Proof of Possession (DPoP) claims to enhance security in MOQT environments. This approach leverages the CAT token's "cnf" (confirmation) claim with JWK Thumbprint binding and the "catdpop" (CAT DPoP Settings) claim to provide proof-of-possession capabilities that prevent token theft and replay attacks in MOQT systems.

CAT DPoP Claims for MOQT This proposal extends the CAT authorization model by binding tokens to client cryptographic key pairs. To enable sender-constrained token usage, the CAT tokens include DPoP-related claims as defined Section 4.8, ensuring that only the legitimate token holder can use the token for MOQT operations.

Confirmation (cnf) Claim with JWK Thumbprint DPoP binding is accomplished by providing the "cnf" claim with the "jkt" (JWK Thumbprint) confirmation method. Below is an example showing jkt token binding. Implementation Requirements:

• Relay Validation: MOQT relays MUST verify that DPoP proofs are signed with the private key corresponding to the "jkt" value
• Proof Binding: Relays MUST reject requests where DPoP proof validation or key binding fails
• Processing Semantics: Relays MUST process DPoP proofs as Protected Resource Access requests per Section 7

DPoP Extension with Application-Agnostic Proof Framework This section defines the use of DPoP with an application-agnostic proof framework as specified in , which extends the traditional HTTP-centric DPoP model to support arbitrary protocols including MOQT. This approach replaces HTTP-specific claims with a flexible authorization context structure that can accommodate protocol-specific command representations. The DPoP proof JWT follows the structure defined in Section 4 of with the following required claims: JWT Header:

• "typ": "dpop-proof+jwt"
• "alg": Asymmetric signature algorithm identifier
• "jwk": Public key for verification

JWT Payload:

• "jti": Unique identifier for the JWT
• "iat": Issued-at time
• "actx": Authorization Context object

For MOQT operations, the Authorization Context ("actx") object contains:

• "type": "moqt" (registered identifier for MOQT protocol)
• "action": MOQT action identifier
• "tns": Track namespace (required)
• "tn": Track name (required)
• "resource": MOQT resource identifier (optional)

When the optional "resource" parameter is included, it MUST be consistent with the "tns" and "tn" parameters. The resource URI should follow the format moqt://<relay-endpoint>?tns=<namespace>&tn=<track> where the tns and tn query parameters match the respective "tns" and "tn" fields in the Authorization Context. Example DPoP proof for MOQT PUBLISH_NAMESPACE operation: MOQT action mapping for Authorization Context:

MOQT Action	actx.action
CLIENT_SETUP	SETUP
SERVER_SETUP	SETUP
PUBLISH_NAMESPACE	PUB_NS
SUBSCRIBE_NAMESPACE	SUB_NS
SUBSCRIBE	SUBSCRIBE
REQUEST_UPDATE	REQ_UPDATE
PUBLISH	PUBLISH
FETCH	FETCH
TRACK_STATUS	TRK_STATUS

Relays supporting this application-agnostic DPoP framework MUST:

• Validate DPoP proofs according to
• Verify that the "actx.type" is "moqt" for MOQT operations
• Validate that the "actx.action" matches the requested MOQT action
• Verify that the "actx.tns" corresponds to the target track namespace
• Verify that the "actx.tn" corresponds to the target track name
• If present, verify the "actx.resource" is consistent with "tns" and "tn"
• Reject requests where Authorization Context validation fails

MOQT Resource URI Construction The Authorization Context "resource" field should specify track namespace (tns) and track name (tn) parameters for MOQT resources:

• Connection setup: moqt://<relay-endpoint>
• Namespace operations: moqt://<relay-endpoint>?tns=<namespace>
• Track operations: moqt://<relay-endpoint>?tns=<namespace>&tn=<track>

DPoP Proof Process and Token Binding Flow The following process illustrates how DPoP proof provision results in CAT token binding and subsequent MOQT relay validation:

Phase 1: Token Acquisition with DPoP Binding Steps 1-5 Detail:

1. Client Key Generation: The MOQT client generates an asymmetric key pair (typically EC P-256) for DPoP operations
2. Authentication with Public Key: Client authenticates with the authorization server, providing user credentials and the public key
3. User Authentication: Authorization server validates user identity and permissions
4. CAT Token Generation: Server creates a CAT token containing:
   • "cnf" claim: JWK Thumbprint ("jkt") of the client's public key (32-byte SHA-256 hash)
   • "catdpop" claim: DPoP processing settings (window, jti handling, critical settings)
   • "moqt" claim: Authorized MOQT actions and scope restrictions
5. Token Delivery: Server provides the bound CAT token and relay endpoint information to the client

Phase 2: MOQT Operations with DPoP Proof Validation Steps 6-11 Detail:

1. DPoP Proof Creation: For each MOQT action, the client creates a fresh DPoP proof JWT with:
   • Header: typ: "dpop-proof+jwt", alg, jwk (public key)
   • Claims: jti (unique ID), iat (timestamp), actx (Authorization Context with type, action, tns, tn)
2. MOQT Request: Client sends MOQT action with both CAT token and fresh DPoP proof
3. CAT Token Validation: Relay validates:
   • Token signature using shared secret with authorization server
   • Token expiration time
   • "moqt" claim scope for requested action
4. DPoP Proof Validation: Relay performs:
   • Extract "jkt" (JWK Thumbprint) from CAT token's "cnf" claim
   • Verify DPoP JWT signature using embedded public key
   • Confirm that SHA-256 hash of DPoP public key matches "jkt" value
   • Check proof freshness within "catdpop" window settings
   • Process replay protection based on "jti" settings
   • Validate Authorization Context ("actx") according to
   • Verify "actx.type" is "moqt"
   • Validate "actx.action" matches the requested MOQT action
   • Verify "actx.tns" and "actx.tn" correspond to target resources
5. Action Authorization: Relay validates the specific MOQT action against token scope and namespace/track permissions
6. Response: Relay responds with success or appropriate error information

Adding a token to a URL Any time an application wishes to add a CAT token to a URL or path element, the token SHOULD first be Base64 encoded . The syntax and method of modifying the URL is left to the application to define and is not constrained by this specification.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Security Considerations

Authentication vs Authorization This specification defines an authorization scheme, not an authentication scheme. User authentication (verifying the identity of a user via credentials, OAuth, 2FA, etc.) occurs prior to token issuance and is outside the scope of this document. The tokens defined in this specification convey authorization - they grant permissions for specific MOQT actions (such as SUBSCRIBE, PUBLISH, ANNOUNCE) on specific namespaces and tracks. A valid token does not authenticate a user; rather, it authorizes the bearer to perform the actions specified in the token's claims. Implementers should ensure that user authentication is performed by appropriate mechanisms before tokens are issued. The security of the authorization scheme depends on the security of the token issuance process, including proper user authentication. TODO Add security considerations for DPoP Claims

IANA Considerations IANA will register the following claims in the "CBOR Web Token (CWT) Claims" registry:

	moqt	moqt-reval
Claim Name	moqt	moqt-reval
Claim Description	MOQT Action	MOQT revalidation
JWT Claim Name	N/A	N/A
Claim Key	TBD_MOQT (1+2)	TBD_MOQT (1+2)
Claim Value Type	array	number
Change Controller	IESG	IESG
Specification Document	RFCXXXX	RFCXXXX

[RFC Editor: Please replace RFCXXXX with the published RFC number for this document.]

MOQT Auth Token Type Registry This document registers the following entry in the "MOQT Auth Token Type" registry established by :

Token Type	Token Name	Specification
0x01	CAT	RFCXXXX

CAT Token Type (0x01) When the Auth Token Type is set to 0x01, the Token Payload field contains a Common Access Token (CAT) serialized as a CBOR-encoded CWT (CBOR Web Token). The token MUST be processed according to the validation rules defined in this specification. Relays receiving a token with this type MUST:

• Validate the token signature or MAC
• Verify token expiration and other standard CWT claims
• Process the "moqt" claim (if present) to authorize MOQT actions
• Process the "moqt-reval" claim (if present) for revalidation requirements
• Process DPoP claims (if present) according to Section 3 of this document

If the token fails validation, the relay MUST reject the connection or action with an appropriate error.

Normative References Comcast Composition claims are claims for CBOR Web Tokens (CWTs) and JSON Web Tokens (JWTs) that define logical relationships between sets of claims. Cisco Google Google Meta This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. Universität Bremen TZI This document formalizes and consolidates the definition of the Concise Diagnostic Notation (CDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing CDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies registry-based extension points and uses them to support text representations such as of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) -26 is intended to // address the May/June 2026 Working Group Last Call comments on -25 // and the ensuing WG discussions. Specifically, this update: • is // going further with the idea to entirely replace the non- backwards // compatible update considered for the RFC 8610/G.4 concatenation by // two new application extensions (temporarily named b1/t1), and to // add related application-oriented extensions that deprecate the // original streamstring syntax. • includes the float'' application- // extension so that the entire CBOR format can be covered. • now // uses rules closer to those of markdown for handling data // transparency in raw strings, simplifying their implementation. • // adds security considerations. • proactively reserves the // application-extension identifier "pragma" for potential future // standardization. • This update does not address certain comments // that propose some editorial restructuring requiring moving text // around; this is best done in a next revision after the technical // comments are addressed. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Appendix A: Test Vectors This appendix provides test vectors in JSON format for cross-implementation validation of CAT tokens for MOQT. Token strings use the base64url encoding defined in with the three-part structure: header.payload.signature.

Keys The following keys are used throughout these test vectors:

CBOR Encoding of Claims These vectors validate correct CBOR encoding of individual claim types.

Token Structure These vectors validate the full token structure (header.payload.signature) with cryptographic verification.

DPoP Binding These vectors validate DPoP (Demonstrating Proof-of-Possession) key binding in CAT tokens.

MOQT Authorization Scopes These vectors validate MOQT scope encoding and authorization matching. Each vector includes authorization tests that specify expected pass/fail results for various action, namespace, and track combinations.

Token Validation These vectors validate token processing: expected pass and fail scenarios. All tokens use HMAC-SHA256 with the key specified in the Keys section unless otherwise noted.

Acknowledgments The IETF moq workgroup