]> Cisco

fluffy@iii.ca

Cisco

snandaku@cisco.com

Applications and Real-Time Media Over QUIC MoQ MOQT MOCHA Identity Authorization Federation Privacy Pass C4M DPoP This document specifies identity, authentication, authorization, and federation for MOCHA (MoQ Open Communication & Hosting Architecture). It defines how users authenticate with Identity Providers (IdPs), how authorization tokens (C4M and Privacy Pass) are issued and validated at relays, how permissions map to MOQT namespaces, and how users from one Provider obtain access to resources on a federated Provider. About This Document Status information for this document may be found at . Discussion of this document takes place on the Media Over QUIC Working Group mailing list (), which is archived at . Subscribe at .

Introduction MOCHA requires participants to prove their identity and obtain authorization before publishing or subscribing to tracks on MOQT relays. This document specifies the identity and authorization architecture, covering:

• Identity Provider (IdP) authentication (OIDC, guest, future methods)
• Token issuance via C4M for identified access with DPoP binding
• Role-to-scope mapping for the MOCHA namespace hierarchy
• Federated identity exchange across Providers
• Token refresh and revocation

Conventions and Definitions See BCP 14 . This document uses terminology defined in , including Provider, Organization, Team, Channel, Device, and DevID. The following identifiers are defined in this document:

HClientID:

A hashed client identifier derived via HMAC. Used in namespace tuples and track names instead of the raw clientID. See .

HDevID:

A hashed device identifier derived via HMAC. Used in track names instead of the raw devID. See .

The following additional terms are used:

Identity Provider (IdP):

A service that authenticates users and asserts their identity. Examples include OIDC-compliant providers, enterprise SSO, and self-hosted identity services. The IdP answers "who is this user?"

Provider Token Service:

The MOCHA component that validates identity assertions from IdPs, determines user permissions, and issues access tokens (C4M) for relay access.

Access Tokens: A C4M (CAT for MOQT) CWT (CBOR Web Token) that encodes a user's identity and MOQT namespace permissions. Defined in . When used in Mocha, the token includes a DPoP confirmation claim (cnf) binding it to the client's key. ID Token: : An OIDC (OpenID Connect) token that provides the authenticated identity of the user.

DPoP (Demonstrating Proof of Possession):

A mechanism that binds a C4M token to the client's asymmetric key pair. The client generates a fresh DPoP proof for each MOQT action, preventing token theft and replay. See .

Authorization Parameter:

The MOQT parameter that carries authentication credentials. It can appear in CLIENT_SETUP, SUBSCRIBE, SUBSCRIBE_NAMESPACE, PUBLISH, PUBLISH_NAMESPACE, and FETCH messages.

Relay:

Validates access tokens and enforces access control for MOQT operations. Relays do not authenticate users directly; they trust tokens signed by known issuers.

Architecture Overview The client does a normal OpenID SSO login flow to authenticate to the Provider Token Service to get an ID Token and an Access Token with DPoP. For each Org at the Provider, the Provider keeps tracks of: * all of the users in the Org * for each users in its Org, all of their devices * all the teams in its Org, * for each team, all of users (in the Org or other Providers/Orgs) and their roles, * for each team, all of its channels, * for each of the channels, its users (in this Org or other Providers/Orgs) and their roles, * for each of the channels, all of the meetings TODO: Add support for federation The Provider Token Service takes an ID Token and generates Access Token(s) with the required scopes for Relays for all the Mocha services. The Provider Token Service coordiates with the CDNs providing the Relays so the relays can validate the Access Tokens. The exact scopes needed for Access Tokens are defined in the specifications that define the Mocha service. Clients use the Access Tokens when sending requests to the Relays. A Client that is acting as User on a different provider can also ask for Access Tokens for this resources in this Provider. This allows federated actions where a Client on Provider A can participated in meetings or channels that are owned by an Org on Provier B.

Identity Architecture | Relay | | (Device) | (C4M + DPoP ) | (Validates) | +----+-----+ +------+------+ | | | (1) authenticate + request token | v | +----+-----------------------------------------+ | | Token Service | | | - Validates IdP assertions | | | - Checks membership/permissions | | | - Mints C4M tokens with DPoP binding | | | - Proxies PP blind token requests | | +----------------------------------------------+ | | (3) SUBSCRIBE / PUBLISH granted | <------------------------------------------+ ]]>

Identity Provider Authentication

Overview Before obtaining authorization tokens, a user must authenticate with an Identity Provider. MOCHA supports pluggable IdPs. The Token Service validates the IdP assertion and establishes a session.

OIDC Authentication

OIDC Authentication Flow | | | | | | (2) ID Token (JWT) | | |<-------------------------| | | | | | (3) POST /auth/oidc | | | Authorization: Bearer | |-------------------------------------------------->| | | | | | (4) Verify signature | | | via JWKS fetch | | |<-----------------------| | |----------------------->| | | | | | (5) Validate claims: | | | iss, aud, exp, | | | email_verified | | | | | (6) 200 OK | | { user_id, session_token } | |<--------------------------------------------------| | | | ]]>

The Token Service MUST validate the ID Token per Section 3.1.3.7 (issuer, audience, expiry, signature via JWKS).

Guest Authentication For deployments allowing pseudonymous access:

Guest Authentication | | | | 200 OK | | { "user_id": "guest-7a3f", | | "session_token": "s_..." } | |<-------------------------------------| | | ]]>

Guest users receive a server-assigned pseudonymous identity. Guest sessions MAY have reduced permissions compared to authenticated users.

C4M Token Issuance and Validation

Overview C4M (CAT for MOQT) is the primary authorization mechanism for identified access. MOCHA deployments MUST use DPoP (Demonstrating Proof of Possession) to bind C4M tokens to the client's key pair, preventing token theft and replay. Token format and CWT claims (Section 2), DPoP claims and proof generation (Section 3.1), and DPoP proof process and token binding flow (Section 3.2) from MUST be used for MOCHA authorization.

Token Request After authentication, the client requests a C4M token scoped to a specific channel and role. The client provides its public key for DPoP binding. The Token Service validates the session, checks membership, determines role permissions, and mints a C4M token with a cnf claim binding it to the client's key. The complete HTTP issuance flow is specified in . The Token Service maps the user's role and channel membership to moq_scopes within the C4M token. The scopes use the MOCHA namespace hierarchy: ////participant/*"], subscribe: ["mocha/////*"] } ]]>

Scope Enforcement Scope enforcement follows the positional namespace matching rules defined in , Section 2.1. The relay evaluates each namespace field against the corresponding match object in the token's moqt claim. Actions not explicitly permitted by the token are denied by default. For example, a MOCHA participant token might encode scopes that permit publishing under their device prefix within a channel, while allowing subscription to all tracks in that channel: /... Token scope (subscribe): mocha/provider.example/acme/eng/general/... PUBLISH request: mocha/provider.example/acme/eng/general/ participant/device-a3f2/messages/live Result: PERMITTED (matches publish scope) SUBSCRIBE request: mocha/provider.example/acme/eng/general/ moderator/device-b1c4/messages/live Result: PERMITTED (matches subscribe scope) ]]>

Privacy Pass Token Issuance and Validation

Overview Privacy Pass provides cryptographic unlinkability: the relay can verify a token was legitimately issued without correlating it to the identity that requested it. This enables anonymous participation in channels. Illustrative call flows are provided in . For scoped access, Partially Blind RSA tokens carry public metadata encoding the permitted MOCHA namespaces without breaking unlinkability. The relay uses these extensions for scope enforcement identical to C4M tokens, but cannot determine which user holds the token.

MOCHA Token Issuance Token types, issuance protocol, attester authentication, and token wire format are defined in . The Token Service acts as Attester (, Section 3) and authenticates to the PP-Issuer using HTTP Message Signatures . In the MOCHA context, the Token Service:

1. Validates the client's session and channel membership (as in the C4M flow).
2. Determines the namespace scope to encode in the token's public metadata (for PBRS tokens).
3. Attests to the PP-Issuer that the client is authorized for the requested scope.

The client presents the resulting token in the AUTHORIZATION parameter of any MOQT control message (CLIENT_SETUP, SUBSCRIBE, PUBLISH, etc.).

Reverse Flow MOCHA deployments MAY use the Privacy Pass reverse flow where the relay acts as both attester and issuer. The client bootstraps with a publicly verifiable token from an external issuer, and the relay responds with privately verifiable tokens for subsequent operations. The reverse flow enables continuous unlinkable authorization without requiring an external issuer after the initial bootstrap. Token replenishment is piggybacked on normal MOQT control message exchanges using batched tokens . The bootstrap, continuous authorization, and batch token encoding are defined in (Sections 4-5) and (Section 4).

Roles and Token Scopes Roles (Owner, Moderator, Participant, Observer) are defined in and assigned at the Organization, Team, and Channel levels. The permissions associated with each role (publish, subscribe, moderation, management) are application policy specified in . This document defines how the Token Service translates a user's role into C4M token scopes. When a user requests a token, the Token Service determines their role for the target channel and encodes the corresponding namespace permissions: The scope patterns follow the MOCHA namespace hierarchy and are enforced by the relay per , Section 2.1. The same scopes apply when using Privacy Pass with PBRS tokens — the namespace permissions are encoded in the token's public metadata extensions (see ) and enforced identically by the relay.

Federation Federation allows a user authenticated with one Provider to participate in Teams and Channels hosted by a different Provider. The home Provider vouches for the user's identity via a signed assertion, and the remote Provider issues a locally-valid C4M token after verifying trust and applying its federation policies.

Federation Model

Federated Providers | Token Service B | | Relay A | Trust | Relay B | | Users: Alice | | Users: Bob | +------------------+ +------------------+ Alice (home: A) wants to join a Channel on Provider B. ]]>

Federation Establishment Providers establish federation trust via mutual discovery and key exchange:

Federation Establishment | | | | (2) { realm, federation_relays, | | signing_key, policies } | |<-----------------------------------------| | | | (3) Verify signing_key via DNSSEC/TLS | | | | (4) Store Provider B's public key | | in trusted federation peers | | | | (5) Provider B does same for A | |<---------------------------------------->| | | ]]>

The well-known document: ", "token_exchange_endpoint": "https://auth.provider-b.example/federation/exchange", "policies": { "allow_inbound": true, "allowed_providers": ["*"], "blocked_providers": [] } } ]]>

Federated Token Exchange When Alice (Provider A) wants to access a Channel on Provider B, a token exchange occurs:

Federated Token Exchange | | | | | | | | | (2) Create signed | | | | federation assertion| | | | (Ed25519): | | | | { sub, home_realm, | | | | target, roles, | | | | exp } | | | | | | | | (3) POST /federation/exchange | | | { assertion, requested_scope } | | |--------------------->| | | | | | | | (4) Verify assertion signature | | | against Provider A's | | | known public key | | | | | | | (5) Check federation policies: | | | - Provider A allowed? | | | - Target channel permits | | | remote users? | | | - Role mapping valid? | | | | | | | (6) Mint C4M token with | | | Provider B's signing key | | | | | | | (7) { token: , expires_at } | | |<--------------------| | | | | | | (8) Federated | | | | C4M token | | | |<---------------| | | | | | | | (9) CLIENT_SETUP { AUTHORIZATION: } | |-------------------------------------------------------->| | | | | | | | (10) Validate | | | | with B's key | | | | | | (11) SERVER_SETUP | |<--------------------------------------------------------| | | | | ]]>

The home Provider creates an Ed25519-signed assertion containing the user's identity (issuer, subject), the target Provider and namespace, the user's home roles, a validity window (issued-at and expiry), and a fresh nonce to prevent replay. The assertion is scoped to the remote Provider via an audience claim. The remote Provider validates the signature against the home Provider's known public key, checks the assertion has not expired, and maps the home roles to local permissions according to its federation policy. The remote Provider MAY downgrade roles (e.g., a home "moderator" becomes a remote "participant").

Token Service The Token Service is the MOCHA component responsible for minting, refreshing, and revoking C4M access tokens. The Token Service interacts with other components via two mechanisms:

HTTP API:

Clients call the Token Service HTTP endpoint to mint initial C4M tokens (before a MOQT session exists). See .

MOQT Tracks:

The Token Service publishes on MOQT tracks that relays and clients subscribe to:

• Per-client refresh track: delivers rotated tokens to each client. See .
• Revocation track: notifies relays and clients of revoked tokens. See .

HTTP Token Issuance Before establishing a MOQT session, a client obtains a C4M token from the Token Service via its HTTP API. The client presents its session credentials (obtained after IdP authentication per ) along with its DPoP public key:

HTTP Token Issuance | | { | | "org_id": "acme", | | "team_id": "engineering", | | "channel_id": "general", | | "role": "participant", | | "dpop_jwk": { }| | } | |-------------------------------------->| | | | (1) Validate session | | (2) Check membership and role | | (3) Mint C4M token with DPoP binding | | | | 200 OK | | { "token": "", | | "expires_at": 1749903600 } | |<--------------------------------------| | | ]]>

The Token Service maps the user's role and channel membership to moq_scopes within the C4M token per .

Token Refresh C4M tokens are intentionally short-lived. To maintain continuous access without requiring the client to re-authenticate via the IdP, MOCHA provides in-session token refresh over MOQT. Once a MOQT session is active, the client subscribes to a per-user token refresh track. The Token Service proactively publishes a new token before the current one expires:

In-Session Token Refresh / | | | tokens/ | | |-------------------->| | | |--------------------->| | | | | | (token nearing | | | expiry) | | | | | | OBJECT: new token | | |<---------------------| | new token | | |<--------------------| | | | | ]]>

The Token Service SHOULD publish the refreshed token at approximately 75% of the current token's lifetime, providing an overlap window where both the old and new tokens are valid.

Token Revocation For immediate access removal (e.g., user banned, role changed, device compromised), the Token Service publishes revocation objects to a dedicated revocation track. Both relays and clients subscribe to this track.

Revocation Track /tokens Track: revocations ]]>

Revocation Object Format Each revocation object carries the SHA-256 hash of the revoked token, enabling relays and clients to identify the specific token without exposing its contents: ", "revoked_at": 1749901500, "reason": "role_change", "affected_scopes": [ "mocha/provider.example/acme/eng/private/*" ] } ]]>

Revocation Fields

token_hash (REQUIRED):

SHA-256 hash of the C4M token being revoked, hex-encoded. Relays and clients match this against hashes of tokens they hold or have validated.

revoked_at (REQUIRED):

Revocation time in seconds since Unix epoch.

reason (OPTIONAL):

Human-readable reason for the revocation (e.g., "role_change", "ban", "device_compromised").

affected_scopes (OPTIONAL):

List of namespace scope patterns affected by this revocation, for informational purposes.

Relay Enforcement Relays MUST subscribe to the revocation track of each Token Service whose tokens they accept. Upon receiving a revocation object, the relay:

1. Computes the SHA-256 hash of each active token it has validated for the affected session(s).
2. If a match is found, immediately terminates any SUBSCRIBE or PUBLISH operations authorized by that token.
3. Caches the token_hash for the remainder of the token's original validity period to reject any late-arriving requests using the revoked token.

Client Behavior Clients SHOULD also subscribe to the revocation track. Upon receiving a revocation matching a token they hold, clients MUST stop using that token and request a new one via HTTP () or await a refresh on their token track.

Token Revocation Flow | | | | | | | (match found: | | | terminate session)| | | | | | OBJECT: revocation| | |------------------>| | | | | | | (stop using | | | revoked token, | | | request new one) | | | ]]>

Identifier Derivation Both the HClientID and HDevID used in namespace tuples and track names are derived using HMAC with a shared secret K between the client and the provider. The clientID is the identifier for the client participant obtained out of band, and "||" denotes concatenation. The shared secret K is established during the authentication flow () and is unique per client-provider pair. The HClientID is computed as: || clientID) ]]> The HDevID is computed as: || devID) ]]> where devID is the device identifier used as the device identity in the MoQ track. The devID MAY be the hash of the client's public key used for DPoP binding (), providing a stable per-device identifier tied to the cryptographic material. These derived identifiers ensure that:

• The actual clientID and devID are not exposed on the wire
• Different namespaces produce different HClientID/HDevID values for the same client, preventing cross-namespace correlation by relays
• Only the client and the provider (who share K) can verify the mapping between the raw identifiers and their hashed forms

Service Discovery TODO

Security Considerations TODO

IANA Considerations This document makes no requests of IANA.

Normative References 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. Akamai Comcast Synamedia Cisco A token-based authorization scheme for use with Media Over QUIC Transport. Cisco Cisco Cloudflare Inc. This document specifies the use of Privacy Pass architecture and issuance protocols for authorization in Media over QUIC (MoQ) transport protocol. It defines how Privacy Pass tokens can be integrated with MoQ's authorization framework to provide privacy- preserving authentication for subscriptions, fetches, publications, and relay operations while supporting fine-grained access control through prefix-based track namespace and track name matching rules. Cloudflare Inc. This document specifies an instantiation of Privacy Pass Architecture [RFC9576] that allows for a "reverse" flow from the Origin to the Client. It describes a method for an Origin to issue a state update to the Client in response to a request in which a token is redeemed. Phoenix R&D Cloudflare Cloudflare Inc. This document specifies two variants of the Privacy Pass issuance protocol that allow for batched issuance of tokens. These allow clients to request more than one token at a time and for issuers to issue more than one token at a time. 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 document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. 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.

Privacy Pass Call Flows This appendix illustrates the Privacy Pass flows for MOCHA. The normative protocol is defined in and .

External Issuer Flow The client authenticates with the IdP, then obtains a Privacy Pass token via the Token Service (Attester) and external PP-Issuer, and finally presents it to the relay.

Privacy Pass External Issuer Flow | | | | | | | | | | (2) ID Token | | | | |<-------------| | | | | | | | | | (3) POST /auth/oidc | | | | { ID Token } | | | |----------------------------->| | | | | | | | | (4) session_token | | | |<-----------------------------| | | | | | | | | (5) POST /auth/privacypass/challenge | | | { room_id, token_type } | | | |----------------------------->| | | | | | | | | | | (6) Fetch issuer | | | | | public key | | | | |----------------->| | | | |<-----------------| | | | | | | | (7) TokenChallenge + | | | | issuer_pub_key | | | |<-----------------------------| | | | | | | | | (8) Generate nonce, | | | | blind token_input | | | | | | | | | (9) POST /auth/privacypass/token-request | | | { blinded_element } | | | |----------------------------->| | | | | | | | | | | (10) Forward | | | | | + HTTP sig | | | | |----------------->| | | | | | | | | | (11) Verify | | | | | attester sig, | | | | | sign token | | | | | | | | | | (12) blind_sig | | | | |<-----------------| | | | | | | | (13) blind_signature | | | |<-----------------------------| | | | | | | | | (14) Unblind, assemble | | | | final token | | | | | | | | | (15) CLIENT_SETUP { AUTHORIZATION: token } | |-------------------------------------------------------------->| | | | | | | | | | (16) Verify | | | | | with issuer | | | | | public key | | | | | | | (17) SERVER_SETUP (identity unknown to relay) | |<--------------------------------------------------------------| | | | | | ]]>

Reverse Flow The reverse flow has three phases: bootstrap, session establishment, and continuous authorization with token replenishment.

Step 1: Bootstrap The client connects without credentials. The relay challenges the client, who obtains a publicly verifiable token from an external issuer.

Reverse Flow Step 1: Bootstrap | | | | | (2) UNAUTHORIZED { TokenChallenge } | |<------------------------------------------------| | | | | (3) Blind token | | | request | | |--------------------->| | | | | | (4) blind_signature | | |<---------------------| | | | | | (5) Unblind, assemble publicly | | verifiable token (type 0x0002) | | | | ]]>

Step 2: Token Exchange The client presents the bootstrap token and requests a batch of privately verifiable tokens from the relay (now acting as issuer).

Reverse Flow Step 2: Token Exchange | | | | (2) Validate bootstrap token | | (3) Issue privately verifiable | | tokens (type 0x0001/0x0005) | | | | (4) SERVER_SETUP { | | GenericBatchTokenResponse | | } | |<----------------------------------------| | | ]]>

Step 3: Continuous Authorization On each subsequent operation, the client presents a privately verifiable token and piggybacks a new batch request. The relay validates and replenishes tokens.

Reverse Flow Step 3: Continuous Authorization | | | | (2) Validate private token | | (3) Issue new batch of tokens | | | | (4) GenericBatchTokenResponse | |<----------------------------------------| | | | (5) PUBLISH { | | AUTHORIZATION: PrivateTokenAuth, | | GenericBatchTokenRequest | | } | |---------------------------------------->| | | | (6) Validate, issue new batch | | | | (7) GenericBatchTokenResponse | |<----------------------------------------| | | | (continues for session lifetime) | | | ]]>