Skip to content

Security and validation

OpenID4VP exchanges are security-sensitive. A verifier is accepting high-value claims, and a wallet is disclosing privacy-sensitive information.

OpenID4VP defines and Vidos implements protocol-level checks that help you prevent replay attacks, request/response confusion, and incorrect interpretation of results.

OpenID4VP uses standard OAuth/OIDC correlation techniques.

nonce

  • Use a fresh nonce per request.
  • Validate that the response is cryptographically bound to the request nonce (depending on the credential format).

state

  • Use state to correlate request and response.
  • Treat state as opaque, and validate it exactly.

In direct-post flows, the wallet posts responses to an endpoint chosen by the verifier (response_uri). Your verifier must ensure it is processing the expected callback.

In Vidos’ Authorizer implementation, direct-post handling includes checks such as:

  • The callback URL must match the URL expected for that authorization.
  • If state is present in the response, it must match the stored authorization state.
  • The authorization must not be expired.
  • The authorization must be in a state where processing a response is allowed.

Encrypted response modes (direct_post.jwt and dc_api.jwt) reduce leakage of sensitive response parameters.

Vidos supports encrypted response modes:

  • Validate response can be decrypted.
  • Validate the decrypted payload against the expected schema.
  • Treat decryption failures as invalid requests.

OpenID4VP supports credential requests that require cryptographic holder binding (proof that the presenter is the credential subject).

When you use DCQL, holder binding is controlled per credential query. See the DCQL credentials documentation for:

  • How holder binding requirements are expressed
  • When a verifier might intentionally allow presentations without holder binding