Private proof,
scarce access.

A service can restrict access without learning a permanent customer identifier from every proof of eligibility. Digital scarcity then becomes a question about the information needed to enforce a limit, as well as the limit itself.

Consider a customer entitled to a limited number of requests from a digital service. The provider needs confidence that each request is authorised. The customer may have a reason to keep the pattern of use separate from the account through which eligibility was established. A design that exposes the whole relationship at every interaction can collect more information than the access decision requires.

The IETF’s Privacy Pass specifications give this problem a concrete technical form. They describe privacy-preserving authorisation tokens and the conditions under which different interactions remain unlinkable. Reading those mechanisms alongside institutional economics reveals a useful design question: how much personal information must a scarce entitlement carry, and which organisations control the answer?

Put eligibility at a different point

The Privacy Pass architecture, RFC 9576, distinguishes four roles: a client seeking access, an attester checking eligibility, an issuer creating tokens and an origin deciding whether to accept them.

An attester might establish that an account is valid without the origin receiving those credentials. The checked property and trust relationships still need specification. A valid token does not, by itself, establish that its holder is a unique person, has paid a particular price or owns a transferable asset.

Let a hidden request receive a verifiable answer

RFC 9578 specifies a publicly verifiable issuance protocol using blind RSA signatures. The client blinds its input, the issuer processes that blinded request, and the client finalises a token that can be checked using the issuer’s public key. The standard also defines a privately verifiable protocol using an oblivious pseudorandom function; the two verification arrangements should be evaluated separately.

The underlying RSA blind-signature specification, RFC 9474, explains two distinct security properties. Blindness protects the client’s input from the signer under the applicable variant’s conditions. One-more-forgery security limits the ability to manufacture additional valid signed messages beyond the signing interactions obtained. Its security statement rests on specified cryptographic assumptions and a stated model.

These properties support different parts of the economic arrangement. Hiding the input can protect the relationship between issuance and use. Preventing extra forgery can protect the issuing boundary. The issuer still chooses how many legitimate requests to honour. Cryptographic protection cannot supply a restrictive business policy that the operator has never adopted.

Scarcity begins with a rule about supply

Suppose, as a hypothetical application, an information service sells an allowance of ten retrievals. Eligibility checking could occur when the allowance is acquired, while later retrievals use separately issued tokens. This is a proposed commercial design, not a claim that Privacy Pass implements payment, a ten-use allowance or a complete account system.

The operator would have to define what one retrieval buys, constrain aggregate issuance to the purchased allowance, and prevent a replacement process from silently creating extra usable allowances. It would also have to decide what happens to unused access when terms change. Those are consequential rules even if every token signature is correct.

A rule limiting issuance and a rule governing consumption answer different questions. RFC 9577 recognises settings where replay is acceptable and recommends anti-replay protection when redemption has side effects. An application selling a consumable allowance must make its own required use limit effective. The earlier article, The second redemption, examines that consumption boundary in detail.

RFC 9576 also notes that tokens can be shared: they are not intrinsically bound to the original client. An aggregate allowance therefore does not establish a per-person use limit. Privacy-preserving authorisation can be an ingredient of scarce access. The scarce object remains the service entitlement defined and enforced by the complete arrangement. Possessing a token does not settle its transferability, the provider’s obligations or the treatment of a disputed request.

Count the traces as well as the tokens

RFC 9576’s privacy model includes the information revealed during attestation, issuance and redemption. IP addresses and other distinguishing context can reduce a client’s anonymity set. Separating roles on a diagram does not establish that their operators cannot correlate observations.

Challenge design creates another trade-off. RFC 9577’s timing analysis explains that a fresh context can make issuance and redemption occur close together, enabling correlation when the surrounding events are distinctive. Its origin-behaviour guidance also notes that unique contexts prevent use of cached tokens and can add delay. The same specification discusses excessive challenges that exhaust a client’s available tokens or issuance capacity.

For the hypothetical retrieval service, the evaluation therefore needs more than a successful signature check. It should ask what an observer learns from request timing, network information, the chosen issuer and the service’s other identifiers. An account cookie attached to each retrieval could reveal the relationship that a blinded token was intended to protect. The token mechanism must be assessed inside the actual application.

Locate the authority behind the allowance

My published paper, Beyond ‘permissionless’: governance, commitment, and rule change in public blockchains, separates open admission from authority over rule changes. Its comparative institutional analysis examines how participants become exposed when they make protocol-specific investments and other actors retain discretion to revise the conditions on which those investments depend.

That distinction supplies an institutional analogy here. A token may remain cryptographically valid while a service changes which issuers it accepts, what a retrieval includes or which clients can obtain replacements. A customer planning around an allowance, or a developer integrating an issuer, needs to understand who can make those changes and what constrains them.

The blockchain paper does not establish the performance or governance of Privacy Pass deployments. Applying its question to this setting suggests an explicit assessment: map issuance, acceptance and change authority; identify the commitments made to users; and examine what users retain if an intermediary withdraws. Privacy and reliable access can both depend on these decisions.

Price the complete exchange

For a small digital purchase, obtaining and presenting proof can consume a meaningful share of the transaction’s value. The relevant cost includes service delivery, eligibility checks, issuance, verification, failure handling and the customer’s time. Information collected along the way also affects the product: some customers may value a service differently when their sequence of uses is linked to an account.

This creates a testable commercial proposition, rather than an automatic saving. Compare an account-linked design and a privacy-preserving design for the same entitlement, workload and abuse target. Measure completed legitimate requests, wrongful refusals, customer effort, operating cost and the information each party can associate with a user. Include clients who cannot satisfy a favoured attestation method. An apparently inexpensive design can merely move its burden onto them.

The specifications establish mechanisms and their security requirements. They do not supply an empirical estimate of demand, operating savings or welfare for this hypothetical service. Those outcomes require an implementation and a comparison that keeps the access promise fixed.

The research matters because it makes a familiar design assumption examinable. Scarce access needs a credible issuing and enforcement arrangement; each access decision need not carry every fact used to establish eligibility. Understanding where those facts can be separated, and where practical traces reconnect them, expands the choices available when designing digital commerce.