MoLE Protocols

4.4.1. Configuration

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

Rollatini Ciphersuite

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

Anchor Public Key

pkA, an Element, as generated in [ROLLATINI], with a stable key ID.¶

Issuance Context

ctx_iss, the canonical encoding of the issuance epoch. Endorsements are valid for that epoch, see Section 6.¶

Redemption Context

ctx_red, the ASCII string "MoLE-Rollatini-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 [ROLLATINI], not a Moderator Challenge. A specific redemption operation is bound separately by challenge_digest.¶

4.4.2. Grant

The grant takes two HTTP exchanges and three protocol messages. The Anchor speaks first, as specified by [ROLLATINI]:¶

1. The Client sends an EndorsementRequest with an empty body. The Anchor runs Commit(ctx_iss), stores the returned state under a fresh session_id, and returns a CommitMessage in the response body.¶

2. The Client runs Challenge(pkA, ctx_iss, ctx_red, commitment), stores the returned state, and sends a ChallengeMessage containing the returned issuance challenge and opaque session_id. The Anchor atomically claims and consumes that identifier before reading the single-use state. Only the instance that wins the claim runs Respond(skA, state, challenge) and returns a ResponseMessage. Tombstones are retained through session expiry. All later requests for the identifier fail without invoking Respond.¶

3. The Client runs Finalize(pkA, state, response) as specified by [ROLLATINI]. On failure it MUST discard the session state and MUST NOT retry with that state.¶

CommitMessage, ChallengeMessage, ResponseMessage, session_id, and the Endorsement encoding are defined by [ROLLATINI]. The session identifier is only transport correlation and is not bound into the Endorsement.¶

The Anchor learns neither nf nor the final Endorsement. Under the statistical blindness claim in [ROLLATINI], 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 [ROLLATINI]. RedeemRequest derives challenge_digest as in Section 4.1 and calls Redeem(anchor_set, index, endorsement, ctx_iss, ctx_red, challenge_digest). The ordered anchor_set comes from Moderator configuration; index selects the Anchor that issued the Endorsement. The Client rejects a set that omits its Anchor.¶

FinalizeRedeem checks that the issuance epoch and Moderator Challenge are accepted, decodes the payload, and calls VerifyRedemption(anchor_set, redemption, ctx_iss, ctx_red, challenge_digest). It returns {nf}, scoped to ctx_iss in the Moderator's store. Any decoding or verification failure returns INVALID. 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 accepted issuer set, circuit artifact, epoch, Moderator origin, and verification time come from authenticated configuration. The selected redemption operation supplies the digest of the complete decoded ModeratorChallenge as challenge_digest, as defined in Section 4.1.¶

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 Rollatini

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 prevents repeat redemption of one credential in that scope. It 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 ACT ciphersuite identifier; [ACT] defines P256-SHA256.¶

Balance Width

L, fixed for the lifetime of the key and credential context ([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 [ACT] is¶

ctx_cred = credential_context || I2OSP(L, 1)

which includes L as [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 [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.¶

The Endorsement is therefore consumed only together with a response, and a malformed request does not cost the Client its 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 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 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 ([ACT]). Besides the spend state that [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. It returns the recovered result with HTTP status 409 as 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 ([ACT]). With P-256 and L = 32, it is about 4.5 KB when one of s and a is nonzero and 8.7 KB when both 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]. Privacy Pass names its cryptographic Context TokenChallenge. In MoLE, the type-specific body of CredentialChallenge carries that configured TokenChallenge. It is therefore both sent by the Moderator as part of a Challenge and supplied to the Privacy Pass replacement-issuance and verification operations as their Context. Initial issuance obtains the same TokenChallenge from authenticated configuration.¶

TokenChallenge is fixed when the token is issued. It MUST be stable for every Client using the same configured credential type, key, and epoch, and MUST NOT contain a per-Client or per-request value. This is necessary because a replacement token is issued before the operation in which it will be presented. The Privacy Pass Token.challenge_digest field MUST equal SHA-256 over the encoded configured TokenChallenge. It is distinct from the MoLE endorsement challenge_digest defined in Section 4.1. The Moderator MUST reject a token carrying any other digest. Replay protection comes from token single use. The Moderator MUST verify the token as specified by [PRIVACYPASS-AUTH] against the configured token type, key, and TokenChallenge, then atomically record its nonce before accepting it. An invalid or previously recorded nonce is rejected, except for the retry behavior below. Holder binding remains an open limitation below.¶

If the Moderator's policy allows continued access, it returns an Update. If not, it returns no update and the Client is out of credentials.¶

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 MUST return the same accepted result while it retains the idempotency record, including the same Update or the same absence of an update. It MUST reject the replay after that record expires and MUST NOT issue a second Credential. The Client MUST NOT combine the same presented Credential with a different update request. These requirements are the retry semantics of [REVERSE-FLOW].¶

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

5.3.4. Limitations

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

• Value: 0x0002¶

• Name: Rollatini¶

• 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. ACT

• Value: 0x0001¶

• Name: 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).¶