A digital identity credential normally works like this: you show it, the verifier calls the issuer, the issuer says yes. It is simple, it is easy to build, and it quietly makes the issuer the most privileged party in the system — because the issuer now sees every bar, landlord, employer and website you presented your identity to, in real time.
Identity Pass is built so that call does not happen.
Verification is a signature check, not a lookup
A pass is a JWT signed with RS256, using the same key that signs our OpenID Connect ID tokens — the one already published at /.well-known/jwks.json. Anyone can fetch that key once, cache it, and verify passes forever without telling us anything.
1. GET https://uniauth.id/.well-known/jwks.json (once, cacheable)
2. verify(passJwt, jwks) (offline, forever)That is the whole protocol. There is no verification endpoint to call, no API key to obtain, and no request from the verifier that reaches us. We cannot build a map of where your identity has been presented, because that data never arrives.
Reusing the OIDC signing key is deliberate. It means the pass is anchored to the same key material that already backs every token we issue, it rotates on the same schedule, and there is no second key hierarchy to get wrong. A verifier who already trusts our tokens does not have to trust anything new.
The subject is pairwise, and it is not your account
The identifier inside a pass is a pairwise subject computed over a dedicated pass audience. It is not your user ID, and it is not the subject any OAuth client sees. Three consequences follow:
- A verifier cannot correlate your pass with an account you hold at an application that uses UniAuth for sign-in. The identifiers are different by construction.
- A leaked pass does not leak an identifier that means anything anywhere else in the system.
- Nothing about the pass grants access to the account behind it. It attests; it does not authenticate.
This mirrors the OIDC pairwise model exactly, which is the point — the privacy property is not a special case bolted onto a new feature, it is the one already applied everywhere else.
Revocation is rotation
A pass lives at an opaque slug. Rotating that slug is what revocation means: the old address stops resolving immediately, and a new one takes its place. There is no revocation list to publish, no window during which a cached copy stays valid because a verifier has not refreshed anything.
The signed credential is a point-in-time attestation, so a copy someone saved will verify as a valid signature over the claims it was issued with. The public page is always live and always reflects the current state, and that split is intentional: a signature proves the claims were true when issued, while the page proves what is true now.
Every field has its own switch
Sharing a pass is not all-or-nothing. Each field carries a per-user visibility setting, so a pass shown to prove one thing does not incidentally disclose four others. The common case — proving you are a verified human with a particular trust tier, without attaching a name to it — is a configuration, not a separate product.
Apple Wallet, properly signed
The pass can be added to Apple Wallet as a real, signed .pkpass — not a screenshot, not a web page saved to the home screen. That means it behaves the way every other Wallet item behaves, including on the lock screen, and it is verifiable through the same signature path as the web credential.
What this does not do
It is worth being plain about the limits. A pass attests to claims we hold about an account; it does not attest that the person presenting it is the person the claims describe. That binding is what a photo, a device biometric, or an in-person check is for. Nothing about a cryptographic signature solves the problem of somebody showing you someone else's phone.
What it does solve is the part that was quietly broken everywhere else: making the issuer a bystander at verification time, rather than a witness to every use.