A verifier checks whether a presented credential is genuine, unaltered, issued by an acceptable authority, current, and suitable for an authorization decision. Cryptography establishes authenticity; governance establishes whether the issuer deserves trust. section 16.10 section 16.3
During presentation, the verifier confirms the issuer, credential integrity, wallet binding, and revocation status. The credential is bound cryptographically to a wallet, not directly to a person; that link depends on identity proofing and wallet controls. section 16.2.1
A verifier’s operational responsibilities include:
- Accept presentations through supported issuance and presentation protocols while keeping verification steps consistent. section 16.7
- Check issuer trust against recognized trust stores and applicable governance frameworks before using claims in policy evaluation. section 16.10 section 16.3
- Normalize verified claims into stable attributes so policies evaluate attributes rather than credential formats. section 16.10
- Support revocation, expiration, privacy-preserving attribute requests, and controlled exceptions when presentations are incomplete. section 16.10
Auditor credential at an access request
When an auditor presents a credential to ACME, the verifier checks the signature, wallet binding, expiration, revocation status, and issuer accreditation. It then supplies normalized claims to policy evaluation rather than trusting the holder or maintaining a partner directory. section 16.2.1 section 16.3
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.
Use the trust triangle to distinguish the issuer’s signed claims, the holder’s presentation, and the verifier’s independent validation. section 16.2.1



