Verifier

A verifier is often the same organisation as the relying party requesting the credential, but the roles are distinct: the relying party decides what to ask for and what to do with the result, while the verifier is the technical function that checks the signature, the Trusted List entry of the issuer, and the revocation status before that result can be trusted.

In an OpenID4VP exchange, a verifier sends a presentation request describing which credential and claims it needs, receives the holder's response, and then runs three checks before accepting it: that the signature matches the issuer's published key, that the issuer appears on the relevant Trusted List for the credential type presented, and that the credential has not since been revoked according to its status list. Only after all three pass does the verifier hand a trusted result back to the relying party, for example confirming that a person is over eighteen or holds a valid professional qualification, without ever seeing claims the holder did not choose to disclose.

Because verification is a well-defined, repeatable check rather than a judgement call, the same verifier logic can serve many different relying parties and credential types, which is why organisations often buy verification as a service rather than building it once per use case. A poorly implemented verifier, one that skips the Trusted List check or caches revocation status too long, is a common source of trust framework failures even when the credential and the issuer are both entirely legitimate.