Protocol · Private attestations
Reclaim private attestation adapter
Abraxas verifies a Reclaim proof on the server, maps one approved result into policy evaluation, then continues the existing consent and receipt flow. Partners never receive the raw proof, source website data, extracted parameters, or provider payload.
What this is
This is the first real issuer connector. A holder completes a Reclaim proof. Abraxas verifies it on the server, maps one approved result into the existing policy path, then continues fresh consent and a partner-bound receipt. It is not a generic identity product, a browser-side verifier, a provider marketplace, a raw-proof store, or an onchain proof submission path.
Holder copy
Verify one required fact privately. Google remains account access only.
Backend callback contract
Reclaim posts to Abraxas /api/reclaim/callback on the validated runtime origin: DEMO uses the isolated demo host, and Production uses the public product host. The server derives that origin from ABRAXAS_RUNTIME_ENV and the configured app/issuer origin. Partners never host this callback. A browser, partner, or request parameter cannot choose the callback URL. Session context is an opaque Abraxas session reference. The browser receives only the signed request configuration needed to launch the provider flow. App secrets stay on the server.
What is persisted
Opaque session reference, HMAC bindings, mapping id, source-controlled provider id and version, policy-result class, proof digest, timestamps, and lifecycle status. Raw proof JSON, extracted values, source website data, signatures, TEE material, emails, names, dates of birth, wallets, callback URLs, and app secrets are never stored or returned.
Where this connects
Issuer trust · Release candidates · Selective disclosure · Reusable eligibility · Partner Flow · Hosted Partner Flow · Starter kits