Core Responsibilities

The Verifier's responsibilities fall into five areas:

1. Verification Request Management:

   • Creates OpenID4VP authorization requests, choosing a response mode (direct_post, direct_post.jwt, dc_api, or dc_api.jwt; default direct_post.jwt) and an OpenID4VP draft version (v1, v1.draft21, or v1.draft24; default v1).

   • Specifies the required credentials and attributes through a configurable query language — either a DCQL query or a DIF Presentation Exchange v2 definition. Exactly one of the two must be supplied per request.

   • Signs each authorization request with the verifier's DID, so wallets can authenticate the relying party before disclosing any data. The signing DID is taken from the verifierId when it is itself a DID, or from the optional signingDid field in the request body.

   • Returns an authorization-request URI (openid4vp://...) and a verification session id, and can render the same request as a scannable QR code.

2. Credential Validation:

   • Checks the cryptographic signatures of presented credentials, supporting SD-JWT VC and JWT-VC formats.

   • Resolves the issuer's DID document to confirm the signing key and the issuer's identity. Issuer DIDs are resolved over standard methods — did:web (served over an HTTPS origin) and did:key — rather than through any centralized registry.

   • Honors SD-JWT selective disclosure, so only the claims the holder chooses to reveal are processed.

   • Validation today rests on DID resolution and signature verification; revocation-status and domain-linkage checks are planned additions (see Future Enhancements).

3. Real-Time Communication and Feedback:

   • Streams verification session updates over Server-Sent Events (SSE), so your application learns about progress and the final outcome as it happens.

   • Emits a session event carrying the current session state immediately on subscribe and on each subsequent change, plus a ping keepalive every 15 seconds to hold the connection open.

4. Session Management:

   • Tracks each verification session through its lifecycle — RequestCreated → RequestUriRetrieved → ResponseVerified, or Error if the response fails validation. Sessions also carry an expiresAt timestamp after which the request is no longer accepted.

   • Exposes the session state (by polling GET /verification-sessions/:sessionId or by subscribing to its SSE stream) so your integration can trigger its own login or access-control logic once a session reaches ResponseVerified. The Verifier itself does not issue application tokens or sessions — your relying party decides what a successful verification grants.

5. Integration Support:

   • Provides a REST + SSE surface for the full presentation flow: create an authorization request (with optional QR-code rendering), then read or watch the resulting verification session.

   • Offers a standalone POST /credentials/verify endpoint for ad-hoc credential checks outside the presentation flow — useful when you already hold a compact SD-JWT or JWT-VC string and simply want to confirm its validity. The response reports isValid, the detected format, and the decoded payload (plus prettyClaims for SD-JWT), or an error message when the credential is invalid.

For example, a standalone credential check:

// POST /credentials/verify
{
  "credential": "eyJhbGciOiJFZERTQSJ9.eyJ2Y3QiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS92Y3QvZW1wbG95ZWUtYmFkZ2UiLCJlbXBsb3llZV9pZCI6IkUtMTAyNCJ9.signature~WyJzYWx0IiwiZnVsbF9uYW1lIiwiQWRhIExvdmVsYWNlIl0~WyJzYWx0IiwiZGVwYXJ0bWVudCIsIkVuZ2luZWVyaW5nIl0~"
}

A valid SD-JWT VC returns:

{
  "isValid": true,
  "format": "dc+sd-jwt",
  "payload": { "vct": "https://issuer.example.com/vct/employee-badge", "iss": "did:web:issuer.example.com:...", "iat": 1718000000, "employee_id": "E-1024" },
  "prettyClaims": {
    "vct": "https://issuer.example.com/vct/employee-badge",
    "employee_id": "E-1024",
    "full_name": "Ada Lovelace",
    "department": "Engineering"
  }
}

The format field reports the detected credential format: dc+sd-jwt for a verified SD-JWT VC, and jwt_vc for a verified JWT-VC.

In every flow, the relying party stays in control of what a verified presentation unlocks.