Anonymous credentials in the wild: how to collect and analyze Privacy Pass, ARC/ACT, and OHTTP evidence

Cloudflare proposed using anonymous credentials to rate-limit bots and AI agents while preserving user privacy on October 31, 2025, outlining issuance, presentation, and verification flows and comparing bandwidth/CPU trade-offs with existing Privacy Pass deployments (Cloudflare). The building blocks sit on standardized components: the Privacy Pass architecture and issuance protocols, and the HTTP “PrivateToken” authentication/challenge scheme (RFC 9576, RFC 9578, IETF draft: Auth Scheme). Expect to see more Authorization: PrivateToken headers, unlinkable single-use tokens or multi-show anonymous credentials (ARC/ACT), and, in some deployments, traffic tunneled via Oblivious HTTP (OHTTP), which intentionally splits client IP from request content (RFC 9458).

Overview

• Privacy Pass provides unlinkable tokens that prove only that a trusted issuer created them, enabling privacy-preserving authorization across origins and deployments (RFC 9576). Issuance has standard, two-message variants using either blind RSA (publicly verifiable) or VOPRF (privately verifiable) (RFC 9578; VOPRF background in RFC 9497).
• The HTTP layer exposes two artifacts you can log:
  • Challenges: 401 responses with WWW-Authenticate: PrivateToken ... containing a TokenChallenge and parameters like token-key and optional max-age (IETF draft: Auth Scheme).
  • Presentations: follow-up requests carrying Authorization: PrivateToken token="..." (IETF draft: Auth Scheme).
• Cloudflare’s post extends beyond single-use tokens to anonymous credentials:
  • ARC (Anonymous Rate-limited Credential): communication-efficient issuance, parallel presentations up to N, and late origin-binding; a downside is lack of revocation once issued (Cloudflare).
  • ACT (Anonymous Credit Tokens): stateful credential with a decreasing counter and ZK range proofs, enabling per-presentation updates and revocation-like control but higher redemption cost; presentations are sequential (Cloudflare).
  • Both ARC/ACT are currently privately verifiable (issuer and origin share a private key), which limits third-party verification; pairing-based BBS signatures are floated as a route to public verifiability (Cloudflare; IETF CFRG draft: BBS).
• Where OHTTP is used, a relay sees the client IP but not content, and the gateway sees the HTTP content but not the client IP; neither can link both without deliberate cooperation, by design (RFC 9458).

Acquisition and Extraction (platform-specific)

Server or API behind Cloudflare (most common)

• Enable Logpush for http_requests and add custom fields for the precise headers you want to analyze, e.g., Authorization and WWW-Authenticate (request/response), plus any bot-related fields. Cloudflare supports adding request/response headers and cookies as custom log fields (Cloudflare Logpush custom fields; Datasets/fields).
• Include identifiers that let you stitch together flows:
  • RayID/cf-ray (also propagate it to origin logs) (Ray ID; HTTP headers doc).
  • CF-Connecting-IP to restore original client IP at the origin (if not removed by a transform) (Restoring original IPs; HTTP headers doc).
• Ship logs to your SIEM or an HTTPS endpoint using Logpush and keep timestamps in RFC3339 or nanoseconds for tight correlation (Enable HTTP destination; API configuration).
• If you keep origin web server logs, add CF-Ray so you can join origin entries to Cloudflare logs during forensics (Add CF-Ray to logs).

Example: create a Logpush job that captures headers relevant to Privacy Pass flows.

# Pseudocode: add Authorization and WWW-Authenticate to custom fields, then create a job
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/zones/$ZONE/logpush/custom_fields" \
  --json '{
    "request_fields": ["authorization"],
    "response_fields": ["www-authenticate"]
  }'

curl -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/zones/$ZONE/logpush/jobs" \
  --json '{
    "dataset": "http_requests",
    "destination_conf": "https://logs.example.com?header_Authorization=Basic%20REDACTED",
    "output_options": {"timestamp_format":"rfc3339"},
    "enabled": true
  }'

• If you run your own reverse proxy: explicitly log Authorization and WWW-Authenticate with secure handling, and record an end-to-end request ID equivalent to cf-ray.

OHTTP deployments (relay/gateway)

• Relay logs: client source IP, relay timestamp, target gateway, byte counts. Gateway logs: decrypted HTTP metadata (method, path, headers like Authorization: PrivateToken), relay IP, gateway timestamp. You cannot attribute both sides without coordinated data sharing and timing correlation, by design (RFC 9458).
• Capture OHTTP key configuration IDs and anti-replay signals per the spec’s key/configuration and replay guidance to support later correlation or replay analysis (RFC 9458, Key Configuration; Replay attacks).

Client-side capture (for lab validation)

• Browser HAR or TLS pcap works when traffic is not encapsulated; with OHTTP, the PrivateToken presentation is inside HPKE-encapsulated messages visible only to the gateway (RFC 9458).
• For controlled testing of Privacy Pass redemption, the IETF auth scheme shows the exact Authorization: PrivateToken token="..." format and 401 challenge parameters you should observe (IETF draft: Auth Scheme).

Artifact Locations and Paths

• Cloudflare Logpush http_requests fields (examples to include): RayID, ClientIP, ClientCountry, UserAgent, EdgeStartTimestamp, OriginResponseStatus, plus your custom request.headers.authorization and response.headers.www-authenticate fields (HTTP requests fields; Custom fields).
• Cloudflare headers in origin logs: Cf-Ray and CF-Connecting-IP (HTTP headers doc).
• Privacy Pass issuance/redemption semantics: see architecture and issuance RFCs to understand what is and isn’t linkable or replayable (RFC 9576; RFC 9578).

Analysis and Correlation

• Identify challenges: filter 401 responses where WWW-Authenticate contains PrivateToken; extract token-key and any redemption context. Then find the immediate next request(s) from the same client/IP (or same session tuple) carrying Authorization: PrivateToken and join on close temporal proximity and RayID-related context.
• In Cloudflare data, a practical approach:
  • Query 401s with response.headers.www-authenticate like "%PrivateToken%".
  • For each, search forward within a short window (e.g., 5-60 seconds) for the same 5-tuple or CF-Connecting-IP+UA and a 2xx/3xx carrying request.headers.authorization like "PrivateToken%".
• Expect unlinkability: with standard Privacy Pass tokens, redemption events are designed to be untraceable to issuance, and tokens are single-use; do not expect to tie a token to a user beyond the surrounding network context (RFC 9576; RFC 9578).
• If ARC/ACT are deployed:
  • ARC enables up to N parallel presentations after one issuance; you may see many Authorization: PrivateToken redemptions if paired with Privacy Pass for revocation, but the ARC credential itself remains opaque in logs (Cloudflare).
  • ACT updates state per redemption; expect strictly sequential presentations and potential server-side policy changes driven by the counter (Cloudflare).
• OHTTP correlation: you need both relay and gateway logs. Relay sees Client→Relay; Gateway sees Relay→Gateway with decrypted HTTP. The split is intentional for privacy and blocks naive IP-based attribution (RFC 9458).

Example Splunk sketch (Cloudflare Logpush):

index=cf_http sourcetype=cloudflare:http_requests 
| eval has_chal=if(like(response_headers.www_authenticate, "%PrivateToken%"),1,0)
| eval has_auth=if(like(request_headers.authorization, "PrivateToken%"),1,0)
| transaction CF_Connecting_IP UserAgent maxspan=60s keepevicted=true
| search (has_chal=1 AND has_auth=1)
| stats values(RayID) as rays, min(_time) as first_ts, max(_time) as last_ts by CF_Connecting_IP, UserAgent

Validation and Pitfalls

• Authorization headers are sensitive and often stripped or redacted; if you log them via Cloudflare custom fields, treat them as restricted data and ensure access control and retention policies match the sensitivity (Custom fields).
• With privately verifiable tokens or credentials (VOPRF issuance; ARC/ACT today), you cannot independently validate a token without issuer/origin key material. Plan escalation paths to the issuer/origin operator for verification, or deploy publicly verifiable schemes when available (e.g., BBS-style signatures) (RFC 9578; Cloudflare; BBS draft).
• OHTTP cloaks client IP from the gateway and content from the relay; traditional IP reputation and per-IP rate heuristics can break. Adjust detection to rely on behavioral signals and per-relay controls (RFC 9458).
• Benchmarks and bandwidth: ARC/ACT reduce issuance bandwidth vs issuing thousands of blind signatures or VOPRF tokens, but presentation cost is higher; set expectations for CPU and latency during validation and tune sampling accordingly (Cloudflare).

Reporting Notes (chain of custody, reproducibility)

• Preserve raw Cloudflare Logpush batches with integrity metadata (destination timestamping, file hashes). Keep configuration snapshots that prove which fields were enabled (including custom fields) at collection time (API configuration).
• Include Cf-Ray in origin logs and attach the Cloudflare zone/account identifiers so support can validate specific requests if needed (Add CF-Ray to logs).
• Document whether OHTTP was in use, who operated the relay and gateway, and what key/config rotation policy applied (RFC 9458, Operational considerations).

Tools

• Cloudflare Logpush to HTTPS/S3 and Log Explorer for scoping and export (Enable HTTP destination; Datasets/fields).
• Test clients and references: Privacy Pass auth scheme examples for header shapes; issuance protocol details for interpreting flows (IETF draft: Auth Scheme; RFC 9578).
• Cloudflare’s Privacy Pass implementation notes and the “Silk” browser extension (for lab validation) (Cloudflare: protocol update + templates).

Takeaways

• Turn on logging for WWW-Authenticate and Authorization around PrivateToken flows and propagate Cf-Ray to origin logs now.
• Build correlation that tolerates unlinkability: rely on timing, RayID, session tuples, and per-origin context rather than token identity.
• If you operate with OHTTP, arrange a legal/operational path to join relay and gateway logs for incident handling.
• Expect ARC/ACT pilots: plan for privately verifiable tokens today and watch for publicly verifiable options (e.g., BBS) to ease third-party validation later.
• Benchmark your validation path; ARC/ACT shift cost from issuance to presentation-reserve CPU where tokens are redeemed.