Decentralised Identity (DID)
Prove what matters. Share only what is needed.
Decentralised identity lets a person, organisation, device, AI agent or product hold signed claims and present only those a verifier needs, without the verifier contacting the issuer each time. ColdAI implements the W3C standards for decentralised identifiers and verifiable credentials, with selective disclosure, for uses such as KYC, age checks, professional credentials and supply-chain provenance. Most of the work sits outside the cryptography: deciding whom to trust, what to ask for and how holders recover when keys are lost.
The opportunity
Start with a decision
worth improving.
A person or organization needs to demonstrate an attribute without repeatedly handing over its entire record. The verifier must know which issuer it trusts and whether the credential is still valid.
From possibility to a working system
Follow the flow.
Three connected decisions. One considered architecture.
Conceptual flow, not a live system or measured result.
Establish the trust model
Identify who can issue a claim, who holds it and who is allowed to verify it. Define assurance, data minimization and lifecycle requirements before choosing credential formats.
Issue and present
Connect credential issuance and presentation to the user's workflow. Use the disclosure and proof capabilities supported by the selected implementation, with clear consent and recovery behavior.
Verify in context
Check the proof, trusted issuer and relevant status information. Keep the final access or business decision separate from the cryptographic check and document what the claim actually establishes.
The work, made concrete
What we can build
with your team.
We agree scope, dependencies and acceptance criteria before delivery. Your project can start with an assessment, a pilot or an integration into an existing system.
Identity and credential trust architecture
Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.
Issuance and verification integration
Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.
Lifecycle, privacy and recovery design
Make the next step operable: document responsibilities, known limitations and the path from pilot to ongoing use.
In depth
Go deeper into credential programme design
Two decisions most credential programmes reach early: whether and how to accept the EU Digital Identity Wallet, and which credential format to issue in the first place.
- 01Regulation explainereIDAS2 relying parties: accepting EU Digital Identity WalletsWhat the amended eIDAS Regulation asks of relying parties: who must accept the EU Digital Identity Wallet and when, registration, formats and how to prepare.
- 02ComparisonW3C VC vs SD-JWT VC vs mdoc: choosing a credential formatW3C Verifiable Credentials, SD-JWT VC and ISO mdoc compared on selective disclosure, unlinkability, offline use, standards status and EU wallet support.
One credential, from issuance to an access decision
The issuer signs once. After that, the holder and verifier complete the exchange without the issuer taking part.
- Issuer
The organisation that knows the fact, such as a register, bank, employer or manufacturer, and signs it.
- Holder wallet
Stores credentials and the holder's keys, asks for consent and builds each presentation.
- Verifier
The service that needs a claim before it grants access or completes a transaction.
- Trust registry
A list or ledger stating which issuers are accredited for which credential types, and their keys.
- Status list
Published by the issuer so verifiers can see whether a credential has been revoked or suspended.
- Issuer to Holder walletIssue credential
- Verifier to Holder walletRequest named claims
- Holder wallet to Holder walletConsent and select
- Holder wallet to VerifierPresent proof
- Verifier to Trust registryIs the issuer trusted?
- Verifier to Status listStill valid?
- Verifier to VerifierApply business policy
The final three messages are where deployments differ most. A signature can be perfect and the credential still unacceptable, because the issuer is not accredited for that claim type, the credential was suspended yesterday, or the policy needs a higher assurance level than the issuer provides. Treating the cryptographic check and the business decision as separate steps, with separate logs, makes it possible to explain later why access was granted or refused.
The W3C Verifiable Credentials Data Model describes these three roles and the claims they exchange1, and W3C Decentralized Identifiers give issuers and holders identifiers whose keys can be looked up without a central account provider2. Neither standard decides whom a verifier should trust. That is a governance question.
People, organisations, devices, AI agents and products as credential subjects
The same standards serve very different subjects, and each one raises its own hardest question.
| Subject | Typical issuer | Who controls the key | Example claim | Hardest design question |
|---|---|---|---|---|
| Person | Government, bank, university or employer | The person, in a phone wallet | Above the legal age; registered nurse; verified address | Recovery after a lost phone without a central back door |
| Organisation | Business register, regulator or industry body | Named staff under the organisation's key policy | Registered company; authorised importer | Which employees may present on the organisation's behalf |
| Device or machine | Manufacturer or operator at commissioning | A secure element inside the device | Genuine model; calibration certificate in force | Rotating keys across a fleet that is rarely online |
| AI agent | The organisation that deploys the agent | The agent runtime, under its operator's controls | May place orders within an approved limit for a named company | Scoping delegated authority and revoking it quickly |
| Product | Brand, certifier or authenticator | Often nobody: the product is a subject, not a holder | Certified organic batch; genuine item | Binding the credential to the physical object |
Product credentials depend on a trustworthy physical identifier, which our phygital assets work covers.
Writing the trust framework before choosing the technology
A credential is only as useful as the agreement around it. Before anyone picks a format or a ledger, the participants need written answers to a short list of questions: who may issue each credential type, how issuers are accredited and removed, what assurance an issuer must reach before signing, what verifiers may request and keep, and who is liable when a credential turns out to be wrong.
In regulated settings much of this already exists. Qualified trust service providers appear on national trusted lists, professions keep public registers, and accreditation bodies already certify laboratories and auditors. Reusing those sources of authority is usually quicker and more credible than creating a new consortium, and the EU wallet framework builds on existing trusted lists in a similar way, as our page on wallet relying parties under the amended eIDAS Regulation explains.
Where no authority exists, such as a supplier network agreeing which sustainability auditors to recognise, keep the first framework narrow: one credential type, a handful of issuers and a clear process for adding more once the first exchange works.
Requesting the least data that still supports the decision
Selective disclosure only helps if verifiers ask for less. These patterns start from the decision, not from the data available.
- If
You sell an age-restricted product or service.
ThenRequest an attribute stating the holder is above the required age, not a date of birth or a full identity document.
The decision is yes or no, and anything beyond that becomes data you must protect.
- If
You onboard customers under anti-money-laundering rules.
ThenRequest person-identification data at the assurance level your customer due diligence policy sets, add address only if your rules require it, and file the issuer and assurance level with the record.
Supervisors ask how identity was verified, so the evidence trail matters as much as the attributes.
- If
You allocate shifts to licensed professionals.
ThenAccept a licence credential from the issuing register and check its status each time a shift is booked.
Licences can be suspended mid-term, and a check made only at hiring goes stale.
- If
You accept supplier certificates in procurement.
ThenVerify the certifier's credential about the supplier, including its scope and expiry, instead of an emailed PDF.
A signed, scoped claim cannot be quietly edited, and expiry is checked automatically.
- If
You let an AI agent act for a customer or a company.
ThenRequire a delegation credential naming the principal, the permitted actions and an expiry, and log every presentation, as in our guide to verifiable agent audit trails.
Counterparties need to know whose authority the agent carries, and the principal needs a fast way to withdraw it.
Lifecycle failures that undermine a credential programme
Lost or replaced devices
Early signalSupport queues fill with holders who must re-onboard from scratch after changing phones.
MitigationDesign reissuance from the issuer's records, with a re-proofing route, before launch; avoid recovery schemes that hand anyone a copy of holder keys.
Issuer key compromise or rotation
Early signalCredentials signed under an old key start failing, or forged ones start passing.
MitigationPublish rotations through the issuer's DID document or trust list, keep earlier keys verifiable for credentials issued under them, and prepare a revocation plan for each key.
Status checks that reveal the holder
Early signalIssuer logs show which verifier checked which credential, and when.
MitigationUse status lists that verifiers fetch in bulk, or short-lived credentials, rather than per-credential lookups.
Correlation across verifiers
Early signalThe same identifier or signature value appears in presentations to unrelated services.
MitigationReserve public, ledger-registered identifiers for issuers, organisations and devices; give individuals pairwise or wallet-held identifiers and formats that limit linkability.
Presentation phishing
Early signalA look-alike site requests credentials and replays the presentation elsewhere.
MitigationBind every presentation to the verifier's identity and a one-time challenge, and have wallets authenticate verifiers before showing a consent screen.
Checking clinical licences without collecting documents
Frequently asked questions
How is decentralised identity different from single sign-on?
With single sign-on, an identity provider vouches for the user in real time at every login, so it must be online and can see each service the user visits. With verifiable credentials, the issuer signs a claim once and the holder presents it to many verifiers without the issuer taking part; the verifier checks the signature, the issuer's standing and the status. Many organisations will run both: single sign-on for staff accounts and credentials for claims that cross organisational boundaries.
Should personal data or individuals' identifiers be written to a ledger?
Generally not. The General Data Protection Regulation gives people rights to rectification and erasure under Articles 16 and 17, which sit badly with records that cannot be changed3. Ledgers suit public information: issuer keys, credential schemas, trust registries, status lists and hashes that anchor an audit trail. Personal attributes belong in the holder's wallet and the issuer's systems, under ordinary data protection controls.
Can devices and IoT sensors hold verifiable credentials?
Yes, provided the device can protect a private key, usually in a secure element or trusted execution environment. Credentials are typically issued at manufacture or commissioning and state facts such as model, firmware lineage or calibration. The hard parts are operational: renewing credentials on devices that connect rarely, revoking them when hardware is retired or resold, and keeping messages compact enough for constrained links. Our edge AI and IoT work covers the device side.
What should we have in place before starting a credential project?
Three things: a defined claim and the decision it supports; the issuers you will trust and the verifiers who will rely on the claim; and your privacy, assurance and recovery requirements. With those agreed, ColdAI designs the identity and credential trust architecture, integrates issuance and verification into your systems, and sets out lifecycle, privacy and recovery procedures. Without them, a pilot tends to prove that signatures work and little else.
Does ColdAI support zero-knowledge proofs and cross-chain identity resolution?
Yes. Our implementations follow the W3C decentralised identifier standards and support selective disclosure, zero-knowledge proofs and resolving identifiers across chains. Which privacy features a given project can use depends on the credential format and the wallets its holders carry, so we choose per use case; the comparison of credential formats sets out the trade-offs.
Sources
Connect the architecture
The next connection.
Explore the complementary capabilities that can turn an individual technology into a complete workflow.
Your next move
Bring us the
real problem.
A workflow that takes too long. A system that cannot connect. An idea that needs a technical path. Start there, and we can define what to investigate, build and measure.
- A defined claim and verification decision
- Trusted issuers and relying parties
- Privacy, assurance and recovery requirements