Discover possibilities you can trust, choose which ones to pursue, and act with people, organisations and agents. Decide what to share and what to authorise, while shaping your own life and caring for the world around you.
A qualification for a new job, evidence for a customer, permission to help someone: different situations call for different parts of your story. The Wallet's direction is to carry the relevant credentials and permissions between services, whether you act for yourself, represent an organisation or ask an agent to help. Availability is listed below.
One usable Wallet. It opens first. Each protected action explains the PIN, permission, or service relationship it needs before you continue.
See who is asking, why, what evidence is involved and which authority you hold. Choose what to share and which relationship to enter. Keep an inspectable account of what was promised and what followed.
North Harbour Materials asks for the smallest evidence set needed to assess Lot A.
Agent proposal Human approval required by policy.
Evidence checked · 4 sources · 1 policy warning
Use the browser now, run a real exchange, inspect the native beta, or enter an organisation workspace when it is enabled for your deployment.
See how accountable agents stay within visible authority →Receive supported OID4VCI offers and inspect local activity. Check Protection for this browser's storage mode.
Controlled native pilot Native WalletReceive credentials, review requests, consent, share, and retain local activity.
Public now Wallet PlaygroundRun issuer and verifier tasks in the browser with exact requests and outcomes.
Deployment-resolved workspace Organisation workspaceOrganisation identity, portable mandates, bounded agents, approval policy, and receipts share one operational model.
Moving somewhere new. Learning a craft. Travelling to see people you love. Starting a business or finding your feet again. Each brings different questions, people and decisions. The Wallet is being built to help you carry the relevant parts of your story into what comes next.
You may be a professional, a neighbour, a learner and someone who cares for another person—all at once. Your experience matters as your circumstances change. Ask for support when you need it, and choose what to share for each situation. Keep other parts of your life private.
See who is asking, why, what would be disclosed, which authority applies and what would return before choosing what happens next.
Qualifications and experience are different from permission to act for someone else. For each request, distinguish what you know and have done from who has authorised you, for what, and whether that authority still applies.
Read the human-rights foundation ↗ Read the MyData Declaration ↗ Explore local-first principles ↗ See how the story meets a place and its people ↗
Choose the actors, work, authority model, and systems around one concrete workflow. The browser turns those choices into a structured brief and an initial topology immediately.
A person may act for themselves in one exchange and for an organisation in the next. The intended review brings together who is acting, whom they represent, the evidence, the permission being requested and the expected result. Those are separate questions, even when the same person answers them.
History helps explain what happened before; it does not guarantee the next request is safe. Review the requested facts, their sources and the current permission before sharing. A valid credential and permission to act are different checks. Read “Imagination Architectures and the Work of Trust” ↗
Channel context belongs in that review too. An NFC, Bluetooth, or local wireless exchange can record the terminal, person, vehicle, or place the holder says they can see, alongside the independently authenticated protocol peer and relay limits. Policy may use that combined evidence to advance, warn, or stop the request; consent remains an explicit decision.
Implemented · opt-in Veritas is inside the wallet. The adapter makes credential metadata queryable with exact provenance; the current build still selects SQLite by default.
A product or asset record carries material, condition, provenance, and lifecycle history. The Business Wallet establishes which organisation, person, or bounded agent may add the next event. Construction and real estate are a focus, alongside batteries, textiles, electronics, and other product groups.
Circular operations handle practical loops: maintenance, repair, reuse, remanufacture and recycling. The wider regenerative ambition asks what those choices restore and enable for people, communities and ecosystems. The Wallet carries the evidence, active principal and authority into each decision.
See product groups and template status →The protocol engine and Wallet source have public repositories. Windows is the controlled native pilot, Linux desktop is coming, and MSIX + App Installer is under evaluation. Open the table for implementation evidence and deployment boundaries.
Explore the public Verifiable protocol stack ↗| Product operation | Binding / availability | Evidence and boundary |
|---|---|---|
| Verifiable protocol stack | Public library | Apache-2.0 first-party libraries implement OpenID4VC, DIDComm Messaging 2.1, WebAuthn Level 3, CTAP 2.3, selective disclosure, sensitive-memory abstractions, and TPM integration. |
| Public issuer + verifier | Public test interface | OID4VCI offer and OID4VP request widgets use the configured test API. Inspect the actual exchange and serving origin. |
| Native credential receive | Controlled native pilot | OpenID4VCI pre-authorised-code receive is app-wired and reachable from the native wallet. |
| Native presentation | Controlled native pilot | The native Home surface exposes Present when a credential is held. The routed flow includes request intake, consent preview, disclosure, a sharing receipt, and local activity. |
| Veritas evidence database | Public source | Queryable evidence, possible worlds, durable history, peer operation and explainable answers. Public source is separate from the installed Wallet's integration and release status. |
| Veritas credential memory | Adapter inactive by default | An implemented and tested Veritas-backed store makes credential metadata queryable; the current build still selects SQLite by default. |
| DIDComm peer relationships | Native binding inactive | DIDComm Messaging 2.1 is implemented in the public Verifiable stack. Peer relationships are not yet available in the native wallet. |
| Bluesky / AT Protocol | Opt-in native experiment | A connected-service OAuth path resolves handle, DID, PDS, and authorisation server. Durable key material, refresh, recovery, and wider platform callbacks remain in development. |
| Organisation roles + portable mandates | Native binding inactive | Organisation roles, portable mandates and delegation chains are not yet available in the installed wallet. |
| Hardware-backed holder keys | Holder-key binding inactive | Hardware-backed protection for production holder keys is in development and is not active today. |
| CTAP 2.3 + enterprise trust | Enterprise binding inactive | CTAP 2.3 foundations exist in the public library. Enterprise provisioning and attestation are not yet available in the wallet. |
| Public wallet source | Public repository | Inspect the Wallet source. Repository availability does not imply a signed installer, certification or a production-ready build. |
| Linux desktop | Package inactive | Linux is a committed target. No Linux wallet download is available yet. |
| MSIX / App Installer delivery | Public channel inactive | Windows web installation and managed updates are planned. No signed public installer is available yet. |
Certification, marketplace onboarding, ecosystem listings, and awards are named only when a dated external record exists. Interoperability results include the exact profile, builds, trust material, date, and terminal outcome.
The technical journey carries protocol, security, and deployment detail beyond this task-first page.
