Business caller verification
Connect a call to a verifiable business identity, helping the recipient check which organisation is calling.
An independent playground for digital trust
Know who’s
on the other side.
A call. A webshop. A product with a story.
How do you know which business to trust?
We explore how decentralized identifiers connect a business to its cryptographic keys — so identity can be checked, rather than simply claimed.
01 / THE CONNECTION THAT MATTERS
THE ORGANISATIONA legal entity
PERSISTENT IDENTITYdid:one identity · evolving keys
THE DID DOCUMENTPublic keys & purpose
Designed to be verified
TRUST STARTS WITH A CONNECTION.
A playground for DID documents.
Curious by nature. Practical by design.01 / A little context
A name is a claim.
A key lets you check.
A decentralized identifier, or DID, is a unique identifier that can be resolved to a DID document. That document describes the public keys and verification relationships associated with the identifier.
A business uses a private key to sign something. A verifier uses the corresponding public key to check the signature. The DID document helps the verifier find the right key and check what it is authorised to do.
The next question matters just as much: what evidence connects that identifier to the real legal entity?
Follow the trust chain ↗02 / The name
trusdid.
Pronounced “trus-ted”.
Trust, with DID at its heart.
The name brings together trust and decentralized identifiers. It reflects our interest in the role of DID methods and DID documents in verifying cryptographic keys used by legal entities.
trusdid is a trade alias of Fabaleus BV, the founder’s holding company. This is our place to turn questions about digital business identity into experiments.
03 / Why it matters
Recognisable over time.
Verifiable in the moment.
A persistent business identifier creates continuity across channels, transactions and years. These are some possibilities we’re exploring.
Trusted webshops
Make it possible to verify the legal entity behind a storefront, beyond a familiar logo or convincing domain.
Digital product passports
Connect product information to its issuer over the long term, with a stable identity as cryptographic keys change.
A deliberate distinction
Business continuity.
Personal privacy.
For a legal entity, being recognisable across interactions can be valuable. It helps people connect a business, its communications and its products.
For a natural person, that same correlation can expose a pattern of activity. Our focus is on persistent public identifiers for businesses. We advocate avoiding them for people; personal identity needs designs that minimise correlation and disclosure.
Read our reasoning ↗Field notes / The foundations
Trust is a chain.
Let’s unpack it.
From an identifier to a public key — and from a public key to a business you can recognise.
Three parts. Different jobs.
Select a step to follow the connection.
01 / The rules behind the identifier
What does a DID method do?
A DID has the form did:method:method-specific-id. The method defines how its identifiers are created, resolved and, where supported, updated or deactivated. Resolution retrieves a DID document and related metadata.
Different methods make different choices about infrastructure, governance and key management. A DID does not inherently require a blockchain. The right method depends on the application, its trust model and its need for continuity.
What is in a DID document?
A document can include verification methods (such as public keys), verification relationships (such as authentication or assertion), and service endpoints. It contains public verification material, never the private keys used to sign. The identifier is intended to stay stable; the document can change when the method supports updates.
02 / Where cryptography meets the real world
A valid signature is one part of the answer.
Cryptographic verification can show that a signature was produced with the corresponding private key. It does not, by itself, prove that a particular registered business controls that key or that a signer may represent that business.
That connection needs evidence: for example, an attestation from a trusted issuer grounded in a business register. A verifier must decide which issuers and evidence it accepts, check validity and status, and assess the authority relevant to the action.
Identifier → authorised key → valid signature → trusted evidence about the legal entity. Every link needs to hold.
03 / Built for the long view
Stable identity. Replaceable keys.
A business identity may need to outlive a key. With a method that supports updates, keys can rotate while the identifier stays the same. This continuity is useful for a shop’s reputation, the source of a business call or the issuer behind a product passport.
Long-term verification also needs lifecycle planning: historic key evidence, timestamps, credential status, recovery, archival and governance. A current DID document alone is not a complete long-term validation strategy.
04 / Our design principle
Correlation needs a purpose.
A persistent identifier makes interactions linkable. For a legal entity, deliberate public continuity can help customers and partners recognise the same business across contexts. That is the kind of correlation trusdid wants to explore.
For natural persons, a public identifier reused across services can enable tracking. Our position is to avoid that design. Where personal DIDs are used, pairwise identifiers, distinct keys and careful endpoint design can help reduce linkability. A pairwise DID alone is insufficient if its document exposes the same keys or other correlatable data.
Business identity still requires care: sole traders, representatives, employees and business activity can reveal personal or confidential information. Publish only what is needed; keep personal data out of public DID documents.
05 / A European opportunity
Why we’re watching EUBW.
European Business Wallets (EUBW) aim to support trusted digital business interactions across Europe. We expect that momentum around business wallets will encourage adoption of DID documents and related verification patterns.
That is trusdid’s expectation, rather than a claim that every European Business Wallet must use DIDs. The Commission describes a technologically neutral approach. Our labs give us a practical place to explore how identifiers, credentials and representation might fit together.
Explore the wallet experiments ↗Go to the source
Further reading.
The playground / Experiments in practice
Ideas need somewhere
to be tried.
Our labs explore business identity, wallets and digital signing. Some are working sandboxes. Others are clickable concepts.
Experimental environments. Use fictional data in demos. Access to some labs requires an authorised account; a link here does not grant access.
01
European Business Wallet
A sandbox for exploring business wallets, issuer definitions, verifier templates and access to organisational credentials.
Why this lab exists & how to use it
To investigate how credentials and organisational identity work together in a business wallet. Open the lab and sign in through trusdid IAM with an authorised account. Available wallets and actions depend on your assigned permissions. This is an experimental implementation, not an official EU service.
02
Business wallet journeys
An interactive concept for wallet activation, credentials and qualified sealing, with country-specific onboarding journeys.
Why this lab exists & how to use it
To make business wallet interactions tangible before connecting real services. Start with Onboarding → Activate business wallet, then choose Belgium, France or Germany. Try the simulated wallet approvals and credential offers. QR interactions, identities, signatures and commercial plans are illustrative; use the demo’s Scan QR button.
03
Business wallet & qualified sealing
A clickable exploration of how a business wallet and qualified electronic sealing could work together.
Why this lab exists & how to use it
To explore the decisions, permissions and evidence involved in business sealing. Sign in with an authorised trusdid account, then navigate the mockup’s wallet and sealing screens. Records and outcomes are illustrative; this mockup does not create a real qualified seal.
04
Sello signing journeys
A concept for inviting signers, choosing signature levels and following the evidence trail around a document.
Why this lab exists & how to use it
To explore the experience of requesting and applying electronic signatures. Sign in with an authorised account, then use the mockup navigation to inspect document requests, identity checks and audit views. Sample subscriptions and documents are fictional. No legally effective signatures are produced.
05
Business onboarding
A demonstration of account onboarding and an operator workspace, using fictional records stored in your browser.
Why this lab exists & how to use it
To explore how applicants and operators move through business onboarding. Open the demo’s account pages at /#/accounts or the operator workspace at /#/operator. Changes stay in that browser. The connected backend mode is unavailable; use fictional records and sample data.
06
Mobile identity handoff
A companion experiment in handing a desktop verification request to a mobile identity application.
Why this lab exists & how to use it
To investigate a desktop-to-mobile verification handoff. This lab requires operator-provided access and a configured companion app. It may invoke a real identity provider and process personal information: read the flow’s disclosure before proceeding. It is separate from device activation and certificate issuance. If you have not been provisioned for the test, start with the browser demos instead.
This catalogue covers the identity experiments. Infrastructure diagnostics and internal operations tools are outside the public playground. Lab availability and access can change.