Privacy Pass Authentication for Media over QUIC (MoQ)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 18 April 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Media over QUIC (MoQ) [MoQ-TRANSPORT] 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 [RFC9576] 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 [RFC9578] 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.¶

2. Privacy Pass Architecture for MoQ

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, and may implement rate limiting. 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.¶

In the below deployment, the MoQ relay and Privacy Pass issuer are operated by different entities to enhance privacy through separation of concerns:¶

                 Separated Issuer and Relay Architecture

┌─────────────┐                               ┌─────────────┐
│   Client    │                               │Privacy Pass │
│             │──────────(1)─────────────────►│  Attester   │
└─────────────┘                               │ (3rd Party) │
   |    │                                     └─────────────┘
   |    │
   |    |──────────(2)──────────────────────────────────
   |                                                    |
   |                                                    ▼
   |                                             ┌─────────────┐
   |                                             │ Privacy Pass│
   |(3)                                          │  Issuer     │
   |                                             │ (Separate)  │
   |                                             └─────────────┘
   │
   ▼
┌─────────────┐
│ MoQ Relay   │
└─────────────┘

(1) Client attestation with separate Attester
(2) Token issuance from separate Issuer to Client
(3) Client requests media access with token from relay

However, in certain deployments the MoQ relay and Privacy Pass issuer may be operated by the same entity to simplify key management and policy coordination. The details of such an intgrated architecture is TBD.¶

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

struct {
    uint16_t token_type;
    opaque issuer_name<1..2^16-1>;
    opaque redemption_context<0..32>;
    opaque origin_info<0..2^16-1>;
} TokenChallenge;

moq-scope = operation ":" namespace-pattern [":" track-pattern]
operation = "subscribe" / "fetch" / "publish" / "announce"
namespace-pattern = exact-match / prefix-match
track-pattern = exact-match / prefix-match
exact-match = namespace/name-string
prefix-match = namespace/name-string"*"

SETUP {
    Version = 1,
    Parameters = [
        {
            Type = AUTHORIZATION,
            Value = base64url(PrivateTokenAuth)
        }
    ]
}

struct {
    uint8_t auth_scheme = 0x01; // Privacy Pass
    opaque token_data<1..2^16-1>;
} PrivateTokenAuth;

SUBSCRIBE {
    Track_Namespace = "sports.example.com/live/soccer",
    Track_Name = "video",
    Parameters = [
        {
            Type = AUTHORIZATION,
            Value = base64url(PrivateTokenAuth)
        }
    ]
}

4. 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 Origin.¶

                    Direct Relay Authorization Flow

   Client      MoQ Relay             Issuer          Attester
     |            |                    |                |
     |            |                    |                |
     | (1) Request Service Access      |                |
     |----------->|                    |                |
     |            |                    |                |
     |  (2) Challenge (TokenChallenge) |                |
     |<-----------|                    |                |
     |            |                    |                |
     |  (3) Attestation Request        |                |
     |---------------------------------|--------------->|
     |  (4) Attestation                |                |
     |<-------------------------------------------------|
     |  (5) Token Request              |                |
     |-------------------------------->|                |
     |  (6) Token                      |                |
     |<--------------------------------|                |
     |            |                    |                |
     |  (7) SUBSCRIBE with Token       |                |
     |----------->|                    |                |
     |            |                    |                |
     |            |  (8) Local Token Validation         |
     |            |     (No external call)              |
     |            |                    |                |
     |            |                    |                |
     |  (9) SUBSCRIBE_OK + Media       |                |
     |<-----------|                    |                |
     |            |                    |                |

5. Security Considerations

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

6. IANA Considerations

TODO¶

7. References

Authors' Addresses