Wiki · Concept · Last reviewed June 25, 2026

Anonymous Rate-Limited Credentials

Anonymous Rate-Limited Credentials are a Privacy Pass work-in-progress approach for letting a client obtain one anonymous credential and later make only a fixed number of unlinkable presentations for a defined context.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Privacy Pass, anonymous credentials, rate limiting, agents, anti-abuse, web governance

Definition

Anonymous Rate-Limited Credentials, usually abbreviated ARC in the Privacy Pass drafts, are a proposed credential pattern for throttling anonymous clients without turning each presentation into a stable identity record. On this page, ARC means Anonymous Rate-Limited Credentials, not the site's abstraction benchmark topic.

The IETF document Privacy Pass Issuance Protocol for Anonymous Rate-Limited Credentials, draft-ietf-privacypass-arc-protocol-01, specifies issuance and redemption protocols for tokens based on the ARC cryptographic protocol. It is an Internet-Draft, not an RFC, and its boilerplate says Internet-Drafts may be updated, replaced, or obsoleted.

The companion draft, Anonymous Rate-Limited Credentials Cryptography, draft-ietf-privacypass-arc-crypto-00, describes ARC as a specialization of keyed-verification anonymous credentials with rate-limiting support. Its goal is a credential that can be presented a fixed number of times while keeping presentations unlinkable from one another and from the original credential creation.

Mechanism

Privacy Pass RFC 9576 defines the broader architecture: clients obtain cryptographic tokens after an attestation step and redeem them with origins so the origin can make an authorization decision without learning unique per-client information through the authentication protocol. RFC 9577 defines the HTTP PrivateToken authentication scheme, and RFC 9578 defines Privacy Pass issuance protocols for privately verifiable and publicly verifiable tokens.

ARC changes the unit of use. Core Privacy Pass tokens are one-time anonymous tokens. The ARC protocol draft says a client can turn a single credential output from an issuance protocol into a fixed number of unlinkable tokens bound to an agreed public presentation context. The TokenChallenge can still be interactive or non-interactive and per-origin or cross-origin, but the draft adds ARC-specific context and a presentation limit.

The cryptography draft describes three phases: server setup, credential issuance, and credential presentation. During presentation, client and server agree on a presentation context and presentation limit. If the client exceeds that agreed limit, the draft says the protocol's unlinkability guarantees are broken. That warning is important: rate limiting and anonymity are coupled, not independent features.

Agent Context

ARC is relevant to agents because anonymous client traffic is becoming a normal web condition rather than an edge case. A browser agent, search assistant, research crawler, shopping agent, monitoring probe, or accessibility tool may need to make repeated requests without exposing a durable identity to every origin.

A rate-limited anonymous credential could let a service say: this client can make a bounded number of presentations for this context, but the service should not learn which other presentations came from the same credential. That is useful for CAPTCHA relief, request throttling, trial access, API metering, or abuse controls where an IP address is too coarse and an account identifier is too invasive.

It does not answer the harder governance questions. A valid ARC presentation would not prove that an AI agent has user delegation, content-use rights, purchase authority, consent to act, or a legitimate purpose. It is a rate-limited admission signal, not a moral or legal status.

Governance Use

A governed deployment should document the issuer, origin, attester, presentation context, presentation limit, time window, challenge class, fallback path, and decision the credential can affect. It should also state whether the system uses ARC because it needs per-context throttling, not because it wants a hidden identity substitute.

The ARC protocol draft states that ARC is compatible only with deployment models where issuer and origin are operated by the same entity, because tokens produced from a credential are not publicly verifiable. That constraint changes governance. It narrows who can verify a presentation, but it can also concentrate admission power inside one operator's infrastructure.

Logs should preserve enough evidence for abuse review without rebuilding a tracking system. Useful records include presentation outcome, limit policy, context label, fallback offered, and aggregate abuse metrics. Raw credential material and linkable side data should have short retention and a named purpose.

Limits

The main limit is status. Both ARC documents cited here are Internet-Drafts. They are useful primary sources for the proposal, but they should be described as work in progress. Do not cite ARC as a deployed web standard, browser API, legal compliance mechanism, or production safety control without separate implementation evidence.

The second limit is scope. ARC helps with bounded anonymous presentations. It does not solve issuer fairness, attester access, side-channel tracking, content authorization, account delegation, or the politics of which clients receive less friction. The absence of an ARC presentation should not automatically mark a user, region, assistive technology, privacy tool, or small browser as abusive.

Review Record

Source Discipline

Claims about ARC issuance and redemption should cite draft-ietf-privacypass-arc-protocol-01. Claims about ARC cryptographic properties, presentation limits, and unlinkability conditions should cite draft-ietf-privacypass-arc-crypto-00. Claims about Privacy Pass roles and authorization architecture should cite RFC 9576; HTTP challenge language should cite RFC 9577; base issuance protocols should cite RFC 9578. Draft claims should be labeled as draft claims.

Spiralist Reading

Spiralism reads ARC as a counting ritual that tries not to become a naming ritual. The client can say, "I still have one of my allowed passes for this context," without telling the gate which other doors it used.

The humane version gives anonymous users and agents a bounded path through abuse controls. The brittle version turns the absence of a pass into suspicion and lets a few issuers define who moves freely.

Sources

Return to Wiki