Digital credential wallet: issuer guide and checklist
A digital credential wallet is a holder-facing repository and presentation tool for receiving, storing and sharing digital credentials. For an issuer, the important question is not whether a product uses the word “wallet.” The important question is whether the intended credential can be delivered, understood, presented and verified without trapping the holder in a fragile workflow.
Wallet readiness therefore needs an acceptance plan. Test the exact credential format, delivery method, holder account, verifier experience, privacy boundary, status behavior and recovery path before making a wallet central to a program.
Short answer: A credential wallet is ready only when the exact issuer-to-holder-to-verifier journey passes delivery, holder-control, presentation, verification, privacy, recovery and exit tests.
Short answer
A credential wallet is ready for an issuer program when it passes six tests:
- The wallet accepts the exact credential format the issuer will deliver.
- The holder can understand who issued the credential and what it represents.
- The holder can present the credential to the intended verifier.
- The verifier can authenticate the credential and evaluate its current
- The workflow limits unnecessary disclosure and explains holder choices.
- The holder and issuer have documented recovery, correction and exit paths.
status and claims.
Passing a visual card between screens is not enough. The program needs an end-to-end result that works for issuer, holder and verifier.
What a digital credential wallet does
The W3C Verifiable Credentials Data Model separates four important roles: an issuer makes claims, a holder possesses credentials, a subject is the entity described by a claim and a verifier evaluates a credential or presentation. The holder may use a credential repository, often called a wallet, to store credentials and generate a presentation for a verifier.
This role separation prevents a common design mistake. A credential is not the same thing as the application that stores it. A wallet is not the authority that decides whether a person earned a credential. A verifier still needs to decide whether the issuer, proof, subject, status and claims satisfy its own policy.
The W3C model also notes that cryptographic verification does not prove that a claim is true or fit for a business decision. It helps a verifier evaluate authenticity and integrity. Trust in the issuer and the meaning of the claim remain separate decisions.
Separate the credential, wallet and verification page
Issuers should name each component in the delivery journey instead of using “digital credential” for all of them.
| Component | Primary job | What it does not prove by itself |
|---|---|---|
| Credential record | Represents an issuer’s claim about a subject or achievement | That every verifier will accept the claim |
| Wallet or repository | Receives, stores and helps the holder present credentials | That the issuer was qualified or the claim is current |
| Visual card | Makes a credential recognizable and usable in a human interface | That the underlying data is authentic |
| Verification page or service | Helps inspect authenticity, issuer, status and visible claims | That the claim satisfies a verifier’s business policy |
| Verifiable presentation | Packages one or more credentials or derived claims for a verifier | That every wallet and verifier supports the same exchange method |
A wallet experience may include several of these components, but the names should not be treated as interchangeable. Document which component is doing which job in the program.
Decide why the program needs a wallet
A wallet should solve a holder or verifier problem. Do not add one only because it appears on a procurement checklist.
Common program jobs include:
- Keeping credentials from several issuers in one holder-controlled place.
- Giving learners or workers a repeatable way to present achievements.
- Supporting machine-readable exchange between compatible systems.
- Helping a holder choose which credential or claim to share.
- Preserving access after a course, job or membership relationship changes.
- Making a credential usable in both a human review and a system workflow.
Write one primary wallet job before selecting the format or provider. A professional association may prioritize long-term member access. A university may prioritize learning mobility. An employer may prioritize presentation to an internal or external verifier. These jobs can require different acceptance tests.
For the broader credential definition and issuer workflow, use Sertifier’s digital credential guide. Keep the wallet project focused on receipt, custody, presentation and recovery.
Define the credential and delivery contract
Compatibility starts with the artifact being delivered. Record:
- Credential format and version.
- Issuer identifier and the method a verifier uses to resolve it.
- Subject or recipient binding.
- Credential type and achievement information.
- Issuance and validity dates when applicable.
- Status or lifecycle mechanism when the program uses one.
- Proof or verification method.
- Delivery method from issuer to holder.
- Expected presentation method from holder to verifier.
Open Badges 3.0 conformance guidance defines properties for achievements and awarded badges and procedures for checking authenticity. W3C Verifiable Credentials define a broader data model for issuer, holder and verifier exchange. A program should identify the exact profile it uses rather than calling every JSON credential or image “standards-compatible.”
The Learning Mobility interoperability guide separates issuance, acceptance, presentation and verification workflows. Use that separation in the acceptance plan. A successful issue response does not prove that a holder accepted the credential or that a verifier can consume a later presentation.
Test holder control and access
The holder experience starts before the credential appears in a wallet.
Check:
- How the holder is notified.
- What identity or account step is required.
- Whether the holder can inspect the issuer and credential before accepting.
- Whether consent and sharing choices are understandable.
- Whether the holder can find, group and present the credential later.
- Whether access survives a changed email address, employer or institution.
- Whether the holder can export or move the credential when the program
promises portability.
Do not describe a credential as holder-controlled when the only working path depends on an institution-owned email address that disappears at graduation or departure. Test a real lifecycle transition before launch.
Test the verifier journey independently
An issuer demo often stops after the credential appears in a wallet. Continue the test from a verifier’s point of view.
The verifier should be able to answer:
- Who issued the credential?
- What subject or holder relationship is represented?
- What achievement, qualification or status is claimed?
- What criteria or evidence gives the claim meaning?
- Is the proof valid for the supported format?
- Is the credential current under the program’s status and validity rules?
- Does the claim satisfy the verifier’s own policy?
Sertifier’s credential verification API guide explains the difference between hosted verification, direct API integration, cryptographic verification and wallet presentation. Use the delivery pattern that matches the verifier job. Do not force every verifier into an API project when a public verification page is sufficient, and do not assume a visual page meets a machine-to-machine requirement.
Include privacy in the acceptance gate
Wallet and presentation design can expose more information than the verifier needs. The W3C model includes data minimization, correlation and sharing risks in its privacy considerations. Translate those concerns into program tests.
Ask:
- Which claims are required for the intended decision?
- Can the holder understand what will be shared and with whom?
- Does the workflow disclose a stable identifier when it is unnecessary?
- Can separate presentations be correlated across contexts?
- What wallet, issuer and verifier logs are retained?
- Who can access recovery or support records?
- What happens when a device is lost or an account is compromised?
Privacy is not a label on the credential. It is the result of the data model, presentation request, wallet behavior, verifier policy and support process.
Design recovery, correction and exit before launch
A holder will eventually lose a device, change an email address, forget a password or discover an incorrect credential. A program also may change vendors or end.
Document separate procedures for:
- Account recovery without silently assigning a credential to the wrong
- Credential correction when recipient or achievement data is wrong.
- Reissue when the original credential must be replaced.
- Expiry and renewal when a claim has a validity period.
- Status changes when the issuer no longer stands behind a claim.
- Holder export or migration when supported.
- Continued verification after a subscription or program ends.
person.
Do not make a recovery promise until the exact path has been tested. Recovery is both a security control and a continuity requirement.
Use this wallet acceptance plan
Run the same plan on desktop and mobile, with a real test holder and a separate verifier.
| Test area | Acceptance evidence | Failure that blocks launch |
|---|---|---|
| Delivery | One approved credential reaches the intended holder once | Wrong holder, duplicate delivery or unexplained missing credential |
| Understanding | Issuer, claim, dates and criteria are readable | Holder cannot tell what was earned or who issued it |
| Storage | Credential remains accessible after sign-out and return | Credential disappears or depends on an undocumented session |
| Presentation | Holder can present through the agreed method | Verifier cannot receive the selected credential or claim |
| Verification | Verifier can authenticate and evaluate current status | Visual card passes while underlying credential fails or is unavailable |
| Privacy | Shared data matches the documented minimum | Hidden or unnecessary claims are disclosed |
| Recovery | Lost-access and correction scenarios have tested owners | Support cannot restore access safely or correct a bad record |
| Exit | The program documents export, migration and verification continuity | Holder access depends on an untested vendor or institution relationship |
Record the exact format, wallet version, browser or device, verifier route, expected result and observed result. Compatibility evidence is dated. Retest it when a format, wallet, verifier or delivery method changes.
Treat wallet cards and verifiable credentials carefully
A downloadable card can be useful for quick human access, but a card image or pass should not automatically be described as a standards-based verifiable credential. Check what data and verification route sit behind the card.
Similarly, blockchain is not required for every credential wallet. Sertifier’s blockchain digital credentials article retains the blockchain explanation role. The wallet decision should focus on the program’s credential format, trust model, holder experience and verifier requirements.
Place Verified Wallet in the correct role
Sertifier’s current Verified Wallet guide describes a recipient flow for verifying credentials, sharing them and customizing a profile. The current help center also documents a downloadable digital wallet card.
These are verified current product-help statements. They do not prove support for every external wallet, credential exchange protocol or verifier. A program that needs an external or standards-specific wallet flow should validate that exact requirement with current documentation and an end-to-end test.
For program teams, Verified is the recipient and presentation surface. The issuer still owns the achievement definition, recipient accuracy, validity rules and support process.
Connect wallet delivery to issuance operations
Wallet delivery should not become an unexplained final step after credentials are created. Connect it to the program’s issuance and reconciliation process.
Track:
- Approved credential issued.
- Delivery invitation or wallet transfer requested.
- Holder acceptance completed or unresolved.
- Presentation path tested.
- Verification result available.
- Recovery or support case opened.
- Correction, expiry or replacement action completed.
The credentialing automation workflow provides the trigger, validation, duplicate and reconciliation controls for automated issuance. Add wallet acceptance as a distinct result rather than assuming that a created credential reached a usable holder state.
Measure the program without inventing portability
Use operational evidence first:
- Credentials offered to holders.
- Successful holder acceptance under the defined test.
- Failed or abandoned acceptance by reason.
- Successful presentations to the intended verifier route.
- Verification failures by format or status cause.
- Recovery and correction cases by cause.
- Time to resolve failed delivery or lost access.
- Export or migration tests completed.
These measures describe the tested program. They do not prove universal interoperability or holder preference. A wallet can work well in one defined ecosystem and fail another requirement.
Roll out one credential and one verifier first
Start with one low-risk credential type, one delivery method and one verifier journey. Test a normal holder, a corrected record, lost access, an expired or otherwise inactive record when applicable and program exit.
Expand only after the first flow has a named owner for:
- Credential definition and issuance.
- Holder support and identity recovery.
- Wallet or repository configuration.
- Verifier policy and technical acceptance.
- Privacy and security review.
- Lifecycle status and corrections.
Then add another credential type, wallet or verifier one at a time. This makes compatibility failures diagnosable and keeps holder promises bounded to tested evidence.
Choose a wallet by the full journey
A digital credential wallet is valuable when it gives a holder a durable, understandable way to receive and present credentials while giving verifiers a reliable path to evaluate them. The issuer’s job is to connect those outcomes, not merely deliver an attractive card.
Define the format, holder, verifier, privacy and recovery contracts. Run the acceptance plan on the exact workflow. Then decide whether the wallet is ready for the program.
To map wallet delivery to your credential program, discuss your credential delivery model.
Map your credential delivery model
Define the credential, holder, verifier, privacy and recovery contracts before selecting a wallet workflow.
Frequently asked questions
Is a digital credential wallet the same as a digital wallet for payments?
No. A credential wallet stores or manages credentials and presentations. A payment wallet manages payment instruments or value. Some user interfaces may look similar, but the data, trust and verification jobs differ.
Does every digital credential work in every wallet?
No. Compatibility depends on the credential format, version, delivery and presentation protocols, wallet implementation and verifier support. Test the exact combination in scope.
Is a wallet required to verify a digital credential?
Not always. A hosted verification page, direct API, cryptographic verifier or wallet presentation can serve different verification jobs. Choose the pattern that fits the holder and verifier workflow.
Does a credential wallet require blockchain?
No. Credential wallets can use different trust and data architectures. Blockchain is one possible component, not a universal wallet requirement.
What should an issuer test first?
Test one approved credential from issuance through holder acceptance, presentation and independent verifier evaluation. Then test duplicate delivery, correction, lost access, lifecycle status and exit.
