MoLE Protocols

4.4.1. Configuration

The Client needs, from Anchor configuration (Section 6):¶

EC-IHAT Ciphersuite

A ciphersuite identifier defined by [EC-IHAT]. It determines Element, Scalar, and all cryptographic encodings.¶

Anchor Public Key

pkA, an Element, as generated in [EC-IHAT]. An Anchor has one key per grant endpoint.¶

Issuance Context

ctx_iss, the issuance epoch the Anchor currently issues under. It is an opaque byte string. Endorsements are valid for that epoch, see Section 6.¶

Redemption Context

ctx_red, the ASCII string "MoLE-EC-IHAT-ctx_red-v1", without a terminating NUL byte. This fixed, domain-separated value is the same for all Moderators. This is the cryptographic redemption Context defined by [EC-IHAT], not a Moderator Challenge. A specific redemption operation is bound separately by challenge_digest.¶

4.4.2. Grant

A grant issues a batch of one or more Endorsements under the same pkA and ctx_iss. It takes two HTTP exchanges and four messages. Each Endorsement in the batch is the output of its own EC-IHAT issuance session ([EC-IHAT]); the batch carries the messages of all its sessions together, and a single session_id correlates them:¶

struct {
  uint16 count;
} GrantRequest;

struct {
  opaque session_id[32];
  CommitMessage commitments<V>;
} GrantCommitments;

struct {
  opaque session_id[32];
  ChallengeMessage challenges<V>;
} GrantChallenges;

struct {
  ResponseMessage responses<V>;
} GrantResponses;

CommitMessage, ChallengeMessage, ResponseMessage, and the Endorsement encoding are defined by [EC-IHAT]. The i-th entry of GrantChallenges answers the i-th entry of GrantCommitments, and the i-th entry of GrantResponses answers the i-th entry of GrantChallenges.¶

The grant proceeds as follows. The Anchor speaks first, as specified by [EC-IHAT]:¶

1. The Client sends a grant POST with a GrantRequest, in which count, at least 1, is the number of Endorsements it asks for. The Anchor rejects a count of zero. It chooses a number n of Endorsements to grant under its policy, with 1 <= n <= count, and rejects the request if it grants none. It runs Commit(ctx_iss) n times, stores the n returned states together under a fresh session_id, and returns a GrantCommitments carrying session_id and the n commitments in order.¶

2. The Client rejects a GrantCommitments with more than count commitments. For each commitment it runs Challenge(pkA, ctx_iss, ctx_red, commitment), and it stores the returned states in order. It sends a GrantChallenges carrying the opaque session_id and the returned issuance challenges in the same order. The Anchor atomically claims and consumes that identifier before reading the single-use states. Only the instance that wins the claim proceeds. It rejects the request if the number of challenges differs from the number of states. Otherwise it runs Respond(skA, state, challenge) for each pair and returns the responses in a GrantResponses. If any Respond fails, the Anchor discards every state of the batch and returns no response. Tombstones are retained through session expiry. All later requests for the identifier fail without invoking Respond.¶

3. The Client rejects a GrantResponses whose number of responses differs from the number of challenges it sent. It runs Finalize(pkA, state, response) for each pair as specified by [EC-IHAT]. If Finalize fails for any session, the grant fails: the Client MUST discard the state of every session in the batch and every Endorsement finalized from it, and MUST NOT retry with that state. If the second response is lost, the Client starts a fresh grant.¶

The Anchor MUST generate session_id with a cryptographically secure random number generator, so that a Client cannot guess, and so collide with, another Client's batch, and MUST NOT have two open batches with the same session_id. A GrantChallenges whose session_id does not name an open batch is rejected.¶

Batching does not change the cryptographic guarantees. The sessions of a batch are concurrent sessions in the sense of [EC-IHAT], whose one-more unforgeability holds under concurrency: a Client that completes a batch of n sessions obtains at most n Endorsements. Each session is blinded independently, so the Anchor cannot link an Endorsement to the batch that produced it, nor to its position in that batch. The Anchor does learn count and n. An Anchor counts every granted session against the Client's budget ([ARCHITECTURE]).¶

The Anchor learns neither nf nor the final Endorsement. Under the statistical blindness claim in [EC-IHAT], its protocol transcript does not let it recognize the Endorsement when it is later redeemed. Timing, network, and configuration metadata are outside that claim.¶

4.4.3. Redemption

The type-specific Redemption payload is the encoding of Redemption in [EC-IHAT]. RedeemRequest derives challenge_digest as in Section 4.1 and calls Redeem(anchor_set, index, endorsement, ctx_iss, ctx_red, challenge_digest). The Client uses the Moderator's accepted Anchor set for the ctx_iss its Endorsement was issued under (Section 6). index is the position of the entry whose key equals the issuing pkA. The Client fails if no set has that ctx_iss or the set omits its Anchor.¶

The Redemption does not carry ctx_iss. FinalizeRedeem checks that the Moderator Challenge is accepted. Then, for each accepted Anchor set until one succeeds, it decodes the payload against that set, since the decoding depends on its size, and calls VerifyRedemption(anchor_set, redemption, ctx_iss, ctx_red, challenge_digest). It returns {nf}, scoped to the matching ctx_iss in the Moderator's store, or INVALID if decoding or verification fails under every set. The common replay protection rules apply before Credential issuance. The same nf is exposed on repeated redemptions, including across Moderators; the scheme does not enforce global single use.¶

4.5.1. Configuration

The Client needs, from Moderator configuration (Section 6):¶

Circuit Artifact Identifier

circuit_artifact_id, the SHA-256 hash of the compressed circuit artifact both parties use.¶

Circuit Manifest

An out-of-band manifest that names the artifact version, the two circuit identifiers, and all proof parameters needed to interpret and verify it.¶

Accepted Issuer Set

the credential-issuer certificates the Moderator accepts, in a fixed published order.¶

Epoch

the validity window redemptions must fall in.¶

Moderator Origin

the canonical origin of the Moderator. Its source is trusted configuration. It MUST NOT be derived from a client-controlled HTTP Host value.¶

Verification Time

verification_time, a Moderator-selected time within the current epoch.¶

4.5.2. Redemption

The Client evaluates the two circuits over its credential to produce a proof and a nullifier. The nullifier is derived, inside the circuit, from a credential-bound secret, the canonical Moderator origin, and the current epoch. One credential therefore yields exactly one valid nullifier per Moderator origin and epoch.¶

struct {
  opaque circuit_artifact_id[32];
  opaque nullifier<V>;
  opaque proof<V>;
} Redemption;

The structure fields are:¶

• circuit_artifact_id is the SHA-256 digest of the configured circuit artifact.¶

• nullifier is the circuit-produced replay protection identifier.¶

• proof is the encoded Longfellow proof.¶

The circuit public inputs are the accepted issuer set, epoch, canonical Moderator origin, verification_time, and nullifier. The proof establishes validFrom <= verification_time <= validUntil. challenge_digest (Section 4.1) is bound into the Longfellow Fiat-Shamir transcript. It is not a circuit public input.¶

Longfellow implements the common API in Section 4. RedeemRequest checks that the artifact and manifest match configuration, evaluates the circuits, and returns the encoded Redemption above. FinalizeRedeem checks the artifact identifier, verifies the proof and its transcript binding, and checks that the configured epoch and verification_time remain current. It returns {nullifier}, or INVALID on any failure. Both operations derive challenge_digest from moderator_challenge. The common caller performs the atomic replay protection check.¶

4.5.3. Differences from EC-IHAT

Longfellow does not inherently require an Anchor to change its issuance protocol. Scarcity then depends on the legacy credential's own issuance limits and on whether it contains a credential-bound Client secret suitable for nullifier derivation. An Anchor that participates in MoLE can control scarcity and arrange for such a secret to be committed during issuance. Some existing credential formats may already provide a suitable Client-contributed or device-bound secret. The one-nullifier-per-origin-and-epoch rule lets the Moderator prevent repeat redemption within its replay protection scope. The legacy credential remains usable at other Moderator origins and in later epochs. This does not limit how many credentials a Client can obtain.¶

• Editor note. This protocol is blocked on normative circuit definitions, public-input encodings and ordering, transcript binding, artifact lifecycle and size limits, and test vectors.¶

5.2.1. Configuration

The Moderator publishes, in its configuration (Section 6):¶

Public Key

pkM, encoded with SerializeElement. Its identifier is key_id = SHA-256(SerializeElement(pkM)), and truncated_key_id is the last byte of key_id.¶

Ciphersuite

The EC-ACT ciphersuite identifier; [EC-ACT] defines P256-SHA256.¶

Balance Width

L, fixed for the lifetime of the key and credential context ([EC-ACT]).¶

Credential Context

credential_context, an opaque byte string of at most 2^16 - 2 bytes that names the epoch or policy that Credentials under the key are valid for.¶

Result Retention Period

The recovery interval after acceptance of a presentation. Recovery ends earlier if its key or credential context is retired (Section 5.2.5).¶

The credential context of [EC-ACT] is¶

ctx_cred = credential_context || I2OSP(L, 1)

which includes L as [EC-ACT] recommends. A Moderator expires every outstanding Credential under a key by publishing a new credential_context, without changing the key. A refund is issued under the context of the spent Credential, so balances do not carry over to a new context. A Moderator SHOULD announce the successor context and a grace period before expiry. Clients obtain Credentials under the new context through Redeem & Issue; this document does not specify balance migration.¶

A Moderator MAY have several active keys, for instance during a rotation. It MUST ensure that no two active keys share a truncated_key_id, SHOULD NOT give a new key the truncated_key_id of a recently retired one, and SHOULD keep the number of active keys small (Section 7.1).¶

5.2.2. Redeem & Issue

struct {
  uint8 truncated_key_id;
  opaque credential_context<V>;
  IssueRequestMessage request;
} IssuanceRequest;

struct {
  IssueResponseMessage response;
} IssuanceResponse;

IssueRequestMessage and IssueResponseMessage are defined in [EC-ACT].¶

The Client runs IssueRequest(), keeps the returned state, and sends the request with the truncated identifier of the key and the credential_context it holds in its configuration.¶

The Moderator processes a CredentialRequest in this order:¶

1. It selects the active key whose truncated_key_id matches, and checks that credential_context is the context it issues under for that key. It rejects the request if either check fails.¶

2. It checks that request deserializes and that its proof verifies, as IssueResponse does, and rejects the request otherwise.¶

3. It validates the accompanying redemption with FinalizeRedeem (Section 4).¶

4. It chooses the initial balance c under its policy and runs IssueResponse(skM, ctx_cred, c, request). It then records the replay_protection_ids returned by FinalizeRedeem. Recording is atomic and fails if any identifier is already recorded. If any step fails, or it is unknown whether the identifiers were recorded, no response is released.¶

5. It returns the result in a CredentialResponse.¶

A request rejected before recording does not cost the Client its Endorsement. A response lost after recording cannot be recovered, and the Client needs a new Endorsement.¶

The Client runs FinalizeIssue(pkM, ctx_cred, state, response) and stores the resulting Credential with pkM, credential_context, L, the identity of the Moderator, and its configured Redeem & Issue endpoint. If finalization fails, the Client MUST discard the state, SHOULD refresh its configuration, and MAY run Redeem & Issue again.¶

5.2.3. Presentation and Update

The EC-ACT Challenge names the amounts, the context the Moderator accepts, and the scope of the authorization it asks for:¶

struct {
  uint64 s;
  uint64 a;
  opaque credential_context<V>;
  opaque request_context<V>;
} Challenge;

s is the amount to spend and is the Predicate of [ARCHITECTURE]: a presentation succeeds only if the balance is at least s. a is the largest top-up the Moderator offers in this presentation, 0 if none. A challenge with s = a = 0 asks for a refresh, which replaces the nullifier and leaves the balance unchanged, since t <= s + a = 0. A Moderator that wants to lower balances challenges with s > 0 and returns t < s; one that wants to raise them offers a > 0. credential_context repeats the configured value, so that a Client can tell that its Credential has expired without refetching the configuration. It is the challenge field that partitions cached Credentials ([HTTP-TRANSPORT]).¶

ctx_spend = SHA-256(credential_challenge)

struct {
  opaque key_id[32];
  SpendMessage spend;
} PresentationAndUpdate;

struct {
  RefundMessage refund;
} Update;

5.2.4. Client State

An EC-ACT Credential goes through the following states:¶

Usable:

The Client holds a Credential with balance c, together with pkM, credential_context, and L, and may present it as Section 5.2.3.2 describes.¶

Spent:

The Client has run ProveSpend, and the Credential is invalid whether or not the presentation is sent or answered ([EC-ACT]). Besides the spend state that [EC-ACT] requires it to store, the Client MUST durably store the presentation octets and the HTTP request needed to resend them before the presentation leaves it.¶

A valid refund returns the Client to Usable. A Credential chain is therefore serialized: one presentation at a time, each waiting for the Moderator's answer to the previous one. When a Client learns that a key or credential context has been retired, it MUST discard the Credentials and pending spend states under that key or context. It obtains a Credential under the current configuration through Redeem & Issue.¶

5.2.5. Lost Refunds

A presentation may be sent and its response lost, or the Moderator may fail between recording the result in step 3 of Section 5.2.3.2 and returning it. The Client cannot then finalize, and the spent Credential cannot be reused.¶

A Moderator MUST keep each result until the earlier of the end of its published result retention period (Section 5.2.1), counted from the recording in step 3, and retirement of the key or credential context. It MUST delete the result when this interval ends. A Client missing an Update MAY resend the byte-identical PresentationAndUpdate during the interval. Step 1 of Section 5.2.3.2 checks the record and the continued acceptance of its key and credential context before returning a result. Recovery remains available after the presentation's challenge expires:¶

• For a recorded Refund(t), the Moderator returns the refund it stored.¶

• For a recorded NoUpdate, the Moderator returns an absent update.¶

The recovery handle ([HTTP-TRANSPORT]) is key_id || SerializeScalar(spend.k) || SHA-256(PresentationAndUpdate).¶

The Moderator MUST NOT authorize another operation for a recorded nullifier, and MUST NOT change a recorded decision. HTTP status codes for recovery and retries are specified in [HTTP-TRANSPORT].¶

Once recovery ends, a retry is rejected, and the Client MUST discard the spend state. To continue, it runs Redeem & Issue. The Moderator MUST retain the nullifier after deleting its result for as long as the key and credential context are accepted (Section 6).¶

5.2.6. Limitations

A SpendMessage grows linearly in L ([EC-ACT]). With P-256 and L = 32, it is at most 4,531 bytes (about 4.5 KB) when s + a > 0, including when both amounts are nonzero, and 468 bytes for a refresh (s = a = 0). These sizes exclude the 32-byte key_id added by PresentationAndUpdate and are before base64url encoding in the Authorization header. Deployments with tight header limits should choose L accordingly.¶

5.3.1. Redeem & Issue

IssuanceRequest is a TokenRequest and IssuanceResponse is a TokenResponse, both as defined for the configured token type in [PRIVACYPASS-PROTOCOLS]. That token type's finalization operation produces the Credential. These messages implement CreateIssuanceRequest, IssueCredential, and FinalizeIssuance.¶

5.3.2. Presentation and Update

struct {
  opaque token<V>;
  opaque token_request<V>;  /* TokenRequest */
} PresentationAndUpdate;

struct {
  opaque token_response<V>; /* TokenResponse */
} Update;

The structure fields are:¶

• token is the presented Privacy Pass Token.¶

• token_request is the encoded replacement TokenRequest.¶

• token_response is the encoded replacement TokenResponse.¶

These structures implement CreatePresentationAndUpdate, ProcessPresentation, and FinalizeUpdate.¶

The token field carries a Token as defined in [PRIVACYPASS-AUTH]. Each configured token key has its own TokenChallenge (Section 6). A token is verified against the TokenChallenge of the key it was issued under. Initial issuance and replacements use the TokenChallenge of the issuance key.¶

The type-specific body of CredentialChallenge is the issuance key's TokenChallenge. A Client MUST reject a CredentialChallenge whose TokenChallenge differs from it. The Client presents a token issued under any accepted key, and builds token_request under the issuance key.¶

TokenChallenge is fixed when the token is issued, before the operation in which it is presented. It MUST be the same for every Client using a given configuration, and MUST NOT contain a per-Client or per-request value. The Client checks agreement with its configuration, not consistency across Clients (Section 7). Token.challenge_digest is SHA-256 over the encoded TokenChallenge. It is distinct from the endorsement challenge_digest of Section 4.1.¶

The Moderator processes a presentation as follows:¶

1. It looks up (token.token_key_id, token.nonce) in its record store. If a record exists, it returns the recorded result with fresh false, only if the record holds the SHA-256 digest of the received PresentationAndUpdate octets and is still retained. Otherwise it rejects the presentation. Only an unrecorded nonce proceeds to step 2.¶

2. It verifies the token as specified by [PRIVACYPASS-AUTH] against the accepted key matching token.token_type and token.token_key_id, and that key's TokenChallenge, including Token.challenge_digest. It rejects the presentation if verification fails.¶

3. It decides under its policy whether to issue an update and, if so, runs the issuance of the configured issuance token type on token_request.¶

4. It atomically records under (token.token_key_id, token.nonce) the digest of the PresentationAndUpdate octets and the result: the Update, or no update. Recording MUST fail if a record exists. If any step fails, or it is unknown whether the result was recorded, no update is released and the protected operation MUST NOT be attempted.¶

5. It returns the recorded result with fresh true and attempts the protected operation.¶

5.3.3. Retry after a lost response

A Client that receives no response MAY retry the byte-identical PresentationAndUpdate only to recover from that loss. The Moderator retains each result for the result-retention period in its configuration, then keeps the nonce without the result while the token key is accepted. It MUST NOT issue a second Credential for a recorded nonce. The Client MUST NOT combine the same presented Credential with a different update request. These requirements are the retry semantics of [REVERSE-FLOW].¶

If concurrent presentations race to record the nonce, only the winner returns fresh true. A loser returns the retained result with fresh false only if the recorded presentation digest matches. Otherwise it rejects the request. Once the result expires, the retained nonce still prevents another acceptance.¶

The recovery handle ([HTTP-TRANSPORT]) is token.token_key_id || token.nonce || SHA-256(PresentationAndUpdate).¶

5.3.4. Limitations

The presented token is a bearer credential. Its verification does not prove that the replacement token_request belongs to the same holder. A holder can therefore supply another party's replacement request. Replay protection limits acceptance of the presented token within its scope. It does not prevent this transfer or establish that a Client holds only one token. The fixed TokenChallenge also does not bind presentation to a particular HTTP request.¶

TODO: define a device binding mechanism, issuing tokens bound to a Client key so that presentation requires proof of possession. This would restore the binding between update and presented credential. Open problem.¶

9.1.1. EC-IHAT

• Value: 0x0002¶

• Name: EC-IHAT¶

• Exchanges: 2¶

• Publicly Verifiable: Yes¶

• Reference: Section 4.4¶

9.1.2. Longfellow

• Value: 0x0003¶

• Name: Longfellow¶

• Exchanges: none (out of band)¶

• Publicly Verifiable: Yes¶

• Reference: Section 4.5¶

9.2.1. EC-ACT

• Value: 0x0001¶

• Name: EC-ACT¶

• Bound Update: Yes¶

• Reference: Section 5.2¶

9.2.2. Privacy Pass Reverse Flow

• Value: 0x0002¶

• Name: Privacy Pass Reverse Flow¶

• Bound Update: No¶

• Reference: Section 5.3¶

9.2.3. Greased Values

• Value: 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A, 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, 0xFAFA¶

• Name: RESERVED¶

• Bound Update: N/A¶

• Reference: Section 3.2¶

These values MUST NOT be assigned. Message bodies carrying them contain random bytes (Section 3.2).¶