> For the complete documentation index, see [llms.txt](https://docs.empe.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.empe.io/develop/verifier/faq.md). # 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 ` 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](/develop/verifier/query-language.md) 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](/develop/verifier/future-enhancements.md)). **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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.empe.io/develop/verifier/faq.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.