Attestation & Privacy Pass

Some clients can present cryptographic evidence that they are a genuine browser or device before any challenge runs. CaptchaLa treats such evidence as a trust signal, not a replacement for verification: a request that arrives with a valid attestation token can skip the interactive challenge; everything else is scored and verified as usual (see How verification works).

This page explains the standards involved, what CaptchaLa actually consumes today, and what is realistic versus aspirational.

The standards

• Privacy Pass (RFC 9576) — an IETF framework for anonymous, redeemable tokens. A client gets a token from an issuer, then redeems it with an origin without the origin being able to link redemptions back to the client.
• Private Access Tokens (PAT) — Apple/Cloudflare's deployment of Privacy Pass on the web. A device attests to a platform issuer, and the resulting token is verifiable by an origin using the issuer's published public key — no per-customer setup. This is the piece CaptchaLa can ingest generically.
• PACT (Private Access Control Tokens) — a proposal put forward in June 2026 (involving Cloudflare, Chrome, Firefox, Edge, and Shopify) that extends Privacy Pass toward a broader, standardized attestation flow. It is a proposal and is years out; nothing here depends on it shipping.

Reference: RFC 9576 — Privacy Pass Architecture.

What CaptchaLa ingests today

Web: Private Access Tokens / Privacy Pass

On the web, CaptchaLa can accept a Private Access Token as a trust signal. The token is verified against the issuer's public key, so there is no customer configuration — it works the same for every site. A request carrying a valid PAT is treated as low-risk and is routed to the invisible tier; a request without one simply follows the normal risk-based path. PAT is therefore an optimization, never a requirement — browsers and platforms that don't emit one lose nothing.

Native: the honest reality

Mobile attestation is app-bound, which changes what is possible:

• iOS App Attest is signed under the app's own Apple Team / Bundle ID.
• Android Play Integrity verdicts are tied to the app's own Google Cloud project.

There is no generic, issuer-public-key path the way there is for web PAT. To verify these, the verifier needs the specific app's credentials. So CaptchaLa exposes them only as an optional, customer-configured signal: if you supply your App Attest / Play Integrity configuration, we can use those verdicts as an additional input for your apps. CaptchaLa does not verify mobile attestation generically, and it is off by default.

When attestation is not configured, native SDKs rely on our own device and behavioral risk signals — the same risk-engine-first model used everywhere else. Attestation, where available, only adds confidence; it is not the basis of native verification.

Summary

Surface	Mechanism	Verified with	CaptchaLa support
Web	Private Access Tokens / Privacy Pass	Issuer public key	Ingested as a trust signal, no setup
iOS / macOS	App Attest	App's Apple Team / Bundle keys	Optional, customer-configured only
Android	Play Integrity	App's Google Cloud project	Optional, customer-configured only
Native (default)	Device + behavioral signals	CaptchaLa risk engine	Always on

Roadmap

Two items are explicitly future work, not current behavior:

• Following PACT. PACT is a June 2026 proposal. We are tracking it, but the current product depends only on shipping standards (Privacy Pass / PAT). Treat any PACT support as roadmap, not a feature.
• Publicly-verifiable pass tokens. Today, CaptchaLa pass tokens (pt_ / sct_) are verified by a server-to-server call to our API (see token types). Emitting a token you can verify offline against our published issuer public key — no call back to us — is a roadmap item. It is not available today.

Nothing on this page changes the integration you write now: validate pt_ tokens server-side as described in the API Reference. Attestation is an upstream signal the engine consumes; your code path stays the same.