How the wallet works
Ten parts of the Wallet model, not ten hurdles before you can use it. Open the Wallet first; a particular action may then need local protection, a service account or permission to act for someone else. Each part names the relevant protocol and carries a technical trace for anyone who wants the exact endpoints and formats. See the overview at Wallets and identity for the wider picture.
1. A person remains themselves
A profile groups local credentials, settings and history. It is not the whole person and does not establish permission to represent someone else. Separate profiles do not by themselves prevent correlation through shared credentials, identifiers or network activity.
Some exchanges resolve a DID document; others use issuer URLs and holder-key bindings. The identifier and key requirements depend on the credential format and protocol profile. One identifier need not follow a person through every exchange.
Technical trace
GET /did/resolve?did=… resolves a supported DID. Resolution
identifies a document and its keys; it does not establish the person's rights or a
mandate to act.
2. A passkey protects access
A passkey lets an authenticator prove control of the registered private key. The service verifies the response using the public key; it does not receive the private key. Whether the passkey is device-bound or backed up depends on the authenticator and service policy.
The app entry page leads with passkey access and invitations. It shows other sign-in methods only when the deployment enables them. The exact native and public-web boundaries are listed on the Wallet page.
Technical trace
navigator.credentials.get() runs against a discoverable
credential. The app calls
POST /webauthn/authenticate/options for a challenge and
POST /webauthn/authenticate/verify to verify the response.
Registration uses navigator.credentials.create() with
/webauthn/register/options and
/webauthn/register/verify. First-administrator enrollment
uses a separate private-link ceremony, not unrestricted public registration.
3. An organisation entrusts authority
In the intended portable-authority model, a relationship record describes a role at an organisation: who entrusted it, its scope and when it expires. The receiving service must check whether it authorises the requested action. Holding a role does not confer the organisation's full authority.
Technical trace
A relationship record shape: { role, organisation, entrustedBy, scope,
expiresAt }. Every field is explicit; there is no ambient "member of organisation
therefore can act as organisation" rule.
4. A credential is issued
Issuance runs as an OID4VCI Pre-Authorized Code offer: the issuer creates an offer, the wallet redeems it for an access token, and the credential endpoint returns the signed credential. This is live today — try it in the sandbox.
The native Wallet also contains an implemented and tested Veritas-backed store that makes held credential metadata queryable as a local evidence graph. It remains opt-in; SQLite is the default vault today.
Technical trace
POST /connect/{tenant}/oid4vci/offer with
{"credentialConfigurationId":"…","subject":"…"} returns an
offer rendered as a QR code and an openid-credential-offer://
deep link. The wallet exchanges the pre-authorized code at the token endpoint, then calls
the credential endpoint to receive the credential — as SD-JWT VC, ISO 18013-5 mdoc, or a
W3C Data Integrity credential, depending on the configuration chosen.
5. The wallet presents what is needed
Presentation runs as OID4VP: a verifier requests specific claims. Review both the requested claims and any format-required information before agreeing. Use a compatible installed holder for the public presentation test; receiving a credential in the Web Wallet does not establish that it can complete the presentation flow.
Technical trace
POST /connect/{tenant}/oid4vp/request prepares a PAR-backed
signed authorization request, returned as an openid4vp:// deep
link and QR code. The wallet resolves the request, selectively discloses the requested
claims (for example a single family_name field from an SD-JWT
VC via DCQL). The public starter uses the encrypted
direct_post.jwt response mode.
6. A verifier checks the result
Checking a presentation means resolving the issuer's identity, verifying the credential's signature, and — where the credential carries one — checking a revocation status list. Nothing is accepted on the strength of the presentation alone.
Technical trace
GET /did/resolve?did=… resolves the issuer's DID document and
signing key. The verifier checks the credential's signature against that key and, for
UNTP-shaped credentials, dereferences the credentialStatus
BitstringStatusListEntry to confirm the credential has not been
revoked.
7. A device can prove where a key lives
Hardware-backed key protection is in development. The current wallet does not yet place production holder keys in a TPM or equivalent platform secure hardware, and it will state clearly which protection is active when that changes.
Technical trace
The implementation already has a hardware-binding path, but it is not the production holder-key path today. Hardware validation, recovery and fallback behavior must be completed before the wallet can claim hardware-backed keys.
8. An agent receives a bounded mandate
The intended mandate gives an agent a specific task, not all of a person's or organisation's authority: a purpose, separate read, draft, publish and reply permissions, a validity window and an approval requirement. The current public publication flow is narrower: an agent may draft, but a person must review and publish. See the agent publication policy.
Technical trace
A mandate record: { purpose, mayRead, mayDraft, mayPublish, mayReply,
recordTypes, validFrom, validTo, humanApproval }. The accepting service must check
whether the mandate still applies. Disconnecting a device is not the same as revoking
a permission at every service.
9. Federation and trust signals update relationships
Beyond a single issuer and verifier, trust extends through a federation of entities that recognise each other, and relationships are expected to update as signals arrive — a credential revoked, a mandate withdrawn, a session that should end. This direction is in development.
Technical trace
OpenID Federation entity statements would form a trust chain from a leaf entity up to a recognised trust anchor. A Shared Signals Framework (SSF) stream is the intended channel for pushing revocation and session-change events to subscribers as they happen. Neither is exercised end-to-end on the public app yet.
10. The same foundations extend to business wallets, laptops, IoT fleets, and services
Nothing above is specific to a single person's phone. The same DID, credential, key, and mandate model applies to a business wallet, an enterprise laptop, an IoT sensor on a factory floor, or a service account — each is just another kind of holder. Fleet-wide device and laptop management, and broader business-wallet profiles, are in development.
Technical trace
The device identity record from step 7 generalises across device classes; the mandate record from step 8 generalises across non-human actors. What remains in development is breadth — enrolling and managing many devices and business-wallet profiles at once, not a different underlying model.
Next
The overview: what a wallet holds, keys and hardware, protocols, and status.
Open your Wallet without signing in. Check its current storage protection and supported credential operations.
Issue and present credentials against the live server, no sign-up.