FAQ

Q: How do I integrate the Verifier into my existing authentication flow?

A: You integrate by calling the Verifier's HTTP API directly from your backend — no client SDK is required. Your server creates an authorization request with POST /verifiers/:verifierId/authorization-requests (or its /qr-code variant) using a valid Authorization: Bearer <token> header, renders the returned authorizationRequestUri as a QR code or deep link for the wallet, and then subscribes to GET /verification-sessions/:sessionId/events over Server-Sent Events to react in real time. When the session reaches a verified state and the claims you required are present, you can complete your own login or access-control decision. This complements or replaces traditional authentication methods such as passwords.

Q: Can the Verifier handle multiple credential types?

A: Yes. There is no fixed set of flows to configure — you describe exactly which credentials and claims you need per request by supplying either a DCQL query or a DIF Presentation Exchange v2 definition in the authorization request body. Provide exactly one of dcqlQuery or presentationDefinition; sending a different query lets the same Verifier accept a different credential type (for example an EmployeeBadge@1:sd-jwt credential in one flow and an employment credential in another). See Query Language for examples.

Q: How do I know if a credential issuer is trustworthy?

A: Issuer authenticity is established cryptographically. When a presentation arrives, the Verifier resolves the issuer's DID — a did:web document fetched over HTTPS, or a did:key resolved from the identifier itself — and verifies the credential signature against the key in that DID document. Credentials that fail authenticity or integrity checks are rejected. Trust today rests on DID resolution and signature verification; revocation-status and domain-linkage checks are planned additions (see Future Enhancements).

Q: What if a verification request expires or fails?

A: Each authorization request creates a verification session that carries an expiry (expiresAt) and advances through lifecycle states (for example RequestCreated) that you can read from GET /verification-sessions/:sessionId or stream over SSE. If a session expires before the wallet responds, simply create a new authorization request and present the fresh URI or QR code. When verification fails, the session exposes an error and /credentials/verify returns { "isValid": false, "error": "..." }; check the message together with your query and the credential definition to diagnose the cause.

Q: Can I customize the verification workflow?

A: Yes. Customization happens in two places. First, shape what you ask for by tailoring your dcqlQuery or presentationDefinition — credential types, claims, JSON Schema filters, the OpenID4VP version, and the responseMode. Second, apply your own business logic in your backend by reading the verification session state (via polling or the SSE stream) and deciding what a successfully verified presentation means for your application. There is no separate callback-handler framework; you own the handling of the verified session in your own code.