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 UNAUTHORIZED containing a TokenChallenge specifying a publicly verifiable token type (0x0002).¶

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

   • The publicly verifiable Token from Phase 1¶

   • A CredentialRequest (or TokenRequest) 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:¶

   • A CredentialResponse (or TokenResponse) 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 GenericBatchTokenRequest in ClientPrivateTokenAuth contains the credential or token request for the privately verifiable token type:¶

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

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

Similarly, GenericBatchTokenResponse in ServerPrivateTokenAuth contains:¶

• For 0x0001 or 0x0005: TokenResponse as defined in Section 5.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.4.5.¶

3.4.1. SETUP Message Authorization

For connection-level authorization, Privacy Pass tokens are included in the SETUP message's authorization parameter (Section 9.3.1.5 of [MoQ-TRANSPORT]).¶

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

type PrivateTokenAuth = ClientPrivateTokenAuth | ServerPrivateTokenAuth;

For CLIENT_SETUP, the authorization value uses GenericBatchTokenRequest as defined in Section 6.1 of [PRIVACYPASS-BATCHED] as follows:¶

struct {
    uint8_t auth_scheme = 0x01;
    Token token;
    GenericBatchTokenRequest token_requests;
} ClientPrivateTokenAuth;

For SERVER_SETUP, the authorization value uses GenericBatchTokenResponse as defined in Section 6.2 of [PRIVACYPASS-BATCHED] as follows:¶

struct {
    uint8_t auth_scheme = 0x01;
    Token token;
    GenericBatchTokenResponse token_responses;
} ServerPrivateTokenAuth;

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

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.4.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 = [
        {
            Type = AUTHORIZATION,
            Value = PrivateTokenAuth
        }
    ]
}

3.4.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 via GenericBatchTokenRequest (defined in Section 6.1 of [PRIVACYPASS-BATCHED]). 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 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 [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.4.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, 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.¶

Reverse Flow Token Usage Timeline:

Time 0:     CLIENT_SETUP with Token_1, request batch of 1 token
            SERVER_SETUP with batch of 1 token

Time T:     SUBSCRIBE with Token_2 (from batch), request batch of 1 token
            Relay responds with batch of 1 token

Time 2T:    Client presents Token_3 (from batch of time T), request batch of 1 token
            Relay responds with batch of 1 token

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

struct {
    TokenChallenge challenges<1..2^16-1>;
} MoQAuthChallenge;

REQUEST_ERROR {
    Request_ID = 42,
    Error_Code = 0x0104,  /* SCOPE_MISMATCH */
    Reason = MoQAuthChallenge {
        challenges = [
            TokenChallenge {
                token_type = 0x0002,
                issuer_name = "public-issuer.example.com",
                redemption_context = <32 random bytes>,
                origin_info = <authorization scope>
            },
            TokenChallenge {
                token_type = 0xE5AC,
                issuer_name = "relay.example.com",
                redemption_context = <32 random bytes>,
                origin_info = <authorization scope>
            },
            TokenChallenge {
                token_type = 0x0001,
                issuer_name = "relay.example.com",
                redemption_context = <32 random bytes>,
                origin_info = <authorization scope>
            }
        ]
    }
}