Skip to content

Authorization requests

An OpenID4VP authorization request tells a wallet:

  • What verifiable presentations to return
  • Where and how to return them (for example, direct_post)
  • How to correlate the response to the request (for example, nonce and state)

OpenID4VP can carry the request parameters directly or wrap them in a Request Object (a signed JWT). For cross-device UX, verifiers often use request_uri to pass the Request Object by reference.

OpenID4VP uses DCQL to express what credentials are requested. Use the dcql_query parameter to request credentials via DCQL. To learn DCQL in detail see Digital Credential Query Language (DCQL).

These parameters show up frequently in verifiable presentation flows:

client_id: Identifies the verifier.

nonce: A unique value used to prevent replay and to bind the response to the request.

response_type: Typically vp_token (or vp_token id_token when an ID token is also requested).

response_mode: Defines how the wallet returns the response. Vidos supports direct_post, direct_post.jwt, dc_api, and dc_api.jwt.

response_uri: Required for direct_post and direct_post.jwt. The wallet posts the authorization response here.

redirect_uri: Used for redirect-based response modes. In Vidos’ OpenID4VP request schema, redirect_uri is not allowed for direct_post response modes.

state: An opaque value for correlating request and response.

For cross-device flows, the authorization request can include:

  • request_uri: A URL where the wallet can retrieve the Request Object
  • request_uri_method: Either get or post

This example shows an OpenID4VP authorization request object using DCQL.

{
"client_id": "https://verifier.example",
"response_type": "vp_token",
"response_mode": "direct_post",
"response_uri": "https://verifier.example/openid4vp/callback",
"nonce": "n-0S6_WzA2Mj",
"state": "af0ifjsldkj",
"dcql_query": {
"credentials": [
{
"id": "photo_id",
"format": "mso_mdoc",
"meta": {
"doctype_value": "org.iso.18013.5.1.mDL"
}
}
]
}
}