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.

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 UNAUTHORIZED containing a TokenChallenge specifying a publicly verifiable token type (0x0002).
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:
- The publicly verifiable Token from Phase 1
- A CredentialRequest (or TokenRequest) 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:
- A CredentialResponse (or TokenResponse) 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 GenericBatchTokenRequest in ClientPrivateTokenAuth contains the credential or token request for the privately verifiable token type:

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

Similarly, GenericBatchTokenResponse in ServerPrivateTokenAuth contains:

For 0x0001 or 0x0005: TokenResponse 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

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

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, Privacy Pass tokens are included in the SETUP message's authorization parameter (). For CLIENT_SETUP, the authorization value uses GenericBatchTokenRequest as defined in as follows: For SERVER_SETUP, the authorization value uses GenericBatchTokenResponse as defined in as follows: When batch issuance is not used, token_requests and token_responses are empty (length = 0). 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.

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

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 via GenericBatchTokenRequest (defined in ). 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 sending a TokenChallenge in a REQUEST_ERROR message. 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, when presenting PrivateTokenAuth, a client MUST send at least one GenericBatchTokenRequest. The Relay then acts as a reverse issuer, and issues the corresponding number of GenericBatchTokenResponse. Tokens obtained this way can be presented by the Client to maintain the continuity of the session without linkability.

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 If authentication fails during SETUP, the Relay MUST terminate the connection with the UNAUTHORIZED (0x02) Termination Error Code defined in . The termination reason phrase MUST contain a MoQAuthChallenge structure: ; } MoQAuthChallenge; ]]> The challenges field lists token challenges the relay accepts, ordered by preference (most preferred first). This allows clients to select an appropriate issuance protocol based on supported token types and issuers. Each challenge specifies a token type, issuer, and optional scope, enabling relays to accept different issuers or scopes for different token types. Relay MUST include at least one challenge.

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
0x0100	TOKEN_MISSING	No token provided when required
0x0101	TOKEN_INVALID	Token signature verification failed
0x0102	TOKEN_EXPIRED	Token has expired or been revoked
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
0x0106	TOKEN_MALFORMED	Token cannot be parsed correctly

The reason phrase in REQUEST_ERROR MUST contain a MoQAuthChallenge structure when the client should retry with a new token, encoded as a byte-string.

TokenChallenge Construction Each TokenChallenge in MoQAuthChallenge 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 , origin_info = }, TokenChallenge { token_type = 0xE5AC, issuer_name = "relay.example.com", redemption_context = <32 random bytes>, origin_info = }, TokenChallenge { token_type = 0x0001, issuer_name = "relay.example.com", redemption_context = <32 random bytes>, origin_info = } ] } } ]]>

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. As per , implementations MAY elevate request-specific errors to session-level errors. 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.

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 | | | | ] | | | | | | | | |<== Attestation ==>| | | | | | | +--------- TokenRequest ------->| | |<-------- TokenResponse -------+ | | | | | FinalizeToken | | | | | | | CLIENT_SETUP[{ | | | |<---------- AUTHORIZATION, --+ | | | PrivateTokenAuth, | | | | }] | | | | | | | .-------------+--. | | | | Local validation | | | | `-------------+--' | | | | | | | +-- SERVER_SETUP[{ -------------->| | | | AUTHORIZATION, | | | | PrivateTokenAuth, | | | | }] | | | | FinalizeToken | | | | | | ]]> The MoQAuthChallenge in the UNAUTHORIZED response contains:

A TokenChallenge with the relay's issuer configuration
A list of supported_token_types (e.g., [0x0002, 0xE5AC])

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

MoQ Privacy Pass Auth Scheme Registry IANA is requested to create a new registry titled "MoQ Privacy Pass Auth Schemes" with the following initial contents: MoQ Privacy Pass Auth Schemes

Value	Name	Reference
0x00	Reserved	This document
0x01	PrivateTokenAuth	This document

New entries in this registry require Specification Required registration policy.

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

MoQ Privacy Pass Error Code Registry IANA is requested to create a new registry titled "MoQ Privacy Pass Authorization Error Codes" with the following initial contents: MoQ Privacy Pass Error Codes Registry

Value	Name	Reference
0x0100	TOKEN_MISSING
0x0101	TOKEN_INVALID
0x0102	TOKEN_EXPIRED
0x0103	TOKEN_REPLAYED
0x0104	SCOPE_MISMATCH
0x0105	ISSUER_UNKNOWN
0x0106	TOKEN_MALFORMED
0x0107-0x01FF	Unassigned

New entries in this registry require Specification Required registration policy. Values are allocated from the 0x0100-0x01FF range reserved for Privacy Pass authorization errors.

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 the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. 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 Oblivious HTTP This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. 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 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.

Acknowledgments TODO acknowledge.

Change Log 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

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