]> 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 access to 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.
• MoQ Relay/Origin: The MoQ relay server or origin that forwards media content and requires authorization. The relay validates Privacy Pass tokens, enforces access policies, and forwards authorized requests to origins or 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 role, allowing it to use privately verifiable token types registered in . In this scenario, the MoQ relay origin would accept tokens signed by two issuers:

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

With , the flow would look as follow | | | | | +----- Response -->| | | | | +TokenResponseO | | | | | | | | ]]> TokenRequestO and TokenResponseO are part of a reverse flow. The client request a new token/credential to the origin. It allows the client to exchange its initial 0x0002 Token against a privately verifiable token issued by the origin. TokenRequestO should correspond to the associated privately verifiable token definition. These are listed in . All privately verifiable scheme allow to amortise token issuance cost, making them more compelling in a streaming case. This is specified in . When using 0xE5AC, TokenRequestO is a CredentialRequest defined in .

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

• Issuer and attesters do not collude to guarantee unlinkability properties
• 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: ; opaque redemption_context<0..32>; opaque origin_info<0..2^16-1>; } TokenChallenge; ]]> For MoQ usage, the origin_info field contains MoQ-specific authorization scope information encoded as a UTF-8 string with the following format:

• TODO: Define origin_info to be binary format using TLS presentation language For anonymous credentials, it would make a lot more sense to use redemption_context instead of origin_info, as redemption_context is decided upon at presentation time rather than at issuance time. Question that I don't have the answer yet: are 32-bytes enough? we might need to say something like "first 2 bytes represent the type of rule, then data"

Examples:

• subscribe:sports.example.com/live/* - Subscribe to any track under live sports
• fetch:vod.example.com/movies/action* - Fetch video-on-demand action content
• publish:meetings.example.com/meeting/m123/audio/opus48000 - Publish content for meeting m123

Track Namespace and Track Name Matching Rules This specification defines prefix-based matching rules for track namespaces and track names to enable fine-grained access control while maintaining privacy.

Namespace Matching Track namespace matching supports three modes: Exact Match:

• Pattern: "example.com/live/sports/soccer"
• Matches: Only the exact namespace example.com/live/sports/soccer

Prefix Match:

• Pattern: "example.com/live/sports/*"
• Matches: Any namespace starting with example.com/live/sports/
• Examples: example.com/live/sports/soccer, example.com/live/sports/tennis

Track Name Matching Track name matching within authorized namespaces follows the same pattern: Exact Match:

• Pattern: "video"
• Matches: Only tracks named exactly video

Prefix Match:

• Pattern: "video*"
• Matches: Any track name starting with video
• Examples: video-med, video-high, video-low

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:

1. Extract the Privacy Pass token from the MoQ control message (SETUP, SUBSCRIBE, FETCH, PUBLISH, or ANNOUNCE)
2. Verify the token signature using the appropriate issuer public key based on the token type:
   • For Token Type 0x0001 (VOPRF(P-384, SHA-384)): Use the issuer's private validation key
   • For Token Type 0x0002 (Blind RSA(2048 bits)): Use the issuer's public verification key
3. Validate that the token has not been replayed by checking:
   • Token nonce uniqueness within the issuer's replay window
   • Token expiration timestamp (if present in token metadata)
4. Extract the MoQ-specific authorization scope from the token's origin_info field:
   • Authorized operation type (subscribe, fetch, publish, announce)
   • Namespace pattern (exact match or prefix match)
   • Track name pattern (exact match or prefix match, optional)
5. Verify that the requested MoQ operation matches the operation specified in the token scope:
   • SUBSCRIBE operations require "subscribe" scope
   • FETCH operations require "fetch" scope
   • PUBLISH operations require "publish" scope
   • ANNOUNCE operations require "announce" scope
6. Apply namespace/name matching rules based on the pattern type:
   • If Exact Match, the requested namespace/name MUST exactly equal the pattern
   • If Prefix Match, the requested namespace/name MUST start with the pattern prefix

Access is granded to the requested resource if and only if ALL of the following conditions are met:

• Token signature verification succeeds
• Token nonce has not been previously used (replay protection)
• Token has not expired (if applicable)
• Requested operation matches token operation scope
• Requested namespace matches token namespace pattern
• Requested track name matches token track name pattern (if specified) specified)

else, authorzation error is returned to the requesting client.

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: ; } PrivateTokenAuth; ]]>

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

Example Authorization Flow Below shows an example deployment scenarios 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 uses token with public verifiability.

Direct Relay Authorization Flow | | | | |<== Attestation ==>| | | | | | | +--------- TokenRequest ------->| | |<-------- TokenResponse -------+ | | | | |<---- SUBSCRIBE+Token ----+ | | .----+-----------. | | | | Local validation | | | | `----+-----------' | | | +-- SUBSCRIBE_OK+Media --->| | | | | | | ]]>

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 TODO

• Register namespace?
• New registry for auth_scheme with 0x01 as the first registered auth_scheme

References Normative References Apple, Inc. Apple, Inc. 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. 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. Apple, Inc. Apple, Inc. This document specifies the issuance and redemption protocols for tokens based on the Anonymous Rate-Limited Credential (ARC) protocol. 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. 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. 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. 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. 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. 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. 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 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. 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. n.d.

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

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