A digital wallet holds verifiable credentials and generates signed presentations of the claims needed for a request. In decentralized identity, trusted issuers sign credentials, holders keep them in wallets, and relying parties verify the presentations cryptographically. The wallet transports evidence but is not itself the source of trust: a verifier evaluates the issuer, integrity, wallet binding, revocation status, and whether the claims satisfy policy. section 2.5.3 section 16.2.1
A wallet is bound to a device or cryptographic holder rather than intrinsically to a person. Device biometric unlock can help ensure that only the device’s rightful controller presents a credential, while issuer identity proofing helps establish that the credential claims belong to that controller. These are distinct controls: cryptography establishes issuance to a wallet; the person-to-wallet link is established outside the credential. section 16.2.1
For authorization, a wallet commonly participates in this claim-driven flow:
- Receive an attribute query from a Policy Enforcement Point (PEP) identifying the claims needed for an access decision. section 16.5
- Select relevant claims from one or more credentials under the holder’s control. section 16.5
- Create a signed presentation containing only the required information; the presentation is a derivative object, not the credential itself. section 16.5
- Allow the verifier to validate the presentation and provide normalized claims for Policy Decision Point (PDP) policy evaluation. section 16.5
External auditor access without account setup
A short-term auditor’s wallet presents an employment credential from AuditsRUs and a CISA-R certification from NISA. The PEP verifies signatures, expiry, revocation, recognized issuers, and wallet binding; the PDP evaluates employer, certification, and engagement-time policies. If they pass, the auditor receives limited log-viewing access for the assignment, without a local account or lingering access after it ends. section 16.2.2
Wallet presentations let organizations exchange authoritative attributes across boundaries without directory synchronization, federation, or prior agreements. A verifier requests claims rather than a particular credential, preserving holder choice over credential selection and limiting disclosure to policy-relevant information. Trust frameworks can still identify which issuers or credential types a relying party accepts. section 2.5.3 section 16.5
Figure 16.3 Claim-based credential presentation. Upon receiving an access request, the PEP requests the specific attributes it needs for the authorization decision. The holder’s wallet receives the attribute query, selects the necessary claims from one or more credentials, and assembles a signed presentation. The PEP verifies the presentation and prepares the claims for policy evaluation.
Trace how an access request becomes an attribute query, a wallet-selected presentation, verified claims, and policy input. section 16.5
In a multi-tenant collaboration platform, tenants can issue project-role credentials containing tenant, project, and role information. Participants present them from wallets; the platform verifies the issuing tenant and credential status, then enforces project-specific permissions. The tenant retains role lifecycle control by updating or revoking credentials instead of the platform maintaining customer and partner account directories. section 16.8.4
