What is a verifiable credential ecosystem?

This page explains how a verifiable digital credential ecosystem works.

If you are new to digital credentials, read Verifiable credentials first. That page explains what a verifiable credential is and why cryptographic verification matters. This page builds on that foundation by focusing on the ecosystem roles, the trust layer, and the interaction flow between participants.

What is a verifiable credential ecosystem?

A verifiable credential ecosystem is the set of participants, rules, and technical components that allow digital credentials to be:

• issued by a trusted organisation
• held by an individual or organisation
• presented when proof is needed
• verified by another party
• trusted across systems, organisations, and jurisdictions

At a minimum, most ecosystems include four core roles:

• Issuer: creates and signs the credential
• Holder: receives, stores, and presents the credential
• Verifier: requests and checks the credential
• Trust framework or trust registry: provides the governance and trust signals that help participants decide which issuers, wallets, keys, and rules to trust

These roles work together to move trust from fragmented, manual checks into a reusable digital model.

Why this ecosystem model matters

A verifiable credential is not useful on its own. Its value comes from being part of an ecosystem where multiple parties can rely on it consistently.

That ecosystem model matters because it helps participants answer four essential questions:

1. Who issued this credential?
2. Can I trust that issuer?
3. Has the credential been changed, expired, or revoked?
4. Is the holder sharing the right information for this transaction?

A well-designed ecosystem makes those questions easier to answer in a secure, privacy-aware, and scalable way.

The four core roles in a verifiable credential ecosystem

Issuer

An issuer is the organisation that creates and signs a credential.

The issuer is the source of the claims inside the credential. For example, an issuer might be:

• a government issuing a mobile driver’s licence
• a university issuing a degree credential
• a bank issuing a proof-of-account or customer credential
• an employer issuing an employee ID credential

The issuer is responsible for:

• confirming the underlying data is accurate
• defining what the credential contains
• signing the credential so others can verify its authenticity
• managing status over time, such as expiry, suspension, or revocation
• operating within the rules of the relevant trust framework

What value does the issuer gain?

Issuers benefit because they can provide credentials that are:

• portable, so the holder can reuse them across services
• tamper-evident, because the credential is cryptographically signed
• easier to verify, reducing follow-up checks and manual validation
• more interoperable, when aligned to shared standards and trust rules

For issuers, this can reduce operational overhead, improve service delivery, and extend the usefulness of authoritative data beyond a single channel or portal.

Holder

A holder is the person or organisation that receives and controls the credential.

The holder typically stores credentials in a wallet application and chooses when to present them. The holder is not the source of the credential’s authority. Instead, the holder is the party that has been given the credential and can use it to prove something about themselves.

Examples include:

• a citizen holding a mobile driver’s licence
• a student holding a degree credential
• an employee holding a digital staff ID
• a business holding a licence or accreditation credential

The holder is responsible for:

• receiving and storing the credential
• keeping access to it secure
• reviewing presentation requests
• deciding when to share it
• consenting to the disclosure of requested information

What value does the holder gain?

Holders benefit because verifiable credentials can give them:

• more control over when and where their information is shared
• more convenience across repeated interactions
• better privacy, especially when selective disclosure is supported
• less repetition, because the same credential can be reused across services
• greater transparency, because they can see what is being requested

For holders, the ecosystem works best when trust does not require oversharing.

Verifier

A verifier is the organisation that requests and checks a credential.

The verifier relies on the credential to make a decision, such as whether to:

• allow access to a service
• approve an application
• confirm age or identity
• validate a qualification or licence
• onboard a customer or employee

The verifier is responsible for:

• requesting the right information for the interaction
• validating the credential’s authenticity and integrity
• checking whether the issuer is trusted under the relevant framework
• checking status information such as expiry or revocation
• applying business or policy rules to the verified result

What value does the verifier gain?

Verifiers benefit because verifiable credentials can provide:

• stronger assurance, through cryptographic verification
• faster decisions, with less manual review
• reduced fraud risk, because tampering is detectable
• better privacy alignment, by collecting only what is needed
• less integration complexity, when ecosystems use shared standards and trust rules

For verifiers, the key value is not just seeing data, but being able to trust where it came from and whether it is still valid.

Trust framework or trust registry

A verifiable credential ecosystem also needs a trust layer.

This is often described as a trust framework, and in some implementations it is supported by a trust registry.

A trust framework is the set of legal, policy, operational, and technical rules that define how the ecosystem works. It answers questions such as:

• who is allowed to issue credentials
• what standards or schemas must be followed
• what assurance requirements apply
• how participants are onboarded and governed
• how keys, identifiers, and trust anchors are managed
• how disputes, compliance, and liability are handled

A trust registry is a technical mechanism that can publish or make available trust information used by ecosystem participants. Depending on the ecosystem, it may contain information about:

• trusted issuers
• trusted verifier organisations
• approved wallet providers
• public keys or trust chains
• supported schemas or credential types
• accreditation or governance status

Why distinguish trust framework from trust registry?

These terms are related, but they are not the same.

• A trust framework is the broader governance model.
• A trust registry is one technical way to expose trust information inside that model.

Some ecosystems may use a formal registry. Others may rely on federation metadata, certificate chains, government trust lists, or another trust distribution mechanism.

What value does the trust layer provide?

The trust layer benefits everyone:

• Issuers gain a recognised path to ecosystem acceptance
• Holders gain confidence that their credentials will be widely usable
• Verifiers gain a reliable way to determine who and what to trust
• Ecosystem operators gain a scalable way to govern participation and assurance

Without a trust layer, a verifier may be able to confirm that a credential was signed, but not whether the signer should be trusted for that credential type.

Credential lifecycle

Credential lifecycle refers to the stages a credential goes through from creation to eventual expiry or revocation. Understanding this lifecycle is key to building secure and privacy-preserving digital credential solutions.

At a high level, the interaction flow is simple:

1. The issuer creates and signs a credential
2. The holder receives and stores it
3. The verifier requests proof from the holder
4. The holder presents the credential or a derived proof
5. The verifier checks the credential, the issuer trust chain, and status information
6. The verifier makes a decision

The trust framework sits around this exchange and defines the rules that make the result meaningful.

Beyond issuance and presentation, credential lifecycle events may include updates, revocation or expiry. The ecosystem must support these lifecycle events to maintain trust over time:

• Credential update: The issuer may need to update a credential, such as adding new claims or correcting information. The ecosystem should support a secure way to issue an updated credential and manage the lifecycle of the old one.
• Credential revocation: If a credential is compromised, no longer valid, or the holder’s relationship with the issuer changes, the issuer may need to revoke it. The ecosystem should support a way for verifiers to check revocation status during verification.
• Credential expiry: Some credentials are only valid for a certain period. The ecosystem should support expiry information and ensure verifiers can check it.

Ecosystem flow at a glance

What happens during issuance?

Issuance is the process where an issuer creates a credential for a specific holder.

During issuance, the issuer typically:

• confirms the subject’s eligibility
• prepares the credential data
• signs the credential using its cryptographic keys
• delivers the credential to the holder’s wallet
• records or publishes any needed status information

The result is a credential that the holder can later present.

Issuance flow

What happens during presentation and verification?

Presentation is the process where the holder shares proof with a verifier.

Verification is the process where the verifier checks that proof and decides whether it can rely on it.

During this interaction, the verifier may check:

• whether the credential is authentic
• whether the issuer is trusted
• whether the credential is expired or revoked
• whether the proof matches the requested data
• whether holder binding or other policy requirements are satisfied

The holder may present:

• the full credential
• selected attributes
• a derived proof, depending on the credential format and ecosystem design

Verification flow

What each role needs from the others

Thinking in architecture terms, each role depends on the others in different ways.

What the issuer needs

The issuer needs:

• a way to identify the holder
• a credential format and schema
• signing keys and trust anchor relationships
• a delivery channel to the holder
• a status management approach
• governance rules that define when it is authorised to issue

What the holder needs

The holder needs:

• a wallet or holder application
• a secure way to receive credentials
• a way to review requests from verifiers
• a way to present credentials or proofs
• confidence that the ecosystem protects privacy and usability

What the verifier needs

The verifier needs:

• a way to request the right proof
• a way to validate signatures and credential structure
• access to trust information
• access to status information when required
• policy rules that define what is acceptable for the use case

What the trust layer needs

The trust layer needs:

• governance and operating rules
• participant onboarding and accreditation processes
• trust anchor management
• mechanisms to publish or distribute trust information
• change management across standards, participants, and assurance requirements

What makes an ecosystem trustworthy?

A verifiable credential ecosystem is not trustworthy just because it uses cryptography.

It becomes trustworthy when technical verification is combined with governance.

That usually includes:

• cryptographic integrity, so credentials cannot be altered undetectably
• issuer authenticity, so verifiers know who signed the credential
• status management, so expired or revoked credentials can be identified
• trust anchors and frameworks, so verifiers know which issuers are accepted
• privacy-preserving presentation, so only necessary data is shared
• clear ecosystem rules, so participants understand obligations and assurance levels

This is why trust frameworks matter so much. Cryptography can prove that a credential was signed. Governance determines whether that signature should be relied on in a real-world context.

Centralised verification versus ecosystem trust

Traditional verification often depends on a central database lookup each time proof is needed.

A verifiable credential ecosystem works differently. The proof travels with the credential, and the verifier can often validate it independently using cryptographic proofs, trust metadata, and status information.

This changes the architecture in important ways:

• trust becomes more portable
• verification can be more scalable
• privacy can improve because fewer central lookups are required
• interoperability becomes more achievable across organisations

The result is not the removal of trust, but the distribution of trust into a framework that can be checked and reused more consistently.

Example: how the ecosystem works for a mobile driver’s licence

A mobile driver’s licence ecosystem might work like this:

• A transport authority acts as the issuer
• A citizen acts as the holder
• A police officer, retailer, or service provider acts as the verifier
• A government trust framework defines which issuers, keys, wallets, and policies are accepted

In practice:

• The transport authority issues an mDL to the citizen
• The citizen stores it in a wallet
• A verifier requests proof of identity, age, or driving entitlement
• The citizen presents the required information
• The verifier checks the proof, issuer trust, and status
• The verifier accepts or rejects the interaction based on policy

That same model can apply to other credential types, including education, health, workforce, and financial use cases.

Frequently asked questions

What is the difference between an issuer and a verifier?

An issuer creates and signs a credential. A verifier requests and checks it.

Is the holder always a person?

No. In many ecosystems the holder is a person, but it can also be an organisation, device, or software agent, depending on the use case and trust model.

What is the difference between a trust framework and a trust registry?

A trust framework is the broader governance model for the ecosystem. A trust registry is one technical mechanism that can publish trust information used within that framework.

Can a verifier trust any digitally signed credential?

No. A verifier must usually confirm both that the credential is cryptographically valid and that the issuer is trusted for that credential type under the relevant framework.

Does the issuer need to be online every time a credential is verified?

Not always. In many verifiable credential models, the verifier can validate the credential without contacting the issuer directly for every transaction, although status checks or trust resolution may still be required depending on the design.

Why is the trust layer necessary?

Without a trust layer, a verifier may know that a credential was signed, but not whether the signer is recognised, authorised, or governed appropriately for the use case.

Summary

A verifiable digital credential ecosystem is made up of issuers, holders, verifiers, and a trust layer that governs how they interact.

• Issuers create and sign trusted credentials
• Holders receive, store, and present them
• Verifiers request and validate proofs
• Trust frameworks and trust registries provide the governance and trust signals that make ecosystem-wide verification possible

Together, these roles allow trust to move with the credential, rather than staying trapped in isolated databases and manual checks.