Privacy Pass Authentication for Media over QUIC (MoQ)

Privacy Pass Authentication for Media over QUIC (MoQ) Cisco

snandaku@cisco.com

Cisco

fluffy@iii.ca

Cloudflare Inc.

ot-ietf@thibault.uk

Web and Internet Transport Media Over QUIC media over quic privacy-pass 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. 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 Working Group mailing list (), which is archived at . Subscribe at . Working Group information can be found at . Source for this draft and an issue tracker can be found at .

Introduction Media over QUIC (MoQ) provides a transport protocol for live and on-demand media delivery, real-time communication, and interactive content distribution over QUIC connections. The protocol supports a wide range of applications including video streaming, video conferencing, gaming, interactive broadcasts, and other latency-sensitive use cases. MoQ includes mechanisms for authorization through tokens that can be used to control access to media streams, interactive sessions, and relay operations. Traditional authorization mechanisms often lack the privacy protection needed for modern media distribution scenarios, where users' viewing patterns and content preferences should remain private while still enabling fine-grained access control, namespace restrictions, and operational constraints. Privacy Pass provides a privacy-preserving authorization architecture that enables anonymous authentication through unlinkable tokens. The Privacy Pass architecture consists of four entities: Client, Origin, Issuer, and Attester, which work together to provide token-based authorization without compromising user privacy. The issuance protocols define how these tokens are created and verified. This document defines how Privacy Pass tokens can be integrated with MoQ's authorization framework to provide comprehensive access control for media streaming, real-time communication, and interactive content services while preserving user privacy through unlinkable authentication tokens.

Requirements Language 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.

MoQ Transport Conventions defines a single SETUP message () that each endpoint sends on its control stream. In this document, CLIENT_SETUP denotes the SETUP message sent by the client and SERVER_SETUP denotes the SETUP message sent by the server.

Privacy Pass Architecture for MoQ Privacy Pass Terminology defined in is reused here. The Privacy Pass MoQ integration involves the following entities and their interactions:

Client: The MoQ client requesting authorization to subscribe to, fetch, or publish media content. The client is responsible for obtaining Privacy Pass tokens through the attestation and issuance process, and presenting these tokens when requesting MoQ operations such as SUBSCRIBE, FETCH, PUBLISH, or PUBLISH_NAMESPACE.
MoQ Relay: The MoQ relay server that forwards media content and verifies that clients are authorized. The relay validates Privacy Pass tokens presented by clients, enforces access policies, and forwards authorized requests to other relays. Relays maintain configuration for trusted issuers and validate token signatures and metadata.
Privacy Pass Issuer: The entity that issues Privacy Pass tokens to clients after successful attestation. The issuer operates the token issuance protocol, manages cryptographic keys. The issuer creates tokens with appropriate MoQ-specific metadata.
Privacy Pass Attester: The entity that attests to properties of clients for the purposes of token issuance. The attester verifies client credentials, subscription status, or other eligibility criteria. Common attestation methods include username/password, OAuth, device certificates, or other authentication mechanisms.

Joint Attester and Issuer In the below deployment, the MoQ relay and Privacy Pass issuer are operated by different entities to enhance privacy through separation of concerns. This corresponds to .

Separated Issuer and Relay Architecture | | | | |<== Attestation ==>| | | | | | | +--------- TokenRequest ------->| | |<-------- TokenResponse -------+ |<--- Request+Token ---+ | | | | | | ]]> In certain deployments the MoQ relay and Privacy Pass issuer may be operated by the same entity to simplify key management and policy coordination. This is the Privacy Pass deployment described in .

Shared Origin, Attester, Issuer with a Reverse Flow The flow described above can be used to bootstrap a shared origin-attester-issuer flow, as described in . The MoQ relay plays all roles (origin, attester, and issuer), allowing it to use privately verifiable token types registered in . In this scenario, the MoQ relay origin would accept tokens signed by two issuers:

Type 0x0002 token signed by the bootstrap issuer from
Type 0x0001, 0x0005, or 0xE5AC tokens signed by its own issuer.

This two-phase approach provides several advantages:

Bootstrapping: The initial publicly verifiable token (0x0002) establishes trust without requiring the relay to share private keys with external verifiers.
Efficiency: Subsequent privately verifiable tokens allow batched issuance, amortizing cryptographic costs across multiple operations.
Privacy: Each token presentation is unlinkable, even when obtained from the same credential.

Reverse Flow Overview The reverse flow, as described in , allows a client to exchange a publicly verifiable token for privately verifiable tokens (or credentials) issued directly by the MoQ relay.

Detailed Reverse Flow Steps Phase 1: Bootstrap Token Acquisition

The client initiates a connection with CLIENT_SETUP without authorization.
The MoQ relay responds with a SERVER_SETUP carrying an AUTH CHALLENGE option whose TokenChallenge specifies a publicly verifiable token type (0x0002), then terminates the session with UNAUTHORIZED.
The client performs attestation with an external attester/issuer.
The client obtains a publicly verifiable token.

Phase 2: Token Exchange via Reverse Flow

The client sends CLIENT_SETUP with:
- An AUTHORIZATION TOKEN option carrying the publicly verifiable Token from Phase 1
- An AUTH REQUEST option carrying a CredentialRequest (or GenericBatchTokenRequest) for a privately verifiable token type (0x0001, 0x0005, or 0xE5AC)
The MoQ relay validates the bootstrap token, then processes the credential request using its internal issuer.
The MoQ relay responds with SERVER_SETUP containing:
- An AUTH RESPONSE option carrying the CredentialResponse (or GenericBatchTokenResponse) with the privately verifiable credential/tokens

Phase 3: Normal Operations

For subsequent operations (SUBSCRIBE, PUBLISH, FETCH), the client presents tokens derived from the credential obtained in Phase 2.
The MoQ relay validates tokens locally using its private verification key.

Credential Request/Response Encoding When using the reverse flow, the AUTH REQUEST payload () contains the credential or token request for the privately verifiable token type:

For 0x0001 or 0x0005: GenericBatchTokenRequest as defined in
For 0xE5AC: CredentialRequest as defined in

Similarly, the AUTH RESPONSE payload contains:

For 0x0001 or 0x0005: GenericBatchTokenResponse as defined in
For 0xE5AC: CredentialResponse as defined in

Trust Model The architecture assumes the following trust relationships based on :

Relays trust issuers to properly validate client eligibility before issuing tokens
Issuers trust attesters to accurately verify client eligibility

Privacy Pass Token Integration This section describes how Privacy Pass tokens are integrated into the MoQ transport protocol to provide privacy-preserving authorization for various media operations.

Token Types for MoQ Authorization This specification uses the below existing Privacy Pass token types: Publicly verifiable token types

0x0002 (Blind RSA (2048-bit)): Defined in . Uses blind RSA signatures () for deployments requiring distributed validation across multiple relays.

Privately verifiable token types

0x0001 (VOPRF(P-384, SHA-384)): Defined in . Uses VOPRF () for deployments where the origin is the issuer. Issuance can be batched as defined in .
0x0005 (VOPRF(ristretto255, SHA-512)): Defined in . Uses VOPRF () for deployments where the origin is the issuer. Issuance can be batched as defined in .
0xE5AC (ARC(P-256)): Anonymous Rate Limit Credentials Token using . Tokens are presented by clients based on an issued credential and up to a presentation_limit.

Token Structure Privacy Pass tokens used in MoQ MUST follow the structure defined in for the PrivateToken HTTP authentication scheme. The token structure includes:

Token Type: 2-byte identifier specifying the issuance protocol used
Nonce: 32-byte client-generated random value for uniqueness
Challenge Digest: 32-byte SHA-256 hash of the TokenChallenge
Token Key ID: Variable-length identifier for the issuer's public key
Authenticator: Variable-length cryptographic proof bound to the token

Token Challenge Structure for MoQ MoQ-specific TokenChallenge structures use the default format defined in with MoQ-specific parameters in the origin_info field, reproduced thereafter for convenience: ; opaque redemption_context<0..32>; opaque origin_info<0..2^16-1>; } TokenChallenge; ]]> For MoQ usage, authorization scope information can be encoded by the origin within origin_info field. This is encoded in the Token at issuance time when types 0x0001, 0x0002, 0x0005 are used. When clients present a credential such as with , the scope may be restricted at presentation time. Origins MAY use redemption_context to scope token use to properties of the client session. As described in , redemption context can be set to 32-byte random nonce, to the hash of a specific time window, or even derived from the client's ASN.

MoQ Actions MoQ operations are identified by the following action values, aligned with MoQTransport control message types: MoQ Action Values

Action	Value	Reference
CLIENT_SETUP	0
SERVER_SETUP	1
PUBLISH_NAMESPACE	2
SUBSCRIBE_NAMESPACE	3
SUBSCRIBE	4
REQUEST_UPDATE	5
PUBLISH	6
FETCH	7
TRACK_STATUS	8
SUBSCRIBE_TRACKS	9

The default authorization policy is "blocked" - all actions are denied unless explicitly permitted by a token scope. MoQAction wire representation is as follows

Match Types Match rules for namespaces and track names support the following types: Match Type Values

Match Type	Value	Description
MATCH_EXACT	0	Value must equal the pattern exactly
MATCH_PREFIX	1	Value must start with the pattern
MATCH_SUFFIX	2	Value must end with the pattern
MATCH_CONTAINS	3	Value must contain the pattern as substring

Track namespaces in MoQ are represented as ordered tuples of byte strings (e.g., ["example.com", "live", "sports"]). Match rules operate on these tuples at tuple element boundaries. The pattern in a MatchRule (defined in ) is also a tuple of byte strings, and matching is performed element-by-element. As for track names, match rules can be applied directly given there is a single tuple element. No normalization is performed on namespace tuple elements or track name values before matching. Comparisons are performed as byte-level operations on each tuple element. MatchType wire representation is as follows

Authorization Scope Structure (origin_info) When authorization scope is bound at issuance time, the origin_info field contains a binary-encoded MoQAuthorizationInfo structure: ; } TupleElement; struct { TupleElement elements<0..2^16-1>; } NamespaceTuple; struct { MatchType match_type; NamespaceTuple value; } NamespaceMatchRule; struct { MatchType match_type; opaque value<0..2^16-1>; } TrackNameMatchRule; struct { MoQAction actions<1..2^8-1>; NamespaceMatchRule namespace_match; TrackNameMatchRule track_name_match; } MoQAuthScope; struct { MoQAuthScope scopes<1..2^8-1>; } MoQAuthorizationInfo; ]]> A token MAY contain multiple MoQAuthScope entries to authorize different combinations of actions and resource patterns. Authorization succeeds if ANY scope in the token permits the requested operation.

Examples The following examples illustrate authorization scope configurations: Subscribe to live sports namespace (prefix match): This matches namespace tuples like ["sports.example.com", "live", "soccer"] and ["sports.example.com", "live", "tennis", "finals"]. Publish to specific meeting track (exact match): This matches only the exact namespace tuple ["meetings.example.com", "meeting", "m123"] with track names starting with "audio-". Fetch video-on-demand with suffix matching: This matches namespace tuples containing the contiguous subsequence ["vod", "movies"], such as ["example.com", "vod", "movies", "action"].

Track Namespace and Track Name Matching Rules This specification defines matching rules for track namespaces and track names to enable fine-grained access control while maintaining privacy. Both namespace and track name matching use the same MatchRule structure and algorithm.

Match Rule Evaluation Given a MatchRule and a target value (namespace tuple or track name), the match succeeds according to the following rules. For namespace matching, both the pattern and target are tuples of byte strings. Matching operates at tuple element boundaries. MATCH_EXACT (0): The target MUST be identical to the pattern. For namespace tuples, this means the same number of elements with each element byte-for-byte identical. The pattern tuple ["example.com", "live"] matches only ["example.com", "live"], not ["example.com", "live", "sports"]. MATCH_PREFIX (1): The target MUST start with the pattern at tuple element boundaries. The pattern tuple ["example.com", "live"] matches ["example.com", "live", "sports"] and ["example.com", "live", "news", "breaking"] but not ["example.com", "vod"]. Note that ["example.com", "liv"] does NOT match ["example.com", "live"] since matching is at element boundaries. MATCH_SUFFIX (2): The target MUST end with the pattern at tuple element boundaries. The pattern tuple ["audio"] matches ["meeting123", "audio"] and ["conference", "room1", "audio"] but not ["audio", "opus"]. MATCH_CONTAINS (3): The target MUST contain the pattern as a contiguous subsequence of tuple elements. The pattern tuple ["live", "sports"] matches ["example.com", "live", "sports", "soccer"] but the single-element pattern ["sports"] does NOT match ["live-sports", "channel"] since "sports" is a substring within an element, not a complete element. Note: To match all values, use MATCH_PREFIX with an empty pattern ([] for namespaces or "" for track names). An empty pattern is a prefix of every value.

Matching Algorithm When a MoQ relay receives a request with a Privacy Pass token, it performs the following validation steps to determine whether to authorize the requested operation:

Token Validation and Matching Algorithm | Authorization | | Protection | No | Failed | +--------+---------+ +----------------+ | v +------------------+ +----------------+ | Verify Token |---->| Authorization | | (Type-specific) | No | Failed | +--------+---------+ +----------------+ | Yes v +------------------+ | Extract Scope | | (origin_info) | +--------+---------+ | v +------------------+ +----------------+ | +---------------->| Authorization | | For each Scope | No more scopes | Failed | | |<---------+ +----------------+ +--------+---------+ | | | v | +------------------+ | | Action in |----------+ | scope.actions? | No | +--------+---------+ | | Yes | v | +------------------+ | | Namespace Match |----------+ | Rule passes? | No | +--------+---------+ | | Yes | v | +------------------+ | | Track Name Match |----------+ | Rule passes? | +--------+---------+ | Yes v +------------------+ | Authorization | | Granted | +------------------+ ]]>

Token Extraction: Extract the Privacy Pass token from the MoQ control message (SETUP, SUBSCRIBE, FETCH, PUBLISH, PUBLISH_NAMESPACE, or other operation).
Token Verification: Verify the token using the appropriate method for the token type:
- Token Type 0x0001 or 0x0005 (VOPRF): Verify using the issuer's private validation key
- Token Type 0x0002 (Blind RSA): Verify using the issuer's public verification key
- Token Type 0xE5AC (ARC): Verify the presentation proof using the issuer's public parameters
Replay Protection: Validate that the token has not been replayed:
- Check token nonce uniqueness within the configured replay window
- Verify token expiration timestamp if present in token metadata
Scope Extraction: Extract authorization scope from the token:
- If using origin_info: Decode the MoQAuthorizationInfo structure
Scope Evaluation: For each MoQAuthScope in the token, check if the requested operation is authorized: a. Action Check: Verify the requested MoQ action (from ) is present in the scope's actions list b. Namespace Match: Apply the namespace_match rule to the requested track namespace using the algorithm in . Requests that carry a Track Namespace Prefix follow c. Track Name Match: Apply the track_name_match rule to the requested track name using the algorithm in d. If all three checks pass, authorization succeeds for this scope
Authorization Decision: Access is granted if and only if:
- Token verification succeeds (step 2)
- Replay protection passes (step 3)
- At least one scope in the token authorizes the operation (step 5)

If authorization fails, an error is returned as specified in .

Requests on a Track Namespace Prefix PUBLISH_NAMESPACE, SUBSCRIBE_NAMESPACE, and SUBSCRIBE_TRACKS carry a Track Namespace Prefix instead of a track namespace and track name. Such a request covers every track namespace that begins with the prefix, so a scope authorizes it only if it covers all of them:

Namespace check: The namespace_match rule MUST be MATCH_PREFIX, and its pattern MUST be a prefix of the requested Track Namespace Prefix. Other match types cannot cover an open-ended set of namespaces.
Track name check: PUBLISH_NAMESPACE and SUBSCRIBE_NAMESPACE do not name tracks, so track_name_match is not evaluated for them. SUBSCRIBE_TRACKS results in subscriptions to any track under the prefix, so its track_name_match MUST be MATCH_PREFIX with an empty pattern.

As an alternative, a relay MAY accept SUBSCRIBE_NAMESPACE or SUBSCRIBE_TRACKS under a narrower scope, provided it only sends NAMESPACE, NAMESPACE_DONE, PUBLISH, or PUBLISH_SKIPPED messages for namespaces and tracks that the scope covers. PUBLISH messages that a relay sends as a result of SUBSCRIBE_TRACKS are covered by the token presented in the SUBSCRIBE_TRACKS. That token is not copied into them ().

Required MoQ Transport Extensions This document uses the Error Details mechanism of to carry AUTH CHALLENGE in REQUEST_ERROR. It also defines AUTH CHALLENGE Setup Options and Message Parameters, and AUTH REQUEST and AUTH RESPONSE for reverse flow issuance. These hooks are scheme-agnostic: any authorization scheme with a codepoint in the "MOQT Auth Token Type" registry can use them. [[editor's note: These hooks depend on ongoing MoQ Transport authentication work (see https://github.com/moq-wg/moq-transport/issues/1658). provides Error Details in REQUEST_ERROR, but the AUTH CHALLENGE binding remains undefined. SETUP challenge delivery and in-band issuance, including successful-response parameters, also remain open. AUTH REQUEST and AUTH RESPONSE describe the exchange needed for reverse flow. They are not an adopted AUTH design-team solution.]]

AUTH CHALLENGE AUTH CHALLENGE is a repeatable, odd-numbered Error Detail in REQUEST_ERROR, using the Key-Value-Pair encoding of . Its value has the following encoding, also used by the Message Parameter and Setup Option counterparts:

Token Type: a codepoint from the "MOQT Auth Token Type" registry of , identifying the authorization scheme.
Challenge: opaque bytes whose format is defined by the Token Type.

The parameter conveys that the sender will accept a credential of this Token Type satisfying this Challenge. It MAY be repeated within a message. Challenges are ordered by sender preference, most preferred first. A receiver ignores challenges whose Token Type it does not support. The Error Detail applies to the error codes in and MAY appear more than once in a REQUEST_ERROR. Its encoding and size limits follow . The Message Parameter can appear in successful responses (REQUEST_OK, SUBSCRIBE_OK, FETCH_OK), including REQUEST_OK responding to REQUEST_UPDATE (REQUEST_UPDATE_OK). The Setup Option can appear in SERVER_SETUP. [[editor's note: The codepoint in the "MOQT Error Detail Types" registry of remains TBD, pending definition of the generic transport challenge mechanism.]] For this document, the Token Type is PRIVACY_PASS_TOKEN () and the Challenge is a TokenChallenge as defined in .

AUTH REQUEST and AUTH RESPONSE Parameters The AUTH REQUEST and AUTH RESPONSE parameters are length-prefixed Message Parameters, with Setup Option counterparts of identical encoding: AUTH REQUEST asks the receiver to produce credential material defined by the authorization scheme, such as a token issuance or renewal request. It can appear wherever the AUTHORIZATION TOKEN parameter can, including REQUEST_UPDATE, and in CLIENT_SETUP as an option. A receiver that does not support the Token Type, or is unwilling to issue, ignores the parameter and processes the message as if it were absent. The sender detects this by the absence of a matching AUTH RESPONSE. AUTH RESPONSE carries the material produced in answer to an AUTH REQUEST. It can appear in the response to the message that carried the AUTH REQUEST (REQUEST_OK, SUBSCRIBE_OK, FETCH_OK) and in SERVER_SETUP as an option. It MUST NOT be sent unsolicited. Request and response payloads are transient: they are not registered in the token cache and do not count against MAX_AUTH_TOKEN_CACHE_SIZE. Issuance is between the client and its peer relay acting as issuer. These parameters do not request issuance by an upstream relay or original publisher. [[editor's note: The transport binding needs to specify how issuance requests and responses are correlated when REQUEST_UPDATE processing is coalesced. The existing parameter update rules do not define this exchange.]] For this document, the Token Type is PRIVACY_PASS_TOKEN and the payloads are the issuance structures listed in .

Token in MOQ Messages Privacy Pass tokens are provided to MoQ relays using the existing MoQ authorization framework with the following adaptations:

SETUP Message Authorization For connection-level authorization, the client includes an AUTHORIZATION TOKEN Setup Option () whose Token Type is PRIVACY_PASS_TOKEN and whose Token Value is a Token structure. When the client also wants tokens or credentials issued over this connection (), it adds an AUTH REQUEST option (). The relay answers with an AUTH RESPONSE option in SERVER_SETUP. The Token structure is prepended by a two-byte token type identifier as registered with IANA: ; } } Token; ]]> Where Nk is determined by token_type per the . Unknown token types MUST be rejected. Each endpoint sends SETUP independently and MAY send it before receiving the peer's SETUP (). A relay that authenticates SETUP or supports issuance through AUTH REQUEST MUST receive and process the client's SETUP before sending its own, so it can include any required AUTH CHALLENGE or AUTH RESPONSE. Requests that a client pipelines after its SETUP are lost if the relay terminates the session with UNAUTHORIZED.

MoQ Operation-Level Authorization For individual MoQ operation authorization, tokens are included in operation-specific control messages:

Token Aliases lets a sender register a token under an Alias and refer to it later with USE_ALIAS. Privacy Pass tokens are single-use, so a sender MUST use Alias Type USE_VALUE for tokens with Token Type PRIVACY_PASS_TOKEN and MUST NOT register them. A receiver still processes a REGISTER as requires. Every message whose token resolves to a PRIVACY_PASS_TOKEN, by value or by alias, redeems that token and is subject to the replay check in . A USE_ALIAS that refers to an already redeemed token therefore fails with TOKEN_REPLAYED. A relay that only accepts Privacy Pass tokens can leave MAX_AUTH_TOKEN_CACHE_SIZE at its default of 0, which prohibits aliases ().

Continuous Authorization with Batched Tokens Long-lived MoQ sessions (such as live streaming or real-time communication) require periodic re-authorization to ensure continued eligibility. Unlike JWT-based approaches that use explicit revalidation intervals, Privacy Pass can achieve continuous authorization through batched token issuance. During the initial SETUP exchange, clients can request multiple tokens by sending a GenericBatchTokenRequest (defined in ) in an AUTH REQUEST option. Each token in the batch is independently valid and can be presented for subsequent operations or periodic re-authorization. Relays MAY request periodic re-authorization by attaching an AUTH CHALLENGE Error Detail to a REQUEST_ERROR, or an AUTH CHALLENGE parameter ahead of time to a successful response alongside the EXPIRES parameter of , which tells the client what its extending REQUEST_UPDATE needs to present. Clients SHOULD present a fresh token from their batch in response if any satisfy the new TokenChallenge. If not, they SHOULD perform a new issuance process. When using tokens (0xE5AC), the credential's presentation_limit controls how many times the client can present tokens from a single credential issuance. This provides rate limiting while preserving unlinkability between presentations. Deployment Considerations:

Batch size SHOULD be sufficient for the expected session duration
Relays SHOULD configure re-authorization intervals based on content sensitivity and trust requirements
Clients SHOULD request new token batches before exhausting their supply
For high-security deployments, shorter re-authorization intervals with smaller batches provide stronger revocation guarantees

Continuous Authorization with Reverse Flow If the client and the relay support it, a Relay MAY perform continuous authentication using a reverse flow. To do so, a client attaches an AUTH REQUEST parameter, carrying at least one token request, to a message that also carries its AUTHORIZATION TOKEN. The Relay acts as a reverse issuer and returns the corresponding AUTH RESPONSE in the message answering it: SERVER_SETUP for a CLIENT_SETUP, or the corresponding REQUEST_OK, SUBSCRIBE_OK, or FETCH_OK for requests on an established connection. In particular, a subscriber can replenish its token supply without a new round trip to the origin issuer by sending REQUEST_UPDATE with an AUTH REQUEST parameter. This composes with the expiry-driven update cycle of : when a subscription carries an EXPIRES parameter, the extending REQUEST_UPDATE presents a fresh token and requests the next one in the same message. Tokens obtained this way can be presented by the Client to maintain the continuity of the session. The presentations are cryptographically unlinkable, subject to the privacy properties of the token type and deployment. Presentations on the same MoQ connection can still be correlated through the connection, timing, or request metadata. A connection may carry requests for multiple actors, so this correlation does not by itself identify an actor.

Errors If the authentication fails for any reason, the server MUST send an error. The error response includes a TokenChallenge to enable the client to obtain a valid token and retry the operation.

SETUP Errors [[editor's note: The following SETUP procedure depends on transport work described in . Sending SERVER_SETUP before closing does not guarantee that the client receives the challenge. MoQ Transport still needs to define challenge delivery before session termination.]] If authentication fails during SETUP, the Relay MUST send a SERVER_SETUP carrying one or more AUTH CHALLENGE Setup Options () and then terminate the session with the UNAUTHORIZED (0x02) Termination Error Code defined in . The termination reason phrase carries no challenge material. It stays a human-readable string, as the QUIC CONNECTION_CLOSE frame requires. Each AUTH CHALLENGE option carries one TokenChallenge. Options are ordered by relay preference, most preferred first, which lets the client select an issuance protocol based on the token types and issuers it supports. Different options MAY name different issuers or scopes for different token types. The Relay MUST include at least one challenge. The client can then obtain a token satisfying one of the challenges and establish a new session presenting it. Since requires endpoints to ignore unknown Setup Options, a client that does not support this mechanism observes a regular UNAUTHORIZED termination.

Operation Errors If the error occurs over an established connection, the Relay MUST send a REQUEST_ERROR defined in . The error code MUST be one of: Privacy Pass Authorization Error Codes

Error Code	Name	Description
0x4	MALFORMED_AUTH_TOKEN	Token cannot be parsed correctly
0x5	EXPIRED_AUTH_TOKEN	Token has expired or been revoked
0x0100	TOKEN_MISSING	No token provided when required
0x0101	TOKEN_INVALID	Token signature verification failed
0x0103	TOKEN_REPLAYED	Token nonce has been seen before
0x0104	SCOPE_MISMATCH	Token scope does not authorize this operation
0x0105	ISSUER_UNKNOWN	Token issuer is not trusted by this relay

MALFORMED_AUTH_TOKEN and EXPIRED_AUTH_TOKEN are defined in . This document registers the remaining codes in the REQUEST_ERROR Codes registry (). When the client should retry with a new token, the REQUEST_ERROR MUST carry one or more AUTH CHALLENGE Error Details (), ordered by relay preference. The reason phrase stays a human-readable string.

TokenChallenge Construction The TokenChallenge carried in each AUTH CHALLENGE MUST be constructed as follows:

token_type: The token type for this challenge
issuer_name: The issuer name that can issue tokens for this challenge
redemption_context: A fresh 32-byte random value, or empty if the relay accepts tokens with any redemption context
origin_info: The relay's origin identifier, optionally including the required authorization scope

Different challenges MAY specify different issuers or scopes for different token types. When origin_info is empty, the relay accepts tokens with any scope and performs authorization based solely on the token's embedded scope information.

Error Response Example This example uses Error Details from and the AUTH CHALLENGE binding in . , origin_info = } }, AUTH_CHALLENGE { token_type = PRIVACY_PASS_TOKEN, challenge = TokenChallenge { token_type = 0xE5AC, issuer_name = "relay.example.com", redemption_context = <32 random bytes>, origin_info = } }, AUTH_CHALLENGE { token_type = PRIVACY_PASS_TOKEN, challenge = TokenChallenge { token_type = 0x0001, issuer_name = "relay.example.com", redemption_context = <32 random bytes>, origin_info = } } ] } ]]> Note the two levels of token type: the Error Detail's token_type names the authorization scheme in the "MOQT Auth Token Type" registry, while the TokenChallenge.token_type names the Privacy Pass issuance protocol inside that scheme.

Control Message Authorization Failures When authorization fails for MoQ control messages other than SETUP, the relay returns a REQUEST_ERROR with the appropriate error code from . The client MAY retry the operation with a valid token obtained using the TokenChallenge from the error response. Implementations MAY elevate request-specific errors to session-level errors by closing the session with UNAUTHORIZED (). This elevation is appropriate when:

The authorization failure indicates a systemic issue (e.g., all client tokens are from an untrusted issuer)
Continuing the session would be futile due to policy restrictions
The error represents a security concern requiring session termination

Implementations need to consider the impact on other outstanding subscriptions before elevating to session-level errors.

Loss of Authorization on Established Requests A relay can determine that an established request is no longer authorized, for example because the client did not present a fresh token before the EXPIRES deadline, or because a REQUEST_UPDATE carried a token that failed verification. The relay answers a failed REQUEST_UPDATE with a REQUEST_ERROR as described in . To end the underlying request:

For a subscription, a failed REQUEST_UPDATE requires PUBLISH_DONE with status UPDATE_FAILED (). Token expiry uses EXPIRED_AUTH_TOKEN. Other loss of authorization uses UNAUTHORIZED ().
For a FETCH in progress, the relay resets the fetch stream with EXPIRED_AUTH_TOKEN ().

Request Migration A request that is re-issued after a GOAWAY (), on a new session or on the current one, MUST carry a fresh token. The token presented with the original request has already been redeemed.

Retry Behavior AUTH CHALLENGE values are ordered by relay preference. A client selects the first challenge whose token type it supports and whose issuer it trusts. If no challenge qualifies, the client MUST NOT retry the operation and SHOULD surface the failure to the application. If the client holds an unused token satisfying the selected challenge, for example from a batch obtained earlier (), it SHOULD present that token rather than start a new issuance. For operation errors, retry timing is governed by the Retry Interval field of REQUEST_ERROR (): the client MUST NOT retry before the interval has elapsed, and MUST NOT retry at all when the interval is 0. Tokens are single-use, so every retry consumes a token and possibly an issuance round trip. A client SHOULD treat a second consecutive failure of the same operation with the same error code as terminal rather than retry further. In particular, SCOPE_MISMATCH is only worth retrying if the client can obtain a token whose scope actually covers the operation. Retrying with an identically scoped token cannot succeed. The same limit applies across connections: after a session termination with UNAUTHORIZED, a client SHOULD NOT reconnect with a token for the same challenge more than once unless its attestation context has changed.

Example Authorization Flow Below shows an example deployment scenario where the relay has been configured with the necessary validation keys and content policies. The relay can verify Privacy Pass tokens locally and deliver media directly without contacting the Issuer. This example uses publicly verifiable tokens.

Direct Relay Authorization Flow | | | | [AUTH CHALLENGE] | | | +-- UNAUTHORIZED (0x2) ->| | | | | | | | |<=Attestation=> | | | | | | +------- TokenRequest ---->| | |<------ TokenResponse ----+ | | | | | FinalizeToken | | | | | | |<--- CLIENT_SETUP ------+ | | | [AUTHORIZATION TOKEN] | | | | | | | .-------------+--. | | | | Local validation | | | | '-------------+--' | | | | | | | +-- SERVER_SETUP ------->| | | | | | | ]]> The AUTH CHALLENGE options in the SERVER_SETUP carry one TokenChallenge per token type the relay accepts (e.g., 0x0002 and 0xE5AC), each with the relay's issuer configuration. This allows the client to select the appropriate issuance protocol based on its capabilities and the available attesters/issuers.

Security Considerations TODO: Add considerations for the security and privacy of the Privacy Pass tokens.

Token Replay
Token harvest
Key rotation
Use of TLS

IANA Considerations

MOQT Auth Token Type Registration IANA is requested to register the following entry in the "MOQT Auth Token Type" registry defined by : MOQT Auth Token Type Registration

Code	Name	Specification
TBD	PRIVACY_PASS_TOKEN	This document

MoQ Action Registry IANA is requested to create a new registry titled "MoQ Actions for Privacy Pass Authorization" with the following initial contents: MoQ Actions Registry

Value	Action	Reference
0	CLIENT_SETUP
1	SERVER_SETUP
2	PUBLISH_NAMESPACE
3	SUBSCRIBE_NAMESPACE
4	SUBSCRIBE
5	REQUEST_UPDATE
6	PUBLISH
7	FETCH
8	TRACK_STATUS
9	SUBSCRIBE_TRACKS
10-254	Unassigned
255	Reserved	This document

New entries in this registry require Specification Required registration policy. Values SHOULD align with MoQTransport control message types where applicable.

MoQ Match Type Registry IANA is requested to create a new registry titled "MoQ Match Types for Privacy Pass Authorization" with the following initial contents: MoQ Match Types Registry

Value	Match Type	Reference
0	MATCH_EXACT
1	MATCH_PREFIX
2	MATCH_SUFFIX
3	MATCH_CONTAINS
4-254	Unassigned
255	Reserved	This document

New entries in this registry require Specification Required registration policy.

REQUEST_ERROR Code Registrations IANA is requested to register the following entries in the "REQUEST_ERROR Codes" registry defined in : REQUEST_ERROR Code Registrations

Code	Name	Specification
0x0100	TOKEN_MISSING
0x0101	TOKEN_INVALID
0x0103	TOKEN_REPLAYED
0x0104	SCOPE_MISMATCH
0x0105	ISSUER_UNKNOWN

References Normative References Anonymous Rate-Limited Credentials Cryptography Apple, Inc. Apple, Inc. Cloudflare This document specifies the Anonymous Rate-Limited Credential (ARC) protocol, a specialization of keyed-verification anonymous credentials with support for rate limiting. ARC credentials can be presented from client to server up to some fixed number of times, where each presentation is cryptographically bound to client secrets and application-specific public information, such that each presentation is unlinkable from the others as well as the original credential creation. ARC is useful in applications where a server needs to throttle or rate-limit access from anonymous clients. Media over QUIC Transport 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. Privacy Pass Issuance Protocol for Anonymous Rate-Limited Credentials Apple, Inc. Apple, Inc. Cloudflare This document specifies the issuance and redemption protocols for tokens based on the Anonymous Rate-Limited Credential (ARC) cryptographic protocol. Key words for use in RFCs to Indicate Requirement Levels 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. RSA Blind Signatures This document specifies an RSA-based blind signature protocol. RSA blind signatures were first introduced by Chaum for untraceable payments. A signature that is output from this protocol can be verified as an RSA-PSS signature. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between a client and a server for computing the output of a Pseudorandom Function (PRF). The server provides the PRF private key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF private key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of 'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially oblivious, called a POPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. The Privacy Pass Architecture This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model, to help ensure that the desired security and privacy goals are fulfilled. The Privacy Pass HTTP Authentication Scheme This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme specified in this document can be used by Clients to redeem Privacy Pass tokens with an Origin. It can also be used by Origins to challenge Clients to present Privacy Pass tokens. Privacy Pass Issuance Protocols This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the Issuer Private Key and one that produces tokens that are publicly verifiable using the Issuer Public Key. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Informative References Batched Token Issuance Protocol 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. Privacy Pass IANA n.d. Privacy Pass Reverse Flow Cloudflare Inc. This document specifies an instantiation of the Privacy Pass Architecture (RFC 9576) 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. Checking Resource Consistency with HTTP Mirrors Mozilla Apple Inc. Google LLC Cloudflare Apple Inc. This document describes the mirror protocol, an HTTP-based protocol for fetching mirrored HTTP resources. The primary use case for the mirror protocol is to support HTTP resource consistency checks in protocols that require clients have a consistent view of some protocol-specific resource (typically, a public key) for security or privacy reasons, including Privacy Pass and Oblivious HTTP. To that end, this document also describes how to use the mirror protocol to implement these consistency checks. Key Transparency Architecture Independent This document defines the terminology and interaction patterns involved in the deployment of Key Transparency in end-to-end encrypted communication services, and specifies the security properties that the protocol provides. It also gives more general, non-prescriptive guidance on how to securely apply Key Transparency to a number of common applications. An Architecture for Trustworthy and Transparent Digital Supply Chains Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements.

Deployment considerations

Fetching key material for the bootstrap issuer This draft does not define how Clients are expected to retrieve privacy pass issuer configuration, nor how they establish a relationship with an attester that is capable of vouching for such tokens to be issued. Clients may reuse issuers that are exposed over HTTP, as defined in . Clients should also consider ways to be less susceptible to partitions, hurting the privacy guarantees that Privacy Pass provides. This is discussed in . For that, they may rely on mechanisms such as using mirrors providing multiple vantage points, or transparency mechanisms such as those in or .

Fetching key material for the relay reverse issuer Similarly, Clients should retrieve material for the relay issuer operating in a reverse mode. This can be via a pre-established relation, such as shipped as part of the initial app installation, webpage load, or device setup. This can also be done on the fly via HTTP, or MoQ API. This draft does not define any of these. Consistency considerations mentioned in apply.

Acknowledgments TODO acknowledge.

Changelog RFC Editor's Note: Please remove this section prior to publication of a final version of this document.

Since draft-ietf-moq-privacy-pass-auth-02

Move reverse flow issuance to AUTH REQUEST and AUTH RESPONSE parameters
Allow token acquisition over an established connection via REQUEST_UPDATE
Remove PrivateTokenAuth structures and the auth scheme registry
Carry TokenChallenge in AUTH CHALLENGE transport parameters instead of reason phrases
Define required MoQ Transport extensions (AUTH CHALLENGE, AUTH REQUEST/RESPONSE)
Bind request-error challenges to Error Details and identify remaining SETUP and issuance dependencies
Clarify that token unlinkability does not hide connection-level correlation
Align with draft-ietf-moq-transport-23: single SETUP message, updated section references
Add SUBSCRIBE_TRACKS action and define matching for Track Namespace Prefix requests
Require USE_VALUE for Privacy Pass tokens and treat alias reuse as replay
Require relays to wait for the client's SETUP before sending challenge or issuance options
Reuse MoQT MALFORMED_AUTH_TOKEN and EXPIRED_AUTH_TOKEN, register remaining codes in the REQUEST_ERROR Codes registry
Specify PUBLISH_DONE and stream reset codes when authorization ends, and fresh tokens after GOAWAY
Register a Privacy Pass codepoint in the MOQT Auth Token Type registry
Specify retry behavior after auth challenge errors
Expanded reverse flow documentation with three-phase flow (bootstrap, exchange, operations)
Defined MoQAuthChallenge structure for error responses with supported_token_types
Added TokenChallenge construction requirements
Added control message authorization failure handling section
Documented credential request/response encoding for different token types

Since draft-ietf-moq-privacy-pass-auth-01

Replace text-based moq-scope with binary TLS presentation language structures
Add MoQ Actions registry aligned with MoQTransport control message types
Add Match Types registry with exact, prefix, suffix, and contains matching
Define MoQAuthorizationInfo structure for origin_info encoding
Add continuous authorization section using reverse flow
Add continuous authorization section using batched tokens
Add IANA registries for auth schemes, actions, and match types
Define error handling
Integrate privacy pass reverse flow within PrivateTokenAuth
MoQ definition now follow draft-ietf-moq-transport-16
Update dependencies
Removed b64 encoding given MoQ can use bytes directly

Since draft-ietf-moq-privacy-pass-auth-00

Add Thibault Meunier as Coauthor
Add support for Reverse flow to be deploy and scale friendly way to get tokens