CreateAuthorizationRequest
Optional Id typically containing a business key that can be used to later query the status. If not provided a random UUID will be assigned to the correlationId and will be returned in the response.
my-business-key-or-uuid
Identifier for the query (DCQL or PE)
example-dcql-id
The base URI to be used for request URIs. Defaults to "oidp4vp://". It is mainly useful for web/organizational wallets that have an https:// URI for OID4VP
oid4vp://
https://example.wallet.com
Determines whether the request_uri should be access by a GET or by a POST by the wallet
Possible values: [get
, post
]
get
The client id and schema as defined in RFC6749 (client_id) and OID4VP (scheme)
redirect_uri%3Ahttps%3A%2F%2Fexample.com%2Fcb
The OID4VP response type to use. FIXME Needs to be changed since response_type is a whitespace delimited strung and thus enums are not the correct approach
Possible values: [vp_token
, id_token
]
vp_token
Whether to use regular authorization responses or encrypted (direct_post.jwt) authorization responses
Possible values: [direct_post
, direct_post.jwt
]
direct_post
Array of strings, where each string is a base64url encoded JSON object that contains a typed parameter set with details about the transaction that the Verifier is requesting the End-User to authorize.
qr_code object
As soon as you include this object the OID4VP agent has to generate a QR code. Every RP implementation needs to support this, as we want to make it easy on the integration side. The integration side can choose whether they create their own QR codes, or whether they want to use the QR code from the RP. Thus every RP conforming to this spec should support generating a QR code in data-uri format. No property is mandatory, so a "qrCodeOpts": {} is already valid and generates a QR with the default properties applied. A RP implementation is free to implement additional properties like logo's etc. This API only mandates a few common properties to not make it too complex for RPs. If the integrating app wants to use their own QR codes they simply need to omit the qr_code param from the request. The agent should not generate a QT code in this case
Size of the QR code in pixels.
400
Color of the blocks on the QR code. Accepts a CSS
#000000
Color of the empty areas on the QR code. Accepts a CSS
#ffffff
Optional URI where the user agent on the wallet device should redirect when completing the interaction succesfully
https://example.com/callback/success/my-unique-vallue-here
callback object
Limit the callbacks to certain statuses. If not provided or an empty array is provided, all statuses will be assumed
Possible values: [authorization_request_created
, authorization_request_retrieved
, authorization_response_received
, authorization_response_verified
, error
]
verified_data object
Controls what verified data to include in the response. Only applies when status is 'authorization_response_verified'. Either nothing (omit), or a combination of the vp_tokens and credential data deserialized (credentials_deserialized), depedning on the modes selected
Possible values: [authorization_response
, vp_token
, credential_claims_deserialized
]
The callback url for status updates
https://example.com/callback/status
{
"correlation_id": "my-business-key-or-uuid",
"query_id": "example-dcql-id",
"request_uri_base": "https://example.wallet.com",
"request_uri_method": "get",
"client_id": "redirect_uri%3Ahttps%3A%2F%2Fexample.com%2Fcb",
"response_type": "vp_token",
"response_mode": "direct_post",
"transaction_data": [
"string"
],
"qr_code": {
"size": 400,
"color_dark": "#000000",
"color_light": "#ffffff"
},
"direct_post_response_redirect_uri": "https://example.com/callback/success/my-unique-vallue-here",
"callback": {
"status": [
"authorization_request_created"
],
"verified_data": [
"vp_token",
"credentials_deserialized"
],
"url": "https://example.com/callback/status"
}
}