A signed credential can prove who issued a claim. A blockchain cannot decide whether that claim is true, whether sharing it is private, or whether an AI agent is allowed to act. This guide separates the parts so you can choose an identity architecture for the problem you actually have.
Updated October 21, 2026. This is an architecture and standards guide, not a claim of hands-on testing. Standards status and rollout statements are linked to primary sources where discussed.
What blockchain-based identity means, and what it does not
Blockchain-based identity is an architecture in which a shared ledger helps publish or govern identity-related verification material. It does not mean putting a passport on a public chain. It also does not mean that a wallet address proves a legal name, that every claim becomes true through consensus, or that a user becomes anonymous simply by using cryptography.
The useful starting point is a separation of concerns. An issuer makes a claim; a holder keeps and presents it; a verifier checks it under a trust policy. A registry may help locate keys or status information. The W3C Verifiable Credentials Data Model 2.0 lists trusted databases, government databases, decentralized databases and distributed ledgers as possible registries. A blockchain is one option, not a requirement of verifiable credentials.
I would choose the trust model before the database. If one employer controls employee access, an ordinary identity provider may be simpler. If independent institutions need to share verification material without one operator, a ledger may be worth evaluating. Our private blockchain guide and tokenization explainer provide background, but neither replaces the need to explain who is trusted and why.
Identity, authentication and authorization are different checks
Identity proofing asks who or what is being enrolled, and at what confidence. Authentication asks whether the current caller controls an authenticator or key. Authorization asks whether that caller may perform a particular action now. A signature can help authenticate the controller of a key without establishing the real-world truth of a credential or granting permission to use a service.
Consider an employee credential. A valid signature from a trusted employer may establish that the employer issued a statement. The verifier must still check whether the credential is current, whether the role meets its policy, and whether the presentation is bound to the person or device making the request. A former employee can still possess an old signed credential. That is why status and expiry are operational requirements, not optional extras.
An app also needs a session and access-control policy after verification. Do not treat a successful wallet connection as blanket approval for payments, record exports or administrative changes. Our cybersecurity compliance overview and mobile payment security guide are useful adjacent reading. Identity evidence supports a decision; it is not the whole decision.
How decentralized identifiers work
A decentralized identifier, or DID, identifies a subject through a particular DID method. DID Core 1.0 is a W3C Recommendation dated 19 July 2022. A DID includes a scheme, a method name and a method-specific identifier. The method defines how identifiers and associated documents are created, resolved, updated or deactivated. Different methods therefore have different infrastructure and privacy properties.
The DID document can describe verification methods and relationships such as authentication or assertion. It is not a complete identity file, and it need not contain a person’s name or date of birth. The DID subject and controller can also be different. Someone controlling a document’s keys is not automatically the same entity the identifier describes.
Before selecting a method, ask how resolution works without the vendor, how keys rotate, what happens during an outage, and whether identifiers become correlatable across services. A method backed by a blockchain inherits that network’s governance, availability and transaction-cost assumptions. A method without a chain has other dependencies. Evaluate those trade-offs directly rather than assuming that decentralization is a single feature.
What belongs in a credential and a presentation
Verifiable Credentials 2.0 became a W3C Recommendation on 15 May 2025. Its data model describes credentials containing claims, metadata and a securing mechanism. A university could issue an education claim; an employer could issue a role claim. A cryptographically verifiable format lets software detect tampering and establish provenance under the chosen proof mechanism. It does not guarantee that the issuer checked the underlying fact correctly.
A presentation is what a holder supplies to a verifier for a particular interaction. It can carry one or more credentials or derived information. Keep the two concepts distinct in your product: obtaining a credential, storing it and presenting it are different flows with different failure modes. An issuance success does not establish that every verifier will accept the credential.
Agree on the whole interoperability profile: credential format, cryptographic suite, issuer trust, schemas, holder binding, status mechanism and transport. Two products both saying “supports verifiable credentials” is not enough. Our blockchain development services guide and development-language overview can help organize engineering questions, but the actual profile should be tested between the wallets and verifiers you intend to support.
An issuance-to-verification flow you can review
Begin with enrollment. The issuer decides what evidence supports the claim, confirms the intended recipient and records the assurance level. It then issues a credential under an agreed format and policy. The holder receives it in a wallet or another holder application. A lost-device recovery route should already exist before this reaches real users.
At presentation time, the verifier asks for a defined set of information and explains the purpose. The wallet shows the request, the recipient and the disclosures. The verifier checks the presentation, issuer trust, validity period, holder binding where required, status and replay protection. It then applies its own authorization rule. A verified credential is an input to that rule, not a command to bypass it.
Transport protocols are now less speculative. The OpenID Foundation approved OpenID for Verifiable Presentations 1.0 in July 2025 and OpenID for Verifiable Credential Issuance 1.0 in September 2025. These final specifications address presentation and issuance flows. They do not mandate a blockchain or automatically settle which issuers a business should trust.
Keep personal documents off a public ledger
A public ledger is a poor default place for passport scans, biometric templates, addresses or a complete customer record. Replication and persistence make mistakes hard to contain. Encrypting personal data before publishing it does not erase metadata, guarantee future secrecy, or make retention and deletion questions disappear. Even a hash can create linkage or reveal a predictable value through guessing.
Prefer a design where personal claims stay with the holder or an appropriately controlled off-chain service. Publish only the minimum verification or governance material the architecture needs, after a privacy review. Decide what an observer can infer from key updates, timestamps, registry lookups and transactions. Avoid creating a universal identifier that quietly joins a person’s banking, employment and shopping activity.
For each field, write down who receives it, why it is required, how long it stays and how deletion or correction works. Our healthcare blockchain overview and education use-case guide illustrate areas where records are sensitive. They should lead to more careful handling, not an assumption that the chain makes storage safe.
Selective disclosure is useful, but not automatic anonymity
The ideal age check asks for the fact needed by the service, such as being above a threshold, instead of collecting a full identity document. Selective disclosure can reduce the information revealed. Some proof mechanisms can support derived statements or unlinkable presentations, but these properties depend on the format, cryptography and profile you deploy. A generic signed credential does not automatically hide unwanted fields.
The VC 2.0 privacy considerations warn about identifier-based, signature-based and metadata-based correlation. Reusing a global subject identifier can undermine an otherwise careful disclosure design. So can an issuer-specific status request or an unusually precise timestamp. Evaluate the complete interaction, including logs and analytics, rather than judging privacy from the credential payload alone.
In the user interface, show the claims actually requested and distinguish required from optional information. Give a meaningful refusal path. A screen saying “share credential” is too vague when one verifier needs only an age threshold and another asks for a legal name and address. Minimized disclosure is a product requirement and a testable outcome, not just a protocol label.
Revocation, suspension and recovery need an owner
A credential can be correctly signed and no longer acceptable. Licences expire, employment ends and devices are stolen. A production design needs a documented status policy: who can change status, how quickly verifiers see it, how cached results behave, and what happens if the status service cannot be reached. High-risk actions should not quietly fall back to unlimited acceptance during an outage.
The W3C Bitstring Status List v1.0 Recommendation provides a compact mechanism for publishing credential status. Its privacy discussion explains why a unique status URL per credential can let an issuer correlate the holder, verifier and time of use. Shared lists and caching can reduce some exposure, but the specification also warns about correlation through indexes and other identifiers. “Uses a status list” is not the same as “cannot be tracked.”
Recovery is a separate workflow. Document how a user replaces a lost phone, how the old key or credential stops working, and how an attacker is prevented from abusing recovery. Recovery can involve re-proofing identity, issuer reissuance, hardware-backed keys or other controls, depending on the use case. Never promise permanent self-sovereign control without explaining the real support and recovery dependencies.
Where blockchain helps, and where a simpler system wins
A ledger can be useful when several independent organizations need a shared record of issuer keys, governance actions or verification references and cannot agree on a single operator. The case becomes stronger when the membership and update rules are explicit. It becomes weaker when a centralized administrator still decides everything while the chain adds latency, operating cost and a second incident surface.
Compare three designs before committing: an existing identity provider, a credential ecosystem using conventional registries, and a credential ecosystem with a ledger. Score each on onboarding, privacy, recovery, availability, interoperability, governance and exit cost. Public versus permissioned is another decision, not a synonym for secure versus insecure. Ask who runs nodes and who can change the rules.
Examples in our blockchain trends overview and our blockchain company comparison can start vendor discovery. Do not select a supplier merely because it advertises decentralization. Ask for an architecture diagram showing precisely which operations require the network and what your service does when that dependency fails.
Practical use cases, with limits attached
Education and professional qualifications are a natural fit for issuer-signed claims that a holder presents elsewhere. The difficult part is not making a diploma-shaped object. It is recognizing legitimate institutions, keeping accreditation current and handling corrections or disputed records. An institution’s digital signature should not be mistaken for an independent guarantee of educational quality.
Workforce and partner access can use portable role or training evidence, but permissions must remain current and scoped. A contractor proving training completion should not automatically receive production access. In regulated onboarding, a reusable credential may reduce repeated data collection only if the relying party accepts its issuer, assurance, freshness and legal basis. It does not remove jurisdiction-specific obligations.
Consumer messaging and communities may want pseudonymous membership rather than verified legal identity. Choose the assurance level the actual risk needs. Our blockchain messaging overview and chat-development company guide are adjacent starting points. Do not force a passport check into a low-risk community merely because an identity wallet can support one.
EU digital identity: a deadline is not universal availability
The European Commission EUDI framework page says Member States are to provide EU Digital Identity Wallets by the end of 2026. The Commission FAQ explains that use is voluntary and describes cross-border recognition and selective sharing of attributes. As of this October 2026 update, the end-of-year deadline must not be rewritten as a claim that every intended wallet and verifier is already available everywhere.
For a product team, the useful task is to map the applicable wallet and relying-party requirements, supported credential formats, certification expectations and rollout dates in the countries it serves. A national pilot, technical reference implementation and generally available service are different states. Confirm the actual supported flow with the provider before advertising it to users.
Equally important, EUDI is not evidence that blockchain is mandatory for digital identity. A legal trust framework, certification process and common technical profile do different jobs from a distributed ledger. Treat the regulation as a specific ecosystem to integrate with, not a marketing shortcut for claiming that any blockchain wallet is legally compliant.
AI agents add an authorization problem, not a blockchain shortcut
AI agents can retrieve data and take actions through software tools, which makes their identity and delegated permissions important. NIST NCCoE Agentic AI Identity and Authorization project is developing practical guidance and example implementations. Its resource hub describes a February 2026 concept paper and an intended SP 1800-series practice guide. This is active project work, not a completed universal certification for agent identity.
An agent credential could identify the software operator or convey a limited delegated role. It does not prove that the model will follow instructions, resist prompt injection or understand a transaction. A genuine credential can still belong to software behaving badly. Keep the accountable human or organization, the agent instance, its allowed actions and the resource boundary separately visible.
Use short-lived, narrowly scoped permissions; require approval for consequential actions; record what was requested and executed; and provide a fast way to revoke access. Bind authority to the intended service and operation rather than giving an agent a reusable owner-level secret. The current mobile app trends guide discusses agentic apps, while our app development tools guide helps frame the client implementation. Neither a DID nor a chain replaces application-level controls.
A build checklist before you fund a pilot
Write a one-page trust model naming issuers, holders, verifiers and governance owners. State what each signature proves and what it does not. Then define the minimum acceptable claim set and the business rule that consumes it. If the team cannot describe a rejected presentation, an untrusted issuer and a revoked credential, the happy-path demo is not enough.
Choose an interoperability profile and test it between independent implementations. Include unsupported wallets, malformed credentials, expired proofs, replayed presentations, offline operation and status-service failure. Test account recovery with real support staff. Check that analytics and logs do not recreate the personal-data collection you were trying to avoid.
Budget for key management, issuance operations, verifier integration, accessibility, security review, monitoring and incident response. A chain transaction fee is only one potential cost. Our app cost calculator can organize an initial scope, but it is not a quote for a production identity ecosystem. Require vendors to price recovery, maintenance and migration as well as the first wallet screen.
The best first pilot has one issuer, a narrow credential, a small set of willing verifiers and a measurable outcome such as reduced document collection. Set exit criteria before launch: acceptable completion rate, recovery time, disclosure volume and verification failures. Add a ledger only if it solves a demonstrated coordination problem that the simpler design cannot satisfy.
Frequently asked questions
Does digital identity require a blockchain?
No. W3C verifiable credentials can use different registries, including trusted databases and distributed ledgers. A blockchain is an architectural choice, not a requirement of the credential data model.
Is a DID the same as a verifiable credential?
No. A DID is an identifier governed by a method. A verifiable credential carries claims from an issuer. A presentation is information supplied to a verifier for an interaction.
Should identity documents be stored on a public blockchain?
Generally, keep personal documents and sensitive claims off a public ledger. Replication, persistence, metadata and linkage create risks that encryption alone does not remove. Publish only the minimum material the reviewed architecture needs.
Can a verifiable credential prove that a claim is true?
A valid cryptographic check can establish provenance and detect tampering under the chosen mechanism. The verifier still needs to trust the issuer, its proofing process, the credential status and the assurance level.
Does selective disclosure guarantee anonymity?
No. It can reduce disclosed information, but identifiers, signatures, status checks and metadata can still create correlation. Privacy depends on the complete implementation and the cryptographic profile.
Are EU Digital Identity Wallets already available everywhere?
Do not assume that. The European Commission says Member States should provide wallets by the end of 2026. Check the current national rollout and supported relying-party flow rather than treating the deadline as universal live availability.
Can blockchain make an AI agent safe to act for a user?
No. An identity record does not guarantee safe behavior or grant unlimited authority. AI agents need scoped authorization, approval for consequential actions, audit trails and revocation, whether or not a ledger is used.
Bottom line: start with issuer trust, minimal disclosure and recoverable access. Credentials and wallets can improve a workflow without a blockchain. Use a ledger only when its shared-governance benefits outweigh its extra dependencies.
Leave a Reply