OTCP demo environment. Tessera is a fictional workspace running on live OTCP rails. No real accounts, no real data. All demos
T Tessera Participant directory

Sign in

There is no password to steal.

Tessera never issued you one. Signing in is a challenge your wallet signs with a key that lives in your phone's secure hardware and only your fingerprint can use. Nothing to phish, nothing to reuse, nothing in a breach.

A tessera was a small token you carried to prove you were expected. Its halves only fitted each other.

Sign in to Tessera

You need the OTCP wallet on your phone with an identity already in it.

Two doors, and they are not the same door.

Tessera accepts both, and tells you which one you came through, because they buy different things. A verifier that treats every factor as equal is the reason account takeovers still work.

Full access

Your wallet signs the challenge

The wallet holds a P-256 key generated inside the phone's secure hardware. It was born requiring authentication for every single use, so each signature costs a fresh fingerprint — and enrolling a new fingerprint destroys the key outright.

What you prove
possession of the key and your biometric, in one step
If someone phishes the login page
Fails. The signature commits to who asked and to a one-time nonce, so it is worthless anywhere else.
If Tessera is breached
Nothing to take. Tessera stores a public key and a handle.
Limited access

You type a six-digit code

The wallet's Auth tab works like any authenticator: Tessera and your wallet share a secret, and both derive the same rolling code from it. The wallet keeps codes masked until a biometric reveal — but that gate is local, not part of the proof.

What you prove
possession of a shared secret
If someone phishes the login page
Works. A code typed into a convincing fake can be replayed on the real site within its window.
If Tessera is breached
The secret leaks with it, and a leaked secret is a cloned authenticator.

And while it signs you in, here is everything Tessera learns

Asked for

  • ✓Your first name, to say hello
  • ✓That the credential is a valid, unrevoked OTCP ID
  • ✓A handle for your key, scoped to Tessera alone

Not asked for, and not received

  • ·Surname, date of birth, address, document number
  • ·An email address or a phone number
  • ·Your public key itself, or anything another site would recognise

That last one matters. The obvious way to recognise a returning user is the key's thumbprint — but every site would compute the same value for you, and two of them could merge their records with a string comparison. So the verifier never returns it. What Tessera gets is a hash of it under Tessera's own scope: stable here, unrelated everywhere else.

Don't take our word for it — and don't take ours either. Before your wallet answers anything it resolves who is asking: these requests are made through the demo instance's verifier, otcp-demo-verifier, and the wallet walks its entity statement in the Trust Fabric first. The identity you answer with came from an accredited issuer, whose standing resolves the same way. Both appear in the participant directory; Tessera is a fictional front end on that verifier's public tenant, so look for the verifier and the issuer there, not for us.

The whole thing, in four lines.

1
Tessera asks the verifier for a challenge
A one-time nonce, bound to Tessera as the audience.
2
Your wallet reads it and asks you
By QR from a computer, or in place on the phone through the Digital Credentials API.
3
Your fingerprint unlocks one signature
Exactly one. The key will not sign twice on one unlock.
4
The verifier checks it and hands back a handle
Issuer signature, revocation status, nonce, audience — then the pairwise handle Tessera keys your account on.

Standards, not inventions: OpenID4VP for the request, SD-JWT VC with key binding for the answer, Token Status List for revocation, and RFC 6238 for the backup code. See the other demos →