Skip to content
DISHA 4.0 HCOS

Trust & Verification

In design — architecture defined

Keep achievements organized and decide when to share them.

A personal space to receive, organize and present credentials

The Credential Wallet is a holder-oriented experience for managing digital achievements. It can help users collect credentials from participating issuers, review their details, organize them for career or learning goals, and present selected claims when an opportunity requires evidence. Wallet functionality depends on supported credential formats, issuer integrations and verification services.

In design — architecture defined

Build a portable record of achievements and share relevant evidence only when you choose.

Wallet architecture is defined; the portable wallet is not yet live.

In depth

01

A user-controlled credential library

The wallet should provide a clear inventory of credentials with issuer, achievement, issue date, expiry, status and verification details. Users should be able to search, filter, group and review items without making every credential public. Expired or unverifiable items should remain understandable rather than silently disappearing.

02

Present with purpose

A presentation request should state who is asking, why the information is needed, which claims are requested and how long the recipient may retain them if known. The holder reviews the request and confirms before sharing. Where supported, disclose only the necessary claims instead of an entire credential or profile.

03

Organize for pathways

Users may group credentials around a target role, learning pathway, professional portfolio or application. The interface can identify relevant credentials, but it should not claim that a credential guarantees eligibility or employment. The holder decides which evidence best represents their experience.

04

Import, backup and recovery

Support only documented import/export formats and secure backup mechanisms. Explain whether credentials are stored locally, in a managed account or through a hybrid approach. Recovery should not expose private keys or permit unauthorized account takeover. Lost-device and account-recovery procedures must be tested.

05

Sharing transparency

Provide a history of presentations where technically and legally appropriate: recipient, purpose, claims shared, timestamp and status. Give users controls to revoke future access where supported, while being honest that a recipient may have retained a copy already shared.

How it works

Step 1ReceiveAccept an issued credential from a participating source.
Step 2ReviewCheck issuer, claim, date and status.
Step 3OrganizeAdd it to a collection or pathway.
Step 4PresentApprove a specific request and share selected information.
Step 5ManageReview history, expiry and available access controls.

Capability domains

Credential inventorySearchable record list and detailed credential view.
Issuer and status detailReadable trust, validity and verification context.
Purpose-based collectionsGroups for applications, pathways and portfolios.
Consent-led presentationPreview requested claims and approve sharing.
Secure recoveryDocumented backup and account/device recovery.
Sharing historyUser-visible record of supported presentations.

Frequently asked questions

Is every credential automatically shared?

No. Credential presentation should be user-initiated and scoped to a stated purpose.

Can a recipient keep a credential after I share it?

Recipients may retain information already received; explain this before presentation and do not promise recall unless technically guaranteed.

Trust & Verification

Experience it inside the live platform.

Open the module that carries this capability, or talk it through with the team.