Verify credentials

Verification starts with a backend authorization request and completes when a separate wallet posts a presentation. This journey creates the request, hands its request URI to the wallet, and reads the result, which is only successful when every check passes.

Complete first: Bind trust and queries.

Steps and why they come in this order

Step	Why here
1. Pick a verification template	The template decides which query, version and trust apply. Read it before starting a session from it.
2. Create an authorization request	The request creates the verification session. Its request URI goes to the wallet and its status URI stays with the backend.
3. Poll the result and cancel	Only the session status says whether the presentation passed. Cancel requests that are no longer needed.

Checks that must all pass

1. The credential signature is valid for the issuer key or certificate.
2. The holder or device binding required by the format is valid.
3. The issuer is admitted by the resolved trust attachment.
4. The credential is within its validity period.
5. The referenced status list is valid and the indexed entry is acceptable.
6. The returned credentials and claims satisfy the DCQL query.

For mdoc, also the issuer-signed MSO, the DSC chain to an accepted IACA, device authentication and the CWT status entry. Creating a request does not mean a presentation was accepted.

Deeper reference

Verify credentials has captured requests from the 22 Verification Postman folder and the console Test page (area=test).

Next journey

Continue with Choose status and trust policy.