A credential holder possesses a verifiable credential and uses a wallet or similar mechanism to assemble and send a presentation when access is requested. The holder carries claims across organizational boundaries; it does not create the trust in those claims. Trust depends on the issuer’s signature, authority, and the verifier’s governance rules. section 16.2.1 section 16.10
A presentation lets the holder respond to a verifier’s attribute request, potentially disclosing only the needed attributes. The verifier checks the issuer, integrity, wallet binding, revocation, and validity before normalized claims become context for an authorization policy. section 16.2.1 section 16.10
A holder participates in an access decision by:
- Storing credentials delivered through an issuance protocol and protected by wallet standards. section 16.7
- Assembling one or more credentials into a presentation after a policy enforcement point (PEP) requests attributes. section 16.8
- Sending a signed presentation through a supported protocol; the verifier validates it before the policy decision point (PDP) evaluates normalized claims. section 16.7
- Relying on device controls and issuer identity proofing to help connect control of a wallet to a person, while recognizing that the credential itself binds to the wallet rather than the person. section 16.2.1
External auditor access
An issuer can give Angela an employment credential stating that she is an active Security Auditor. When Angela requests ACME access, her wallet presents the credential. ACME verifies the issuer’s proof and revocation status, then evaluates the employment and role claims against policy rather than trusting Angela’s assertion alone. section 16.2 section 16.2.1
Figure 16.1 The verifiable credential trust triangle. The issuer, AuditsRUs, creates and signs the credential. The holder, Angela, carries and presents it. ACME verifies the signature and uses the data in the credential as context when it evaluates policy.
The trust triangle separates the holder’s transport and presentation role from the issuer’s claim-making role and the verifier’s policy evaluation role. section 16.2.1
This pattern reduces the need to synchronize partner directories or create accounts for every external participant. A PEP can request only policy-relevant attributes, while a PDP applies consistent rules to verified claims regardless of the credential protocol or issuer format. section 16.2.1 section 16.8
