---
title: Attestation & Privacy Pass
---

# 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](./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](https://www.rfc-editor.org/rfc/rfc9576.html).

## 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 {#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](./how-verification-works#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](../api-reference).
Attestation is an upstream signal the engine consumes; your code path stays the
same.