Create presentation definition
POST/v2/config/digital-wallet/openid/sdjwt/presentation-definition
Creates a presentation definition. The presentation definition gives the credential types and the claims that the verifier needs for an OpenID4VP verification.
Give the credential requirements as a Digital Credentials Query Language (DCQL) query in dcqlQuery. The verifier is OpenID4VP 1.0 and accepts DCQL queries only.
The presentation definition also holds the transport settings that every verification request inherits: responseMode, clientIdScheme, dcApiRequestType, expectedOrigins and encryptedResponseEncValuesSupported. Both Direct Post (direct_post, direct_post.jwt) and DC API (dc_api, dc_api.jwt) response modes are available.
Rules that the server applies:
labelis mandatory and must be 3 to 100 characters long.labelmust not be a label that an extension reserves, for example 'Age Verification', 'Document Signing' or 'Know-Your-Customer (KYC)'.dcqlQueryis mandatory whenresponseTypeisvp_tokenordevice_response. Do not send it whenresponseTypeisid_token.- Each entry of
dcqlQuery.credentialsneeds anidand aformat. Theformatcontrols whichmetakeys the server accepts:mso_mdoctakesdoctype_valueonly,dc+sd-jwttakesvct_valuesortype_values, andjwt_vc_jsontakestype_valuesonly. Thevc+sd-jwt,vp+sd-jwtandjwt_vcformats take nometakey at all. Any other key is refused. claim_setsneeds a non-emptyclaimsarray in the same credential query.- Each entry of
dcqlQuery.credential_setsneeds a non-emptyoptionsarray. directPostRedirectUriis allowed only whenresponseModeisdirect_post. The server refuses it fordirect_post.jwt.encryptedResponseEncValuesSupportedis mandatory whenresponseModeisdirect_post.jwt, and the verifier global configuration must permit response encryption.dcApiRequestTypeis allowed only whenresponseModeisdc_apiordc_api.jwt.expectedOriginsis mandatory when the request type issigned.dc_api.jwtdefaults tosignedanddc_apidefaults tounsigned.transactionDataDefinitionTypeis mandatory when the DCQL query asks for a Payment Wallet Attestation, a QESAC credential or an SCA attestation.
The iso18013_7_annex_c version has more rules: responseType must be device_response, trustAnchor must be x509, clientIdScheme must be null, transactionDataDefinitionType must be absent, expectedOrigins must hold exactly one origin, every credential query must use mso_mdoc with a meta.doctype_value, a non-empty claims array and require_cryptographic_holder_binding set to true, every claim path must hold two elements, and credential_sets and claim_sets are not allowed.
Request
Header Parameters
Optional. Unique identifier of the sandbox organisation to use for this request. When you send this header, the service runs the operation in the context of the named sandbox organisation, that is, against the wallet of that sandbox organisation and not against the main wallet of the organisation. Leave the header out to use the main wallet.
The service reads this header only when you authenticate with a bearer access token. When you authenticate with an API key, the service takes the sandbox organisation from the API key and ignores this header. To run an API-key call in a sandbox organisation, bind the key to the sandbox organisation with PUT /v2/config/admin/apikey/{apiKeyId}/sandbox-org instead.
X-SubwalletId is the deprecated name of this header. The service continues to accept it, but X-SandboxOrgId wins if you send both headers.
The sandbox organisation must exist, must belong to your organisation and must be deployed. An unknown identifier, an identifier of a sandbox organisation that is not deployed, and an identifier that belongs to a different organisation all make the call fail with HTTP 400.
- application/json
Body
required
Label, credential requirements and transport settings of the new presentation definition.
- Default (all fields)
- IETF SD-JWT VC
- ISO 18013-5 mDoc/mDL
- W3C VC (JWT)
- Array [
mso_mdoc-doctype_valueonly.dc+sd-jwt-vct_valuesortype_values.jwt_vc_json-type_valuesonly.vct_valuesis refused.vc+sd-jwt,vp+sd-jwt,jwt_vc- no key is allowed. Leavemetaout.mso_mdoc-doctype_valueonly.dc+sd-jwt-vct_valuesortype_values.jwt_vc_json-type_valuesonly.vct_valuesis refused.vc+sd-jwt,vp+sd-jwt,jwt_vc- no key is allowed. Leavemetaout.- Array [
- ]
- Array [
- ]
- ]
- Array [
- ]
Possible values: >= 3 characters and <= 100 characters
Human-readable label that gives the purpose of this presentation definition, for example 'Verify Portable Document A1'. The dashboard shows this label. The label must be 3 to 100 characters long. Labels that extensions reserve are refused, for example 'Age Verification', 'Document Signing' and 'Know-Your-Customer (KYC)'.
dcqlQuery object
Digital Credentials Query Language (DCQL) query that gives the credentials and the claims that the verifier asks from the holder. This is the only way to give the credential requirements.
The query holds a credentials array. Each entry needs an id and a format. The format controls which meta keys the server accepts. Each entry can also hold claims, claim_sets, require_cryptographic_holder_binding, multiple and trusted_authorities. A top-level credential_sets array can group the credential queries.
dcqlQuery is mandatory when responseType is vp_token or device_response. Do not send it when responseType is id_token.
credentials object[]required
Possible values: >= 1
Credential queries. The wallet of the holder must satisfy every entry, unless credential_sets says otherwise.
Identifier of this credential query. credential_sets and the presentation response use this value. Use letters, digits, spaces, _ and -. The server does not apply this check to the iso18013_7_annex_c version.
Possible values: [dc+sd-jwt, vc+sd-jwt, vp+sd-jwt, jwt_vc_json, jwt_vc, mso_mdoc]
Credential format that the verifier accepts for this query.
meta object
Format-specific match rules. The server refuses any key that the format does not allow:
Accepted vct values of the SD-JWT VC. Use this property with the dc+sd-jwt format only.
Accepted type sets of the credential. Each entry is an array of type names, and the credential must hold every type of at least one entry. Use this property with the dc+sd-jwt and jwt_vc_json formats only.
Accepted docType of the mDoc, for example org.iso.18013.5.1.mDL. Use this property with mso_mdoc only.
Format-specific match rules. The server refuses any key that the format does not allow:
claims object[]
Claims that the verifier asks for. Leave this property out to ask for the whole credential.
Identifier of this claim query. claim_sets uses this value. Give an id to every claim when you use claim_sets.
Pointer to the claim inside the credential. Each element is a property name, or an array index. For mso_mdoc the path holds two elements: the namespace and the data element, for example ['org.iso.18013.5.1', 'family_name']. For jwt_vc_json the path starts with credentialSubject.
Values that the claim must hold. Leave this property out to accept every value.
Alternative sets of claims. Each entry is an array of claim id values, and the wallet satisfies the first entry that it can. Send this property only together with a non-empty claims array.
true when the credential must prove that the holder owns it.
true when the wallet can return more than one credential for this query.
trusted_authorities object[]
Issuers that the verifier trusts for this query.
Type of the trust list, for example etsi_tl for an ETSI trusted list or aki for an authority key identifier.
Identifiers of the trusted issuers.
credential_sets object[]
Groups of credential queries. Each entry gives the combinations of credential query identifiers that satisfy the request.
Possible values: >= 1
Accepted combinations. Each entry is an array of credential query identifiers. This property is mandatory, and it must hold at least one combination.
true when the wallet must satisfy one of the options.
Reason why the verifier asks for this group of credentials. The server accepts a string, a number or an object here.
Digital Credentials Query Language (DCQL) query that gives the credentials and the claims that the verifier asks from the holder. This is the only way to give the credential requirements.
The query holds a credentials array. Each entry needs an id and a format. The format controls which meta keys the server accepts. Each entry can also hold claims, claim_sets, require_cryptographic_holder_binding, multiple and trusted_authorities. A top-level credential_sets array can group the credential queries.
dcqlQuery is mandatory when responseType is vp_token or device_response. Do not send it when responseType is id_token.
Possible values: [payment_data, payment, login_risk_transaction, login_risk_transaction_non_ts12, account_access, emandate, data_agreement_record, data_disclosure_agreement_record, qes_data]
Type of transaction data that the verification request binds. The holder must approve the transaction data before the wallet sends the presentation. The value selects the JSON Schema that the server uses to validate the transactionData of the verification request. Read GET /v2/config/digital-wallet/openid/sdjwt/transaction-data-definitions for the schema of each type.
This property is mandatory when the DCQL query asks for a Payment Wallet Attestation, a QESAC credential or an SCA attestation.
Possible values: [version_01, iso18013_7_annex_c]
Default value: version_01
OpenID for Verifiable Presentations (OpenID4VP) version of the Authorization Request. version_01 is OpenID4VP 1.0. iso18013_7_annex_c is the ISO 18013-7 Annex C profile, which asks for mDoc credentials over the Digital Credentials API.
Key Identifier (kid) of the cryptographic key of the verifier. The server uses the key of the organisation when you send no kid. The key must be valid when dcApiRequestType is signed.
Possible values: [did:key, x509]
Default value: did:key
DID method or key type that the verifier uses as its trust anchor. It sets how the holder resolves the identity of the verifier. iso18013_7_annex_c needs x509.
OAuth 2.0 scope value for a scope-based presentation request.
Possible values: [vp_token, id_token, device_response]
Default value: vp_token
OAuth 2.0 response type of the Authorization Request. vp_token asks for a Verifiable Presentation. id_token asks for an OpenID Connect ID Token and accepts no dcqlQuery. device_response asks for an ISO 18013-5 DeviceResponse and is only for iso18013_7_annex_c.
Possible values: [redirect_uri, did, verifier_attestation, x509_san_dns, x509_hash]
Default value: redirect_uri
Client ID scheme of the Authorization Request. It sets how the verifier identifies itself to the wallet of the holder. redirect_uri uses a redirect URI, did uses a DID, verifier_attestation uses a Verifier Attestation JWT, x509_san_dns uses the SAN DNS name of an X.509 certificate, and x509_hash uses the hash of an X.509 certificate. With the DC API response modes, redirect_uri is only a logical identifier and not a real redirect target. Send null for iso18013_7_annex_c.
URI that the wallet of the holder opens after it posts the Authorization Response. Only for the direct_post response mode. The server refuses this property for direct_post.jwt, and it has no meaning for the DC API response modes.
Possible values: [direct_post, direct_post.jwt, dc_api, dc_api.jwt]
Default value: direct_post
Response mode that sets how the wallet of the holder delivers the Authorization Response. Direct Post: direct_post posts the response over HTTP. direct_post.jwt posts the response as an encrypted JWT. DC API: dc_api uses the W3C Digital Credentials API and returns the response without JWE encryption. dc_api.jwt uses the Digital Credentials API and returns the response as a JWE.
Possible values: [signed, unsigned]
Signing type of the DC API request. Only allowed when responseMode is dc_api or dc_api.jwt. signed makes the verifier sign the Authorization Request. unsigned gives no verifier authentication. The server treats a missing value as unsigned for dc_api and as signed for dc_api.jwt. Use signed in production.
Origins that the wallet accepts for a signed DC API request. The wallet compares these values with the actual origin to find a replay. Mandatory when the effective dcApiRequestType is signed, and mandatory for iso18013_7_annex_c. The wallet ignores this property for an unsigned request.
Possible values: [A128CBC-HS256, A128GCM, A256GCM]
JWE content encryption algorithms that the verifier accepts for the Authorization Response.
This property is mandatory when responseMode is direct_post.jwt, and the verifier global configuration must permit response encryption. When the stored value is empty, the verification request falls back to all three algorithms: A128CBC-HS256, A128GCM and A256GCM.
The dc_api.jwt response mode ignores this property. That flow always advertises A128GCM and A256GCM, and encrypts with A256GCM.
Possible values: >= 3 characters and <= 100 characters
Human-readable label that gives the purpose of this presentation definition. The dashboard shows this label. The label must be 3 to 100 characters long. Labels that extensions reserve are refused, for example 'Age Verification', 'Document Signing' and 'Know-Your-Customer (KYC)'.
Possible values: [did:key, x509]
Default value: did:key
DID method or key type that the verifier uses as its trust anchor. It sets how the holder resolves the identity of the verifier.
Possible values: [version_01]
Default value: version_01
OpenID for Verifiable Presentations (OpenID4VP) version of the Authorization Request. version_01 is OpenID4VP 1.0.
Key Identifier (kid) of the cryptographic key of the verifier. The server uses the key of the organisation when you send no kid. The key must be valid when dcApiRequestType is signed.
Possible values: [vp_token, id_token]
Default value: vp_token
OAuth 2.0 response type of the Authorization Request. Use vp_token to ask for a Verifiable Presentation. id_token asks for an OpenID Connect ID Token and accepts no dcqlQuery.
Possible values: [redirect_uri, did, verifier_attestation, x509_san_dns, x509_hash]
Default value: redirect_uri
Client ID scheme of the Authorization Request. It sets how the verifier identifies itself to the wallet of the holder. With the DC API response modes, redirect_uri is only a logical identifier and not a real redirect target.
Possible values: [direct_post, direct_post.jwt, dc_api, dc_api.jwt]
Default value: direct_post
Response mode that sets how the wallet of the holder delivers the Authorization Response. Direct Post: direct_post posts the response over HTTP. direct_post.jwt posts the response as an encrypted JWT. DC API: dc_api uses the W3C Digital Credentials API and returns the response without JWE encryption. dc_api.jwt uses the Digital Credentials API and returns the response as a JWE.
URI that the wallet of the holder opens after it posts the Authorization Response. Only for the direct_post response mode. The server refuses this property for direct_post.jwt, and it has no meaning for the DC API response modes.
Possible values: [payment_data, payment, login_risk_transaction, login_risk_transaction_non_ts12, account_access, emandate, data_agreement_record, data_disclosure_agreement_record, qes_data]
Type of transaction data that the verification request binds. The holder must approve the transaction data before the wallet sends the presentation. Read GET /v2/config/digital-wallet/openid/sdjwt/transaction-data-definitions for the schema of each type.
Possible values: [signed, unsigned]
Signing type of the DC API request. Only allowed when responseMode is dc_api or dc_api.jwt. signed makes the verifier sign the Authorization Request. unsigned gives no verifier authentication. The server treats a missing value as unsigned for dc_api and as signed for dc_api.jwt. Use signed in production.
Origins that the wallet accepts for a signed DC API request. The wallet compares these values with the actual origin to find a replay. Mandatory when the effective dcApiRequestType is signed. The wallet ignores this property for an unsigned request.
Possible values: [A128CBC-HS256, A128GCM, A256GCM]
JWE content encryption algorithms that the verifier accepts for the Authorization Response.
This property is mandatory when responseMode is direct_post.jwt, and the verifier global configuration must permit response encryption. When the stored value is empty, the verification request falls back to all three algorithms: A128CBC-HS256, A128GCM and A256GCM.
The dc_api.jwt response mode ignores this property. That flow always advertises A128GCM and A256GCM, and encrypts with A256GCM.
dcqlQuery object
Digital Credentials Query Language (DCQL) query for the IETF SD-JWT VC format. It holds a credentials array, and every entry needs an id and a format.
Set format to dc+sd-jwt and give the accepted credential types in meta.vct_values. Claim paths are flat, for example ['identifier'].
Ask only for subject claims, for example given_name or birthdate. The envelope claims iss, iat, exp, cnf, vct and status are always in the presentation. You cannot ask for them.
Digital Credentials Query Language (DCQL) query for the IETF SD-JWT VC format. It holds a credentials array, and every entry needs an id and a format.
Set format to dc+sd-jwt and give the accepted credential types in meta.vct_values. Claim paths are flat, for example ['identifier'].
Ask only for subject claims, for example given_name or birthdate. The envelope claims iss, iat, exp, cnf, vct and status are always in the presentation. You cannot ask for them.
Possible values: >= 3 characters and <= 100 characters
Human-readable label that gives the purpose of this presentation definition. The dashboard shows this label. The label must be 3 to 100 characters long. Labels that extensions reserve are refused, for example 'Age Verification', 'Document Signing' and 'Know-Your-Customer (KYC)'.
Possible values: [did:key, x509]
Default value: did:key
DID method or key type that the verifier uses as its trust anchor. It sets how the holder resolves the identity of the verifier.
Possible values: [version_01]
Default value: version_01
OpenID for Verifiable Presentations (OpenID4VP) version of the Authorization Request. version_01 is OpenID4VP 1.0.
Key Identifier (kid) of the cryptographic key of the verifier. The server uses the key of the organisation when you send no kid. The key must be valid when dcApiRequestType is signed.
Possible values: [vp_token, id_token]
Default value: vp_token
OAuth 2.0 response type of the Authorization Request. Use vp_token to ask for a Verifiable Presentation. id_token asks for an OpenID Connect ID Token and accepts no dcqlQuery.
Possible values: [redirect_uri, did, verifier_attestation, x509_san_dns, x509_hash]
Default value: redirect_uri
Client ID scheme of the Authorization Request. It sets how the verifier identifies itself to the wallet of the holder. With the DC API response modes, redirect_uri is only a logical identifier and not a real redirect target.
Possible values: [direct_post, direct_post.jwt, dc_api, dc_api.jwt]
Default value: direct_post
Response mode that sets how the wallet of the holder delivers the Authorization Response. Direct Post: direct_post posts the response over HTTP. direct_post.jwt posts the response as an encrypted JWT. DC API: dc_api uses the W3C Digital Credentials API and returns the response without JWE encryption. dc_api.jwt uses the Digital Credentials API and returns the response as a JWE.
URI that the wallet of the holder opens after it posts the Authorization Response. Only for the direct_post response mode. The server refuses this property for direct_post.jwt, and it has no meaning for the DC API response modes.
Possible values: [payment_data, payment, login_risk_transaction, login_risk_transaction_non_ts12, account_access, emandate, data_agreement_record, data_disclosure_agreement_record, qes_data]
Type of transaction data that the verification request binds. The holder must approve the transaction data before the wallet sends the presentation. Read GET /v2/config/digital-wallet/openid/sdjwt/transaction-data-definitions for the schema of each type.
Possible values: [signed, unsigned]
Signing type of the DC API request. Only allowed when responseMode is dc_api or dc_api.jwt. signed makes the verifier sign the Authorization Request. unsigned gives no verifier authentication. The server treats a missing value as unsigned for dc_api and as signed for dc_api.jwt. Use signed in production.
Origins that the wallet accepts for a signed DC API request. The wallet compares these values with the actual origin to find a replay. Mandatory when the effective dcApiRequestType is signed. The wallet ignores this property for an unsigned request.
Possible values: [A128CBC-HS256, A128GCM, A256GCM]
JWE content encryption algorithms that the verifier accepts for the Authorization Response.
This property is mandatory when responseMode is direct_post.jwt, and the verifier global configuration must permit response encryption. When the stored value is empty, the verification request falls back to all three algorithms: A128CBC-HS256, A128GCM and A256GCM.
The dc_api.jwt response mode ignores this property. That flow always advertises A128GCM and A256GCM, and encrypts with A256GCM.
dcqlQuery object
Digital Credentials Query Language (DCQL) query for the ISO 18013-5 mDoc/mDL format. It holds a credentials array, and every entry needs an id and a format.
Set format to mso_mdoc and give the document type in meta.doctype_value. Every claim path holds two elements: the namespace and the data element, for example ['org.iso.18013.5.1', 'family_name'].
Ask only for subject data elements, for example given_name or birth_date. The MSO fields validityInfo, digestAlgorithm and deviceKey are always in the presentation. You cannot ask for them.
Digital Credentials Query Language (DCQL) query for the ISO 18013-5 mDoc/mDL format. It holds a credentials array, and every entry needs an id and a format.
Set format to mso_mdoc and give the document type in meta.doctype_value. Every claim path holds two elements: the namespace and the data element, for example ['org.iso.18013.5.1', 'family_name'].
Ask only for subject data elements, for example given_name or birth_date. The MSO fields validityInfo, digestAlgorithm and deviceKey are always in the presentation. You cannot ask for them.
Possible values: >= 3 characters and <= 100 characters
Human-readable label that gives the purpose of this presentation definition. The dashboard shows this label. The label must be 3 to 100 characters long. Labels that extensions reserve are refused, for example 'Age Verification', 'Document Signing' and 'Know-Your-Customer (KYC)'.
Possible values: [did:key, x509]
Default value: did:key
DID method or key type that the verifier uses as its trust anchor. It sets how the holder resolves the identity of the verifier.
Possible values: [version_01]
Default value: version_01
OpenID for Verifiable Presentations (OpenID4VP) version of the Authorization Request. version_01 is OpenID4VP 1.0.
Key Identifier (kid) of the cryptographic key of the verifier. The server uses the key of the organisation when you send no kid. The key must be valid when dcApiRequestType is signed.
Possible values: [vp_token, id_token]
Default value: vp_token
OAuth 2.0 response type of the Authorization Request. Use vp_token to ask for a Verifiable Presentation. id_token asks for an OpenID Connect ID Token and accepts no dcqlQuery.
Possible values: [redirect_uri, did, verifier_attestation, x509_san_dns, x509_hash]
Default value: redirect_uri
Client ID scheme of the Authorization Request. It sets how the verifier identifies itself to the wallet of the holder. With the DC API response modes, redirect_uri is only a logical identifier and not a real redirect target.
Possible values: [direct_post, direct_post.jwt, dc_api, dc_api.jwt]
Default value: direct_post
Response mode that sets how the wallet of the holder delivers the Authorization Response. Direct Post: direct_post posts the response over HTTP. direct_post.jwt posts the response as an encrypted JWT. DC API: dc_api uses the W3C Digital Credentials API and returns the response without JWE encryption. dc_api.jwt uses the Digital Credentials API and returns the response as a JWE.
URI that the wallet of the holder opens after it posts the Authorization Response. Only for the direct_post response mode. The server refuses this property for direct_post.jwt, and it has no meaning for the DC API response modes.
Possible values: [payment_data, payment, login_risk_transaction, login_risk_transaction_non_ts12, account_access, emandate, data_agreement_record, data_disclosure_agreement_record, qes_data]
Type of transaction data that the verification request binds. The holder must approve the transaction data before the wallet sends the presentation. Read GET /v2/config/digital-wallet/openid/sdjwt/transaction-data-definitions for the schema of each type.
Possible values: [signed, unsigned]
Signing type of the DC API request. Only allowed when responseMode is dc_api or dc_api.jwt. signed makes the verifier sign the Authorization Request. unsigned gives no verifier authentication. The server treats a missing value as unsigned for dc_api and as signed for dc_api.jwt. Use signed in production.
Origins that the wallet accepts for a signed DC API request. The wallet compares these values with the actual origin to find a replay. Mandatory when the effective dcApiRequestType is signed. The wallet ignores this property for an unsigned request.
Possible values: [A128CBC-HS256, A128GCM, A256GCM]
JWE content encryption algorithms that the verifier accepts for the Authorization Response.
This property is mandatory when responseMode is direct_post.jwt, and the verifier global configuration must permit response encryption. When the stored value is empty, the verification request falls back to all three algorithms: A128CBC-HS256, A128GCM and A256GCM.
The dc_api.jwt response mode ignores this property. That flow always advertises A128GCM and A256GCM, and encrypts with A256GCM.
dcqlQuery object
Digital Credentials Query Language (DCQL) query for the W3C VC (JWT) format. It holds a credentials array, and every entry needs an id and a format.
Set format to jwt_vc_json and give the accepted type sets in meta.type_values, which is an array of arrays. Every claim path starts with credentialSubject, for example ['credentialSubject', 'identifier'].
Ask only for claims under credentialSubject. The envelope fields issuer, issuanceDate, expirationDate and credentialStatus are always in the presentation. You cannot ask for them.
Digital Credentials Query Language (DCQL) query for the W3C VC (JWT) format. It holds a credentials array, and every entry needs an id and a format.
Set format to jwt_vc_json and give the accepted type sets in meta.type_values, which is an array of arrays. Every claim path starts with credentialSubject, for example ['credentialSubject', 'identifier'].
Ask only for claims under credentialSubject. The envelope fields issuer, issuanceDate, expirationDate and credentialStatus are always in the presentation. You cannot ask for them.
Responses
- 200
- 400
- 401
- 500
The server created the presentation definition.
Response Headers
- application/json
- Schema
- Example (from schema)
Schema
presentationDefinition objectrequired
Internal record identifier of the presentation definition. The list endpoint returns the value of presentationDefinitionId here. The create, read and update endpoints return a different internal identifier. Always use presentationDefinitionId to address the presentation definition.
Identifier of the OpenID4VC deployment that owns this presentation definition.
Unique identifier that the server gives to the presentation definition. Use this identifier in a verification request and in the path of the read, update and delete endpoints.
Human-readable label that gives the purpose of this presentation definition, for example 'Verify Portable Document A1'. The dashboard shows this label.
dcqlQuery object
Digital Credentials Query Language (DCQL) query that gives the credentials and the claims that the verifier asks from the holder.
The query holds a credentials array. Each entry has an id, a format and a format-specific meta object: doctype_value for mso_mdoc, vct_values or type_values for dc+sd-jwt, and type_values for jwt_vc_json. An entry can also hold claims, claim_sets, require_cryptographic_holder_binding, multiple and trusted_authorities. A top-level credential_sets array can group the credential queries.
The server leaves this property out when the presentation definition has no DCQL query.
Digital Credentials Query Language (DCQL) query that gives the credentials and the claims that the verifier asks from the holder.
The query holds a credentials array. Each entry has an id, a format and a format-specific meta object: doctype_value for mso_mdoc, vct_values or type_values for dc+sd-jwt, and type_values for jwt_vc_json. An entry can also hold claims, claim_sets, require_cryptographic_holder_binding, multiple and trusted_authorities. A top-level credential_sets array can group the credential queries.
The server leaves this property out when the presentation definition has no DCQL query.
Possible values: [``, payment_data, payment, login_risk_transaction, login_risk_transaction_non_ts12, account_access, emandate, data_agreement_record, data_disclosure_agreement_record, qes_data]
Type of transaction data that the verification request binds. The holder must approve the transaction data before the wallet sends the presentation. The value selects the JSON Schema that the server uses to validate the transactionData of the verification request. Read GET /v2/config/digital-wallet/openid/sdjwt/transaction-data-definitions for the schema of each type.
The value is an empty string when the presentation definition binds no transaction data.
Unix timestamp, in seconds, of the moment that the server created this presentation definition.
Unix timestamp, in seconds, of the moment that the server last changed this presentation definition.
Possible values: [version_01, iso18013_7_annex_c]
OpenID for Verifiable Presentations (OpenID4VP) version of the Authorization Request. version_01 is OpenID4VP 1.0. iso18013_7_annex_c is the ISO 18013-7 Annex C profile, which asks for mDoc credentials over the Digital Credentials API.
Key Identifier (kid) of the cryptographic key that the verifier uses to sign the Authorization Request and to receive an encrypted response. The value is an empty string when the presentation definition holds no key identifier.
Possible values: [did:key, x509]
DID method or key type that the verifier uses as its trust anchor. It sets how the holder resolves the identity of the verifier.
OAuth 2.0 scope value for a scope-based presentation request. The value is an empty string when the presentation definition holds no scope.
Possible values: [vp_token, id_token, device_response]
OAuth 2.0 response type of the Authorization Request. vp_token asks for a Verifiable Presentation. id_token asks for an OpenID Connect ID Token. device_response asks for an ISO 18013-5 DeviceResponse and is only for iso18013_7_annex_c.
Possible values: [redirect_uri, did, verifier_attestation, x509_san_dns, x509_hash]
Client ID scheme of the Authorization Request. It sets how the verifier identifies itself to the wallet of the holder. redirect_uri uses a redirect URI, did uses a DID, verifier_attestation uses a Verifier Attestation JWT, x509_san_dns uses the SAN DNS name of an X.509 certificate, and x509_hash uses the hash of an X.509 certificate. With the DC API response modes, redirect_uri is only a logical identifier and not a real redirect target. The server leaves this property out for iso18013_7_annex_c.
URI that the wallet of the holder opens after it posts the Authorization Response. Only for the direct_post response mode. The server refuses this property for direct_post.jwt, and it has no meaning for the DC API response modes. The server leaves this property out when the presentation definition holds no URI.
Possible values: [direct_post, direct_post.jwt, dc_api, dc_api.jwt]
Response mode that sets how the wallet of the holder delivers the Authorization Response. Direct Post: direct_post posts the response over HTTP. direct_post.jwt posts the response as an encrypted JWT. DC API: dc_api uses the W3C Digital Credentials API and returns the response without JWE encryption. dc_api.jwt uses the Digital Credentials API and returns the response as a JWE.
Possible values: [signed, unsigned]
Signing type of the DC API request. Only for the dc_api and dc_api.jwt response modes. signed means that the verifier signs the Authorization Request. unsigned means that the verifier sends the request unsigned. The server leaves this property out when the presentation definition holds no value.
Origins that the wallet accepts for a signed DC API request. The server leaves this property out when the presentation definition holds no origin.
Possible values: [A128CBC-HS256, A128GCM, A256GCM]
JWE content encryption algorithms that the verifier accepts for the Authorization Response. It applies to the direct_post.jwt response mode; the dc_api.jwt flow ignores it and always advertises A128GCM and A256GCM.
The server leaves this property out when the presentation definition holds no algorithm. The verification request then falls back to all three algorithms.
true when the platform owns this presentation definition. You cannot delete a system managed presentation definition.
true when an extension uses this presentation definition. You cannot update such a presentation definition, and you cannot delete most of them. Note the spelling of this property name.
presentationDefinition object
Legacy credential requirements of a presentation definition that an older OpenID4VP version created. The value is null for every presentation definition that uses dcqlQuery. You cannot set this property.
Legacy credential requirements of a presentation definition that an older OpenID4VP version created. The value is null for every presentation definition that uses dcqlQuery. You cannot set this property.
{
"presentationDefinition": {
"id": "string",
"openIdOrganisationId": "string",
"presentationDefinitionId": "string",
"label": "string",
"dcqlQuery": {},
"transactionDataDefinitionType": "",
"createdAt": 0,
"updatedAt": 0,
"version": "version_01",
"kid": "string",
"trustAnchor": "did:key",
"scope": "string",
"responseType": "vp_token",
"clientIdScheme": "redirect_uri",
"directPostRedirectUri": "string",
"responseMode": "direct_post",
"dcApiRequestType": "signed",
"expectedOrigins": [
"string"
],
"encryptedResponseEncValuesSupported": [
"A128CBC-HS256"
],
"systemManaged": true,
"extentionEnabled": true,
"presentationDefinition": {}
}
}
The body is not valid JSON, label is missing or shorter than 3 characters, label is a label that an extension reserves, dcApiRequestType does not agree with responseMode, expectedOrigins is missing for a signed DC API request, directPostRedirectUri is set for direct_post.jwt, encryptedResponseEncValuesSupported is missing for direct_post.jwt or the verifier global configuration does not permit response encryption, the DCQL query is not valid, transactionDataDefinitionType is missing for a transaction data credential, the organisation is unknown, the digital wallet deployment is not resolved, or the digital wallet refused the presentation definition.
Response Headers
- application/json
- Schema
- Example (from schema)
Schema
{
"errorCode": 400,
"errorDescription": "Bad input parameter"
}
Unauthorized
Response Headers
- application/json
- Schema
- Example (from schema)
Schema
{
"errorCode": 400,
"errorDescription": "Bad input parameter"
}
Internal server error
Response Headers
- application/json
- Schema
- Example (from schema)
Schema
{
"errorCode": 400,
"errorDescription": "Bad input parameter"
}