A business owner may need to demonstrate that an enterprise is registered, has completed training or meets a programme condition. Each receiving institution needs evidence it can assess. Verifiable credentials offer a way to carry statements between institutions with cryptographic protection, while keeping the issuing organisation identifiable.

This page explains the main roles, the journey from issuance to use and the checks a service needs before relying on a credential. The examples are proposed teaching scenarios, rather than descriptions of deployed MOSAIC services.

What is a verifiable credential?

A verifiable credential is a digital statement whose authorship and integrity can be checked cryptographically. The W3C Verifiable Credentials Data Model 2.0 defines how claims and their issuers can be represented. A claim can concern a person, organisation or other subject.

An authorised training provider could, for example, issue a statement that a named business owner completed a course. The receiving programme decides whether it accepts the provider and whether the course meets its requirements.

CDPI's Verifiable Credentials technical note explores digitally signed evidence as a shared capability for public and private services. Its practical value comes from making evidence usable outside the institution that originally issued it.

The roles in a credential exchange

Role Function Teaching example
Issuer Makes and issues a protected statement A recognised provider issues a training-completion credential
Holder Possesses the credential and presents it A business owner holds the credential
Verifier Receives and checks the evidence A support programme checks the course and provider
Credential subject The entity the statement concerns The person who completed the course

These roles follow the W3C model. The holder and subject may differ: an authorised representative could present evidence concerning an organisation.

What does a digital wallet do?

A credential wallet helps a holder receive, manage and present digital evidence. Credentials may be kept on a device or accessed through another storage arrangement. CDPI discusses wallets and document-access arrangements in its credentialing guidance.

For a service team, the useful questions concern the person's experience: can they recognise the issuer, understand a request and see what will be shared? Can they recover access after losing a phone? Can they obtain help without exposing unnecessary information?

A payments wallet and a credential wallet perform different functions. A product may combine them, but the ability to send money does not establish its ability to hold or present interoperable credentials.

From issuance to a decision

Stage What happens Responsibility to clarify
1. Establish evidence The issuing organisation checks the underlying condition Which records and checks support the statement?
2. Issue The issuer creates the protected statement and makes it available Who controls issuance, signing keys and correction?
3. Request and present The verifier requests relevant information; the holder presents it How are the requester, purpose and fields explained?
4. Check The receiving system checks proof, applicable validity and status, and the accepted issuer Which results require further review?
5. Decide The programme applies its own rules to the evidence Who owns the decision and handles disputes?

The exchange also needs a protocol. OpenID for Verifiable Credential Issuance 1.0 specifies an issuance API. OpenID for Verifiable Presentations 1.0 specifies how credentials can be requested and presented. Participating institutions still define their service rules.

What verification can establish

A service should record which checks it performs and what each result means.

Check What it can establish What needs another assessment
Cryptographic proof Protected information matches the proof under the expected mechanism Accuracy of the underlying statement
Issuer and verification key Proof is linked to the expected issuer through the agreed key-resolution process Issuer authority and acceptance for this purpose
Validity and status Relevant time conditions and an available status check meet the policy Whether a changing real-world condition remains true
Presenter binding, where required and supported Control of the relevant key Whether all programme conditions are met
Programme validation Evidence satisfies specified service rules Conditions and decisions outside those rules

The W3C Data Integrity specification explains cryptographic protection for authenticity and integrity. The VC Data Model distinguishes verification from deciding whether claims are true and suitable for reliance. Presenter binding depends on the selected format and exchange requirements; OpenID4VP addresses presentations with and without holder-binding proofs.

A successful signature check is one input to a service decision. A statement based on an incorrect source record can carry an error. The process needs an accountable issuer and a way to correct the evidence.

A signature also does not encrypt the information. Confidentiality requires appropriate protection in exchange and storage. Decide who can see the evidence as well as who can verify it.

Expiry, suspension and correction

A credential may have a validity period and a mechanism for reporting changed status. The W3C Bitstring Status List specifies one way to publish information such as suspension or revocation.

Define who changes status, when the verifier checks it and what happens if the status service is unavailable. Assess the age of a cached result against the transaction's risk and the agreed freshness policy.

Correction may require updating a source record and issuing replacement evidence. Make clear how the holder learns of the change and how receiving institutions handle an earlier decision. A revocation mechanism alone does not resolve the person's application.

Share evidence needed for the purpose

Some credential formats support selective disclosure: particular claims can be presented without exposing every field. IETF RFC 9901, Selective Disclosure for JSON Web Tokens, specifies one such mechanism.

This capability needs to be designed and tested. It does not appear automatically in every signed credential or wallet. Showing a qualification result instead of a full record may require a separately issued statement or a suitable proof mechanism.

Compare two teaching requests: one asks for an entire training record; another asks only for a course identifier, completion result and date. Examine whether the second request gives sufficient evidence. Consider logs and whether repeated presentations can be linked across services.

QR codes and offline presentation

A QR code may carry a signed payload, a document reference or an instruction to start an exchange. The design determines what can be checked. Scanning an ordinary web link does not itself establish a cryptographic proof.

CDPI's credentialing note includes signed QR and offline approaches. A deployment must separately plan trusted verification material, status information and permitted cache age. Checking a signature offline should be distinguished from knowing every relevant condition is current.

For assisted or paper-based journeys, consider how evidence is bound to its legitimate presenter and how copied codes are handled. Evaluate those channels against the same service purpose and support requirements.

Compatibility needs an agreed profile

A project needs to agree the credential format, proof mechanism, exchange protocol, claim definitions and applicable status and trust arrangements. Two products supporting credential technology may support different combinations.

OpenID's issuance and presentation specifications accommodate credential-format choices. Test the selected combination across independent issuers, wallets and verifiers, including failure cases. State the versions and profile in the project documentation.

A proposed MOSAIC learning case: business-support eligibility

A local programme accepts evidence that a business owner completed an approved course. Its existing process repeatedly checks certificates with several training providers.

In a proposed pilot, participating providers issue a credential containing the course identifier, completion date and learner reference. The applicant presents required evidence. The programme checks the proof, recognised provider, course and dates, then assesses its other eligibility conditions.

Test accepted evidence, an unrecognised issuer, expired or suspended credentials, source-record errors and assisted access. Measure processing time, verification effort, mistaken rejection and correction outcomes against the existing process.

The exercise separates reusable evidence from programme authority. It does not assume that course completion is sufficient for subsidy eligibility or credit approval.

Guided reading list

For development and institutional context, use the World Bank, Co-Develop and UNDP references in DPI Principles and Resources. Apply those questions to the whole journey, including people who cannot use a wallet.