The principal control surface
The issuer’s passkey page for the person behind a verification (not a wallet; the holder library stays the sovereign path): the view, the issuer-side revocation beside the holder’s kill switch, the consent requests of the commercial rail, and the one operator call that enrols the person.
The principal control surface is the issuer's own page for the person who completed an identity check with it. With a passkey and nothing installed, the person sees what their verification backs, ends it at once if their keys are lost, and answers the consent requests of the commercial rail. It is hosted by the issuer, under the issuer's origin, and it knows only that issuer's records about that one person.
It is not a wallet. It holds no credential, no credential secret and no key that can present; it never presents on the person's behalf and it recovers no key. The holder library stays the sovereign path: the person who still has it keeps every credential in their own infrastructure and switches any of them off with the holder's kill switch, without the issuer. The surface is the issuer's complement for the person without keys, and the device the commercial rail asks for consent.
What the person can do there
| Action | What happens |
|---|---|
| See their verification | Everything the issuer holds about the person's own session chain (the first session and every renewal): each session's state, grade, approval time, end of reuse and freshness band; the identity credentials with issuance, expiry and status; the agents with lease start and end, state (active, expired, revoked, replaced) and bundle; the seller attestations; the revocation history; the passkeys |
| Open the agents' recorded terms | On request only, the scope axes, limit and key-custody class the issuer recorded at mint, opened from the issuer's sealed record under one audit entry |
| End everything | Issuer-side revocation of every credential, agent and attestation the verification backs, and the end of the verification itself (below) |
| Answer consent requests | Accept or refuse, once, a request the commercial rail escalated to the person (below) |
| Manage passkeys | Add a second passkey; remove one, never the last |
What it never shows
The surface shows nothing the issuer does not hold or must not hold: no pairwise pseudonym (that is the verifier's), no nullifier (that is the holder's), no identification field (that stays with the identity-verification provider), and nothing about any other person. There is one surface per issuer and no view across issuers: MintID has no principal identifier and builds none. Nothing of the surface is on chain, and its logs carry truncated session handles only, never a passkey identifier, a bearer, a request's content or a scope.
Two revocation paths, two bounds
| Path | Who acts | How it is published | Bound |
|---|---|---|---|
| Holder self-revocation (the kill switch) | the holder, from the holder library, with the credential's own secret | a zero-knowledge proof through a privacy relay; the chain records the nullifier and forces the issuer to fold it | the published bound from the chain's recording: 245 s on the single-node production chain (revoking your own credential) |
| Issuer-side revocation from the surface (a panic) | the person, signed in with a passkey; the issuer revokes | an emergency status root when the issuer's emergency key is armed; otherwise the next ordinary root, with the same set | at once with the emergency root, which makes every earlier root unusable for verifiers once it is final; otherwise the next root and the published validity window. The surface states its own figure: one heartbeat plus the validity window of a status root |
A panic is the issuer's path, with the issuer's bound. It is not a self-revocation and does not replace one: it needs no credential secret, because the issuer revokes from its own records, and the issuer therefore learns that the person ended the verification. Where the keys exist, the kill switch remains the first thing to reach for.
What a panic does:
- every approved session of the chain is withdrawn, terminal exactly as a consent withdrawal: no new credential is issued from the ended verification, and the person who wants credentials again completes a new identity check (strict reading of re-verification after lost keys);
- every attestation, identity credential and agent the sessions back is revoked, the agents undelayed: no cascade spread for this trigger, and agents an earlier cascade had scheduled go now;
- the emergency root carries the person's own set only, so one person's panic never collapses the cascade spread that protects everyone else;
- publicly, a panic is visible as an emergency root of the issuer (public reason code 4), attributable and reviewable by the council, and never as anything about the person.
A panic is idempotent: a second one ends nothing and repeats how the first was published (the emergency root or the next root).
Enrolment: the one operator call
The operator that runs the identity-check hand-off makes one call to the issuer right after a session is approved, and receives a one-time enrolment link:
- Hand the URL to the person once, at the end of the verification, the way the hand-off URL was handed: it is a one-time link valid for 24 hours, carrying a random token and never the session identifier. The person opens it and registers a passkey (resident key, user verification required); the page then points to the surface.
- One enrolment per session. A first session enrols its chain once; asking again is refused.
- A renewal replaces. Call it again after an approved renewal session: that enrolment replaces every earlier passkey of the chain and ends their sign-ins. This is the only way to replace passkeys after loss.
None of the MintID SDKs wraps this call: they are holder-side and verifier-side, and the operator's issuer calls (opening an identity-check session, the credential and agent offers) are made by the operator's own client against the issuer's API contract.
Sign-in and passkeys
The person signs in on the issuer's page with the passkey (a discoverable credential against a single-use, five-minute challenge) and receives a 15-minute bearer, of which the issuer keeps only a digest. A second passkey can be added from a signed-in view; one can be removed, never the last, and its bearers end with it. A passkey registered less than 24 hours ago cannot accept a full-identity request.
The passkey authenticates the person towards the issuer and nothing else. It is not the credential's key, it attests nothing about the credential, and the issuer verifies no attestation statement from it: it learns a public key and a credential identifier, never a device model. The key-custody appraisal of agent keys is a different use of the same standard and shares no code with it.
Pending consent requests (the CIBA device)
When the commercial rail escalates an offer to the person, the surface's channel parks it with exactly the content the consent rules require: the relying party, the tier or the obligation class and its fields, the bid, the stated purpose, the correlation warning where it applies, and for the first exercise of a mandate its act and bounds. A parked request lives for the governed consent timeout; the person accepts or refuses it once, and an expired one cannot be decided: silence refuses.
In this version the exchange that escalated is refused when the request is parked, as before, and the person's decision is recorded on the surface. The re-entry of the exchange with the recorded decision is scheduled, and so is the choice of whether each decision needs a fresh passkey assertion; today a decision rides the sign-in bearer. The commercial rail itself is built and switched off: no identity is released through it until its governance texts are in force.
Current status
The surface is built in the reference issuer: enrolment, passkey sign-in, the view, the panic through the emergency root, passkey management and the parking of consent requests. It is not yet switched on in a MintID deployment; an issuer of your own switches it on in its configuration, and it is off by default. The re-entry of a recorded decision into the commercial exchange is scheduled.
Where to go next
- Credentials and holders — the holder library, the sovereign path, and the kill switch.
- Agent clients — the agents a panic revokes, and the disclosure relay.
- The public testnet and its KYC sandbox — the revocation bounds as measured.