Verifier Integration

A verifier integration asks a defined trust question, requests proportionate evidence, validates the response, and returns an explainable policy outcome to the relying institution. It should not collect a complete identity profile merely because more data is technically available.

Define the relying purpose

The verifier should document:

• the transaction and relying party;
• the decision that needs evidence;
• acceptable credential types and issuers;
• minimum claims or derived statements;
• assurance, freshness, and holder-binding requirements;
• status and dependency behavior;
• retention and receipt requirements;
• human review or appeal paths;
• the owner of the final institutional decision.

The request must be explainable to the holder and proportionate to the purpose.

Design the request

A credential request can define:

• acceptable formats and credential profiles;
• trusted issuers or trust frameworks;
• required and optional claims;
• alternative credentials or evidence combinations;
• freshness, audience, and transaction binding;
• holder relationship or key-binding requirements;
• purpose and relying-party information;
• response protection and expiry;
• consent and user-experience expectations.

A standards-compliant query can still be excessive. Policy and privacy review remain necessary.

Verification pipeline

A representative verifier performs the following checks:

1. Request integrity — confirm that the transaction is current, authentic, and associated with the correct relying party.
2. Response parsing — reject malformed, ambiguous, or unsupported structures.
3. Credential format validation — apply the exact approved credential profile.
4. Issuer resolution — resolve the issuer and verification material through approved discovery paths.
5. Signature or proof validation — verify integrity using allowed algorithms and key relationships.
6. Credential lifecycle — check validity period, status, replacement, and other current-state conditions.
7. Presentation context — validate nonce, audience, state, time, and replay resistance.
8. Holder relationship — verify the required holder or wallet binding when the credential profile requires it.
9. Disclosure conformance — ensure required claims are present and unrelated data is not treated as necessary.
10. Trust and assurance policy — evaluate issuer scope, credential type, assurance, jurisdiction, and transaction rules.
11. Outcome generation — produce an explainable result and evidence reference.
12. Relying-party decision — allow the institution to apply business, legal, safety, or access rules outside the credential protocol.

Verification is not one boolean

A useful result distinguishes among:

Outcome	Meaning
Verified and policy-satisfied	Required technical and trust conditions passed
Valid but insufficient	The artifact is authentic but does not meet the transaction policy
Lifecycle failure	Expired, suspended, revoked, or superseded
Untrusted source	Issuer or credential type is outside the approved trust scope
Context failure	Stale, replayed, incorrectly addressed, or not transaction-bound
Holder relationship failure	Required binding was not proven
Unsupported	Format, algorithm, schema, or profile is not accepted
Indeterminate	An authoritative dependency is unavailable or inconclusive
Review required	Policy routes the result to an authorized human process

The relying party should not reinterpret an indeterminate or unsupported result as successful verification.

Trust policy

The verifier must know not only who issued the credential, but whether that issuer is trusted for that credential type and purpose. Trust can be scoped by:

• jurisdiction and sector;
• credential definition;
• assurance level;
• algorithm and key type;
• status mechanism;
• holder-binding model;
• transaction risk;
• validity and freshness;
• certification or framework membership where independently evidenced.

Trust registries and policy versions are controlled assets. Their public representation should not reveal customer acceptance logic or private relationships.

Privacy-preserving verification

The verifier should minimize:

• requested claims;
• presentation frequency and correlation identifiers;
• retained credential material;
• source documents and proofing evidence;
• logs containing personal data;
• distribution of verification receipts.

Where practical, the relying application should receive only the claims and policy outcome required for the decision rather than the complete presentation artifact.

Receipts and evidence

A verification receipt can identify:

• request and transaction reference;
• verifier and relying party;
• declared purpose;
• credential type and issuer reference;
• checks performed and policy version;
• disclosed claim names or minimized result;
• status and dependency outcomes;
• final verification category and timestamp.

It should not become a reusable identity dossier. Retention and access must be purpose-bound.

Dependency and failure behavior

The integration profile should define whether to fail closed, retry, or route to review when:

• issuer metadata cannot be resolved;
• a key is missing, retired, or unapproved;
• status cannot be checked;
• the presentation is incomplete or stale;
• clocks, caches, or metadata versions disagree;
• an external trust registry is unavailable;
• a format is syntactically valid but outside the pinned profile.

Silent downgrade from a required control to a weaker check is not acceptable.

Testing expectations

Verifier testing should include:

• valid and invalid signatures;
• wrong issuer or credential type;
• expired, revoked, suspended, and superseded credentials;
• unsupported algorithms and malformed disclosures;
• wrong audience, nonce, state, or transaction;
• replayed and duplicated responses;
• missing holder binding;
• excessive or unexpected claims;
• metadata rotation and cache refresh;
• dependency outage and indeterminate results;
• policy-version migration.

Verifier readiness checklist

Before production approval, confirm that:

• the trust question and final decision owner are explicit;
• requests collect only necessary evidence;
• issuer and credential trust scopes are governed;
• algorithms, formats, status, and holder binding are pinned;
• outcomes are explainable beyond a simple valid/invalid flag;
• failure-closed and review behavior are defined;
• receipts are minimized and retained appropriately;
• negative and replay tests pass;
• policy and metadata changes are monitored;
• support, incident, and appeal responsibilities are assigned.

Public documentation boundary

This page does not expose production verifier metadata, customer request definitions, private trust lists, acceptance thresholds, fraud rules, policy code, client registrations, receipt schemas, or exception procedures.

See Verification and Policy, Trust and Policy, and OpenID for Verifiable Credentials.