Privacy Pass Authentication for Media over QUIC (MoQ)

2.2.1. Reverse Flow Overview

The reverse flow, as described in Section 4 of [PRIVACYPASS-REVERSE-FLOW], allows a client to exchange a publicly verifiable token for privately verifiable tokens (or credentials) issued directly by the MoQ relay.¶

2.2.2. Detailed Reverse Flow Steps

Phase 1: Bootstrap Token Acquisition¶

1. The client initiates a connection with CLIENT_SETUP without authorization.¶

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

3. The client performs attestation with an external attester/issuer.¶

4. The client obtains a publicly verifiable token.¶

Phase 2: Token Exchange via Reverse Flow¶

1. 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)¶

2. The MoQ relay validates the bootstrap token, then processes the credential request using its internal issuer.¶

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

1. For subsequent operations (SUBSCRIBE, PUBLISH, FETCH), the client presents tokens derived from the credential obtained in Phase 2.¶

2. The MoQ relay validates tokens locally using its private verification key.¶

2.2.3. Credential Request/Response Encoding

When using the reverse flow, the AUTH REQUEST payload (Section 3.4.2) contains the credential or token request for the privately verifiable token type:¶

• For 0x0001 or 0x0005: GenericBatchTokenRequest as defined in Section 6.1 of [PRIVACYPASS-BATCHED]¶

• For 0xE5AC: CredentialRequest as defined in Section 7.1 of [PRIVACYPASS-ARC]¶

Similarly, the AUTH RESPONSE payload contains:¶

• For 0x0001 or 0x0005: GenericBatchTokenResponse as defined in Section 6.2 of [PRIVACYPASS-BATCHED]¶

• For 0xE5AC: CredentialResponse as defined in Section 7.2 of [PRIVACYPASS-ARC]¶

3.2.1. Token Challenge Structure for MoQ

MoQ-specific TokenChallenge structures use the default format defined in Section 2.1 of [RFC9577] with MoQ-specific parameters in the origin_info field, reproduced thereafter for convenience:¶

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;

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 [ARC], 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 Section 2.1.1.2 of [RFC9577], 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.¶

3.2.2. MoQ Actions

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

The default authorization policy is "blocked" - all actions are denied unless explicitly permitted by a token scope.¶

MoQAction wire representation is as follows¶

enum {
    CLIENT_SETUP(0),
    SERVER_SETUP(1),
    PUBLISH_NAMESPACE(2),
    SUBSCRIBE_NAMESPACE(3),
    SUBSCRIBE(4),
    REQUEST_UPDATE(5),
    PUBLISH(6),
    FETCH(7),
    TRACK_STATUS(8),
    (255)
} MoQAction;

3.2.3. Match Types

Match rules for namespaces and track names support the following types:¶

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 Section 3.2.4) 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¶

enum {
    MATCH_EXACT(0),
    MATCH_PREFIX(1),
    MATCH_SUFFIX(2),
    MATCH_CONTAINS(3),
    (255)
} MatchType;

3.2.4. Authorization Scope Structure (origin_info)

When authorization scope is bound at issuance time, the origin_info field contains a binary-encoded MoQAuthorizationInfo structure:¶

struct {
    opaque element<0..2^16-1>;
} 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.¶

3.2.5. Examples

The following examples illustrate authorization scope configurations:¶

Subscribe to live sports namespace (prefix match):¶

MoQAuthScope {
    actions = [SUBSCRIBE(4)],
    namespace_match = {
        match_type = MATCH_PREFIX(1),
        value = ["sports.example.com", "live"]
    },
    track_name_match = {
        match_type = MATCH_PREFIX(1),
        value = ""
    }
}

This matches namespace tuples like ["sports.example.com", "live", "soccer"] and ["sports.example.com", "live", "tennis", "finals"].¶

Publish to specific meeting track (exact match):¶

MoQAuthScope {
    actions = [PUBLISH(6)],
    namespace_match = {
        match_type = MATCH_EXACT(0),
        value = ["meetings.example.com", "meeting", "m123"]
    },
    track_name_match = {
        match_type = MATCH_PREFIX(1),
        value = "audio-"
    }
}

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:¶

MoQAuthScope {
    actions = [FETCH(7)],
    namespace_match = {
        match_type = MATCH_CONTAINS(3),
        value = ["vod", "movies"]
    },
    track_name_match = {
        match_type = MATCH_SUFFIX(2),
        value = ".mp4"
    }
}

This matches namespace tuples containing the contiguous subsequence ["vod", "movies"], such as ["example.com", "vod", "movies", "action"].¶

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

3.3.2. 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. Token Extraction: Extract the Privacy Pass token from the MoQ control message (SETUP, SUBSCRIBE, FETCH, PUBLISH, PUBLISH_NAMESPACE, or other operation).¶

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

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

4. Scope Extraction: Extract authorization scope from the token:¶

   • If using origin_info: Decode the MoQAuthorizationInfo structure¶

5. Scope Evaluation: For each MoQAuthScope in the token, check if the requested operation is authorized:¶

   a. Action Check: Verify the requested MoQ action (from Section 3.2.2) 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 Section 3.2.3¶

   c. Track Name Match: Apply the track_name_match rule to the requested track name using the algorithm in Section 3.2.3¶

   d. If all three checks pass, authorization succeeds for this scope¶

6. 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 Section 3.5.5.¶

3.4.1. AUTH CHALLENGE Parameter

The AUTH CHALLENGE parameter is a length-prefixed Message Parameter, with a Setup Option counterpart of identical encoding:¶

Auth Challenge {
  Token Type (vi64),
  Challenge (..)
}

• Token Type: a codepoint from the "MOQT Auth Token Type" registry of [MoQ-TRANSPORT], 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 Message Parameter can appear in REQUEST_ERROR and in successful responses (REQUEST_OK, SUBSCRIBE_OK, FETCH_OK). The Setup Option can appear in SERVER_SETUP.¶

For this document, the Token Type is PRIVACY_PASS_TOKEN (Section 6.1) and the Challenge is a TokenChallenge as defined in Section 2.1 of [RFC9577].¶

3.4.2. 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 {
  Token Type (vi64),
  Request Payload (..)
}

Auth Response {
  Token Type (vi64),
  Response Payload (..)
}

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

For this document, the Token Type is PRIVACY_PASS_TOKEN and the payloads are the issuance structures listed in Section 2.2.3.¶

3.5.1. SETUP Message Authorization

For connection-level authorization, the client includes an AUTHORIZATION TOKEN Setup Option (Section 9.3.1.5 of [MoQ-TRANSPORT]) 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 (Section 2.2), it adds an AUTH REQUEST option (Section 3.4.2); the relay answers with an AUTH RESPONSE option in SERVER_SETUP.¶

CLIENT_SETUP {
    Setup Options = [
        AUTHORIZATION TOKEN {
            Token Type = PRIVACY_PASS_TOKEN,
            Token Value = Token
        },
        AUTH REQUEST {          /* optional, reverse flow */
            Token Type = PRIVACY_PASS_TOKEN,
            Request Payload = GenericBatchTokenRequest
        }
    ]
}

SERVER_SETUP {
    Setup Options = [
        AUTH RESPONSE {         /* only answering an AUTH REQUEST */
            Token Type = PRIVACY_PASS_TOKEN,
            Response Payload = GenericBatchTokenResponse
        }
    ]
}

The Token structure is prepended by a two-byte token type identifier as registered with IANA:¶

struct {
   uint16_t token_type; /* From the IANA Privacy Pass Token Types Registry */
   select (token_type) { /* Rest of the token */
     case (0x0001, 0x0002, 0x0005):
         uint8_t nonce[32];
         uint8_t challenge_digest[32];
         uint8_t token_key_id[Nid];
         uint8_t authenticator[Nk];
     case (other): /* Other token types from the IANA Privacy Pass Token Types Registry */
         opaque remainder<0..2^16-1>;
   }
} Token;

Where Nk is determined by token_type per the [PRIVACYPASS-IANA].¶

Unknown token types MUST be rejected.¶

3.5.2. MoQ Operation-Level Authorization

For individual MoQ operation authorization, tokens are included in operation-specific control messages:¶

SUBSCRIBE {
    Track_Namespace = "sports.example.com/live/soccer",
    Track_Name = "video",
    Parameters = [
        AUTHORIZATION TOKEN {
            Token Type = PRIVACY_PASS_TOKEN,
            Token Value = Token
        }
    ]
}

3.5.3. 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 Section 6.1 of [PRIVACYPASS-BATCHED]) in an AUTH REQUEST option. Each token in the batch is independently valid and can be presented for subsequent operations or periodic re-authorization.¶

Batched Token Usage Timeline:

Time 0:     CLIENT_SETUP with Token_1, request batch of N tokens
            SERVER_SETUP with batch of N tokens

Time T:     SUBSCRIBE with Token_2 (from batch)

Time 2T:    Client presents Token_3 for continued authorization
            (proactive re-auth before relay requests it)

Time 3T:    Relay requests re-authorization
            Client presents Token_4

Relays MAY request periodic re-authorization by attaching an AUTH CHALLENGE parameter to a REQUEST_ERROR, or ahead of time to a successful response alongside the EXPIRES parameter of [MoQ-TRANSPORT], 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 [ARC] 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¶

3.5.4. 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 [MoQ-TRANSPORT]: 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 without linkability.¶

Reverse Flow Token Usage Timeline:

Time 0:     CLIENT_SETUP with Token_1 + AUTH REQUEST for 1 token
            SERVER_SETUP with AUTH RESPONSE (1 token)

Time T:     SUBSCRIBE with Token_2 + AUTH REQUEST for 1 token
            SUBSCRIBE_OK with AUTH RESPONSE (1 token)

Time 2T:    REQUEST_UPDATE with Token_3 + AUTH REQUEST for 1 token
            REQUEST_OK with AUTH RESPONSE (1 token)

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

REQUEST_ERROR {
    Request_ID = 42,
    Error_Code = 0x0104,  /* SCOPE_MISMATCH */
    Retry_Interval = 1,
    Reason = "token scope does not cover this namespace",
    Parameters = [
        AUTH_CHALLENGE {
            token_type = PRIVACY_PASS_TOKEN,
            challenge = TokenChallenge {
                token_type = 0x0002,
                issuer_name = "public-issuer.example.com",
                redemption_context = <32 random bytes>,
                origin_info = <authorization scope>
            }
        },
        AUTH_CHALLENGE {
            token_type = PRIVACY_PASS_TOKEN,
            challenge = TokenChallenge {
                token_type = 0xE5AC,
                issuer_name = "relay.example.com",
                redemption_context = <32 random bytes>,
                origin_info = <authorization scope>
            }
        },
        AUTH_CHALLENGE {
            token_type = PRIVACY_PASS_TOKEN,
            challenge = TokenChallenge {
                token_type = 0x0001,
                issuer_name = "relay.example.com",
                redemption_context = <32 random bytes>,
                origin_info = <authorization scope>
            }
        }
    ]
}