]> Comcast

Chris_Lemmons@comcast.com

Synamedia

gsimon@synamedia.com

Cisco

snandaku@cisco.com

Akamai

wilaw@akamai.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 | |<------------------------------------------------->| | (SETUP, PUBLISH_NAMESPACE, SUBSCRIBE, | | SUBSCRIBE_NAMESPACE, PUBLISH, FETCH, | | REQUEST_UPDATE) | | | | | | 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-scopes-key => moqt-scopes, * int => any } moqt-scopes-key = 0 moqt-scopes = [ + 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. The claim value is a CBOR map. Key 0 holds the scopes array. Each scope is itself an array of one to three elements: the actions (an array of integers), the namespace matches (an array of match objects), and the track match (a single match object). The actions are integers defined as follows:

Action	Key	Reference
SETUP	1	Section 9.1
PUBLISH_NAMESPACE	2	Section 9.14
SUBSCRIBE_NAMESPACE	3	Section 9.15
SUBSCRIBE	4	Section 9.6
REQUEST_UPDATE	5	Section 9.5
PUBLISH	6	Section 9.8
FETCH	7	Section 9.11
TRACK_STATUS	8	Section 9.13
SUBSCRIBE_TRACKS	9	Section 9.18

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.

Extensibility Map keys other than 0 are reserved for future revisions of this specification. A recipient that finds a key it does not recognize in the "moqt" claim map MUST treat the claim set containing that claim as not acceptable. When that claim set is the token's top-level claim set, the token is rejected. This fail-closed behavior ensures that new keys which restrict authorization scope cannot be silently skipped. Issuers that need to offer alternative scope formats can place each in a separate claim set within an "or" claim , so recipients that do not understand one format can still accept another.

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.

Replay Protection without DPoP In MOQT, the same token MAY be presented for SETUP and again for subsequent actions (SUBSCRIBE, PUBLISH, FETCH, etc.) on the same connection. defines "catreplay" value 1 as single use, which would cause these subsequent actions to fail. For MOQT, this specification therefore interprets "catreplay" value 1 as single connection: the token may be used for any number of actions, but only on one connection. When "catreplay" is 1, a relay binds the token's "cti" to the QUIC or WebTransport connection on which the token is first accepted. The relay MUST NOT reject the token solely because it was previously accepted on that connection. All other validation and authorization requirements continue to apply. The relay MUST reject the token on any other connection. A token with "catreplay" 1 that lacks a "cti" or an "exp" claim MUST be rejected. After the connection terminates, the relay MUST retain sufficient replay state to prevent reuse for as long as the token could otherwise be accepted, including any permitted expiration-time leeway. When "catreplay" is 2, replay semantics are implementation-defined. When "catreplay" is absent or 0, no replay protection is applied.

DPoP for MOQT Demonstrating Proof of Possession (DPoP) binds a token to a client key pair, so that a stolen token cannot be used without the corresponding private key. This section defines how DPoP is used with CAT tokens in MOQT. has two parts. The first (Sections 4, 5, 6 and 8 of ) covers how a client obtains a DPoP-bound token from an authorization server; it is used unchanged. The second (Sections 7 and 9 of ) covers how the client proves possession of the key when it uses the token. That part is HTTP-specific: the proof is a JWT that identifies the request by HTTP method and URI ("htm" and "htu"). For MOQT, this section replaces it with a CWT proof whose "actx" claim identifies the MOQT action, Track Namespace and Track Name, using the same encoding as the "moqt" claim.

Token Binding The authorization server binds the CAT token to the client's public key with the "cnf" claim . Because the DPoP proof carries the key as a COSE_Key, the "cnf" claim SHOULD use the "ckt" confirmation method (key 5), the COSE Key Thumbprint of the client's public key. Relays MUST support "ckt". For compatibility with existing CAT issuers, the "cnf" claim MAY instead use the "jkt" confirmation method of , the JWK SHA-256 Thumbprint ; relays SHOULD support "jkt". The "catdpop" claim ( Section 4.8) sets the window within which a proof is fresh and whether relays use the proof's "cti" for replay detection. A relay MUST NOT accept a token that contains a "cnf" claim for an MOQT action unless the action is accompanied by a valid DPoP proof.

DPoP Proof For each MOQT action, the client creates a new DPoP proof: a COSE_Sign1 signed with the private key bound to the token. The protected header contains:

• "alg" (label 1): an asymmetric signature algorithm. Symmetric algorithms MUST NOT be used. Relays MUST support ES256 (-7) and SHOULD support ES384 (-35) and EdDSA (-8) .
• "typ" (label 16): "dpop-proof+cwt".
• "kccs" (label 14) : a CWT Claims Set whose "cnf" claim carries the client's public key as a COSE_Key.

The payload is a CWT Claims Set : bstr, ; cti: unique proof identifier 6 => int, ; iat: creation time actx-label => moqt-actx, ; actx: the MOQT action being authorized ath-label => bstr, ; ath: SHA-256 hash of the CAT token } moqt-actx = { 0 => "moqt", ; type 1 => moqt-action, ; action ? 2 => [ * bstr ], ; Track Namespace fields ? 3 => bstr, ; Track Name } actx-label = TBD_ACTX ath-label = TBD_ATH ]]> The action in "actx" uses the action codes defined for the "moqt" claim. The Track Namespace (key 2) is present for actions that target a namespace or track, and the Track Name (key 3) for actions that target a track. Both carry the exact bytes from the MOQT message, with no serialization or normalization. The "type" value "moqt" prevents a proof created for MOQT from being accepted by another protocol that uses the "actx" claim. The "ath" claim is the SHA-256 hash of the CAT token bytes exactly as presented to the relay. It binds the proof to one token.

Example A CAT token that allows SUBSCRIBE and FETCH on namespace ("cdn", "example.com") for tracks starting with "/sports/", bound to the client's key: The DPoP proof the client sends with a SUBSCRIBE to track "/sports/live" in that namespace: The "ckt" value in the token is the COSE Key Thumbprint of the key in the proof's header (the ES256 test key from Appendix A).

Relay Validation A relay that receives an MOQT action with a DPoP-bound CAT token MUST reject the action unless all of the following hold:

1. The CAT token is valid according to this document.
2. A DPoP proof accompanies the action, and is a COSE_Sign1 whose "typ" is "dpop-proof+cwt" and whose "alg" is a supported asymmetric algorithm.
3. The proof's signature verifies with the COSE_Key in its "kccs" header parameter.
4. The key matches the token's "cnf" claim: for "ckt", its COSE Key Thumbprint equals the "ckt" value; for "jkt", the JWK SHA-256 Thumbprint of the equivalent JWK (for an EC2 key: "crv", "kty", "x" and "y") equals the "jkt" value.
5. "ath" equals the SHA-256 hash of the token as presented.
6. "iat" is within the window set by the "catdpop" claim.
7. If the "catdpop" claim requests replay detection, the relay has not accepted another proof with the same "cti" within that window.
8. In "actx", "type" is "moqt", the action equals the requested action, and the Track Namespace and Track Name equal those in the MOQT message.

The relay then authorizes the action against the token's "moqt" claim as for any other token.

DPoP Security Considerations The security considerations of apply. In addition:

• A proof authorizes exactly one MOQT action. Because "actx" carries the full action, namespace and track, a captured proof cannot be used for a different action or track, and the "iat" window and "cti" replay detection limit its reuse for the same one.
• DPoP relies on the QUIC or WebTransport connection for integrity and confidentiality; it does not protect the MOQT messages themselves.
• Clients SHOULD NOT use the same key pair across unrelated deployments.
• Each proof adds to the size of the message that carries it. Implementations need to keep the token and proof within the size limits of that message.

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. DPoP security considerations are covered in the "DPoP for MOQT" section.

Replay Protection for Bearer Tokens Without DPoP, connection-scoped replay protection limits but does not eliminate token theft risk; an attacker who intercepts the token before the client connects can still use it. Deployments that need stronger guarantees SHOULD use DPoP. The binding of a token to a connection is state held by the relay that accepted it. In deployments with multiple relays, such as a CDN or relay cluster, the same token can be replayed against another relay unless the relays share this state. Such deployments SHOULD share "cti" bindings among relays that accept the same tokens, or use DPoP.

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

Claim Name	Key	Description	Value Type	JWT	Ref
moqt	TBD_MOQT (1+2)	MOQT Action Scope	map	N/A	RFCXXXX
moqt-reval	TBD_MOQT (1+2)	MOQT Revalidation	number	N/A	RFCXXXX

[RFC Editor: Please replace RFCXXXX with the published RFC number for this document.] IANA will also register the following claims, used in DPoP proofs, in the "CBOR Web Token (CWT) Claims" registry. The "ath" claim corresponds to the JWT claim of the same name defined in .

Claim Name	Key	Description	Value Type	JWT	Ref
actx	TBD_ACTX	Authorization Context	map	N/A	RFCXXXX
ath	TBD_ATH	Access Token Hash	bstr	ath	RFCXXXX

Media Type Registration IANA will register the following media type in the "Media Types" registry, for use as the "typ" of DPoP proofs:

• Type name: application
• Subtype name: dpop-proof+cwt
• Required parameters: N/A
• Optional parameters: N/A
• Encoding considerations: binary (CBOR)
• Security considerations: see the "DPoP for MOQT" section of RFCXXXX
• Interoperability considerations: N/A
• Published specification: RFCXXXX
• Applications that use this media type: MOQT clients and relays that use DPoP-bound CAT tokens
• Fragment identifier considerations: N/A
• Additional information: N/A
• Person and email address to contact for further information: Media Over QUIC Working Group, moq@ietf.org
• Intended usage: COMMON
• Restrictions on usage: N/A
• Author: Media Over QUIC Working Group
• Change controller: IETF

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	This document

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 the "DPoP for MOQT" section

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

Normative References Comcast Composite claims are claims for CBOR Web Tokens (CWTs) and JSON Web Tokens (JWTs) that define logical relationships between sets of claims. This document also defines a CWT representation of the "crit" (Critical) claim. 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:) This revision -29 // attempts to implement various change requests not covered in -28 // that have been discussed in the 2026-08-19 and 2026-09-30 WG // interim meetings, but does not attempt to reflect the outcome of // those discussions. The text also does not have WG input yet on // any renaming decisions (CDN name, b1/t1 name). 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. This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). This specification defines a method for computing a hash value over a CBOR Object Signing and Encryption (COSE) Key. It specifies which fields within the COSE Key structure are included in the cryptographic hash computation, the process for creating a canonical representation of these fields, and how to hash the resulting byte sequence. The resulting hash value, referred to as a "thumbprint", can be used to identify or select the corresponding key. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. 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. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.

Appendix A: Test Vectors This appendix provides test vectors in JSON format for cross-implementation validation of CAT tokens for MOQT. Tokens use COSE_Mac0 (CBOR tag 17) for HMAC-SHA256 or COSE_Sign1 (CBOR tag 18) for ES256. Token strings are the base64url encoding of the full COSE structure. The JSON is only a container for the vectors; it does not define a JSON representation of CAT claims. The "payload_cbor_hex" value is the normative claim set. The "claims_edn" value shows the same claim set in CBOR Extended Diagnostic Notation , with claim names as comments. Long string values are folded across lines to fit this document. The line breaks and the indentation that follows them are not part of the JSON string. To unfold a hex or base64url value, remove each line break and the indentation after it. In "description" and "claims_edn" values, replace each line break and its indentation with a single space. The moqt and moqt-reval claims do not yet have assigned claim keys (TBD_MOQT and TBD_MOQT_REVAL). These vectors use the Private Use claim keys -65537 for moqt and -65538 for moqt-reval as placeholders.

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 COSE_Mac0 (tag 17) and COSE_Sign1 (tag 18) token structure with cryptographic verification. Each vector includes the COSE binary encoding (cose_hex) and its base64url representation (cose_b64).

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.

Composite Claims These vectors validate composite claim encoding per . Each vector includes an outer token (iss, exp) with embedded composite claims. Tokens use COSE_Mac0 with HMAC-SHA256. The or, nor and and claims do not yet have assigned claim keys. Until they are allocated, these vectors encode every composite claim key as 0. 0 is not a valid claim key, so a verifier fails to parse these claims. The "claims_edn" value and the "operator" field identify which composite claim each 0 key stands for.

Token Validation These vectors validate token processing: expected pass and fail scenarios. All tokens use HMAC-SHA256 (algorithm_id 5) with the key specified in the Keys section unless otherwise noted. Token values are the base64url encoding of the full COSE_Mac0 structure.

Acknowledgments The IETF moq workgroup