Learn how to verify SD-JWT-based Verifiable Credentials (IETF SD-JWT VC) via OID4VP using walt.id's verifier API, including policy configuration, custom presentation definitions, and result retrieval.
What you'll learn
Relevant concepts
This guide provides a comprehensive walkthrough for verifying a SD-JWT VC credentials based on the IETF standard using the walt.id verifier API. The verification process will utilize the OID4VCI protocol, an extension of OpenID, facilitating secure and standardized communication between identities.
SD-JWT VC: A digital equivalent of physical credentials such as a driver's license or university degree. VCs are cryptographically secure, privacy-respecting, and instantly verifiable.
OID4VCI: A protocol specifying how parties can issue VCs and present these credentials in a way that's consistent and secure across platforms ensuring interoperability.
First, determine the type of SD-JWT VC Credential to be verified. Although this guide focuses on a "VerifiableDiploma," you can use any credential type compliant with the IETF standard.
The verification process will be as follows:
After you have provided the required information:
If you have provided a success or failure redirect URL, the user will be redirected to that URL. You can then access the verification results by using the id of the verification session, which can be found in the URL generated by the API, as well as in the query or path parameters of the redirect URL.
In this example, we specify the credential we want to verify by supplying the type.
curl -X 'POST' \
'https://verifier.demo.walt.id/openid4vc/verify' \
-H 'accept: */*' \
-H 'authorizeBaseUrl: openid4vp://authorize' \
-H 'responseMode: direct_post' \
-H 'successRedirectUri: https://example.com/success?id=$id' \
-H 'errorRedirectUri: https://example.com/error?id=$id' \
-H 'statusCallbackUri: https://example.com/verificationResult' \
-H 'statusCallbackApiKey: myAPIKey' \
-H 'stateId: myUniqueStateValue' \
-H 'Content-Type: application/json' \
-d '{
"request_credentials": [
{ "vct": "VerifiableDiploma", "format": "vc+sd-jwt" }
]
}'
Header Parameters
openid4vp://authorize which
is fine for most use-cases. If you however are required to use the HAIP OID4VC profile, you need to update the value as follows: haip://direct_post as the other options are not yet supported.$id
placeholder
to get access to the id of verification session in your application in order to retrieve the verification results.
E.g. /success?id=$id will be replaced with /success?id=1234567890$id
placeholder
to get access to the id of verification session in your application in order to retrieve the verification results.
E.g. /error?id=$id will be replaced with /error?id=1234567890POST including the whole presentation
result. See Verification Status Policies ResponsestatusCallbackUri is protected, you can use
the statusCallbackApiKey to authenticate.
The provided key will be appended as Authorization Header to the request.state value which gets created for each verification request with your
own.DEFAULT.
Apart from that, you can choose from the following options:HAIP: For the OID4VC HAIP profile.EBSIV3: For EBSI V3 compliant VP. Learn more here.ISO_18013_7_MDOC: For mdoc Openid4VP.Body Parameters
Below are the possible credential types and their respective object structures:
vct
attribute in the SD-JWT VC credential.vc+sd-jwt.
{ "vct": "test.com/identity_credential", "format": "vc+sd-jwt" }
VerifiableID, VerifiableDiploma). This maps to the type
attribute in W3C credentials.jwt_vc_json.
{ "type": "ProofOfResidence", "format": "jwt_vc_json" }
mso_mdoc.
{ "doc_type": "org.iso.18013.5.1.mDL", "format": "mso_mdoc" }
Optional Parameters
Next to describing the type and format of the credential, the objects also take an optional policies and id
attribute
Full Examples
{
"vct": "ProofOfResidence",
"format": "vc+sd-jwt",
"policies": [
"schema",
{
"policy": "webhook",
"args": "https://example.org/abc/xyz"
}
],
"id": "test123"
}
Please note that if you are using the HAIP profile, you cannot specify custom policies at this point.
In this example, we not only specify the types of credentials to verify, but also define the policies that should be executed during verification:
signature policy is applied by default to both VP and VC(s).How VC policies are applied:
We specify policies in the verification request alongside the request_credentials parameter (previously explained),
using the vc_policies and vp_policies fields:
vc_policies and vp_policies each contain a list of policies; either one or both can be provided.Example Polices
[
"signature",
// policy without argument
"expired",
// policy without argument
"not-before",
// policy without argument
{
"policy": "webhook",
"args": "https://example.org/abc/xyz"
}
// policy with argument
]
Initiation Request
curl -X 'POST' \
'https://verifier.demo.walt.id/openid4vc/verify' \
-H 'accept: */*' \
-H 'authorizeBaseUrl: openid4vp://authorize' \
-H 'responseMode: direct_post' \
-H 'successRedirectUri: https://example.com/success?id=$id' \
-H 'errorRedirectUri: https://example.com/error?id=$id' \
-H 'statusCallbackUri: https://example.com/verificationResult' \
-H 'statusCallbackApiKey: myAPIKey' \
-H 'stateId: myUniqueStateValue' \
-H 'Content-Type: application/json' \
-d '{
"vp_policies": ["signature", "expired", "not-before"],
"vc_policies": ["signature", "expired", "not-before",
{"policy": "webhook", "args": "https://example.org/abc/xyz"}],
"request_credentials": [
{ "vct": "VerifiableDiploma", "format": "vc+sd-jwt" }
]
}'
Header Parameters
openid4vp://authorize or if you don't
know the wallet the user will be using to claim the credential. If you are using the same device flow, where you
already
know the user's wallet and want the user to be able to go directly to it, you can use the wallet URL path that is able
to
receive an OIDC request as a query parameter. Our wallet for example can receive OID4VC requests here
https://wallet.demo.walt.id/wallet-api/wallet/{wallet}/exchange/useOfferRequest.direct_post as the other options are not yet supported.$id
placeholder
to get access to the id of verification session in your application in order to retrieve the verification results.
E.g. /success?id=$id will be replaced with /success?id=1234567890$id
placeholder
to get access to the id of verification session in your application in order to retrieve the verification results.
E.g. /error?id=$id will be replaced with /error?id=1234567890POST including the whole presentation
result. See Verification Status Policies ResponsestatusCallbackUri is protected, you can use
the statusCallbackApiKey to authenticate.
The provided key will be appended as Authorization Header to the request.state value which gets created for each verification request with your
own.DEFAULT.
Apart from that, you can choose from the following options:HAIP: For the OID4VC HAIP profile.EBSIV3: For EBSI V3 compliant VP. Learn more here.ISO_18013_7_MDOC: For mdoc Openid4VP.Body Parameters
Below are the possible credential types and their respective object structures:
vct
attribute in the SD-JWT VC credential.vc+sd-jwt.
{ "vct": "test.com/identity_credential", "format": "vc+sd-jwt" }
VerifiableID, VerifiableDiploma). This maps to the type
attribute in W3C credentials.jwt_vc_json.
{ "type": "ProofOfResidence", "format": "jwt_vc_json" }
mso_mdoc.
{ "doc_type": "org.iso.18013.5.1.mDL", "format": "mso_mdoc" }
Optional Parameters
Next to describing the type and format of the credential, the objects also take an optional policies and id
attribute
Full Examples
{
"vct": "ProofOfResidence",
"format": "vc+sd-jwt",
"policies": [
"schema",
{
"policy": "webhook",
"args": "https://example.org/abc/xyz"
}
],
"id": "test123"
}
Upon execution, the system generates a URL, which can be shared directly with users or displayed as a QR code.
Please note that if you are using the HAIP profile, you cannot specify custom policies at this point.
In this example, which builds on the previous ones, we apply specific policies to a distinct credential in the verification process.
To do this:
request_credentials array.policies array to the same credential object to define policies that apply only to that credential.Here's how it looks in practice:
{
"vp_policies": [
"signature",
"expired"
],
"vc_policies": [
"signature",
"expired"
],
"request_credentials": [
{
"vct": "VerifiableId",
"format": "vc+sd-jwt"
},
{
"vct": "ProofOfResidence",
"format": "vc+sd-jwt"
},
{
"vct": "OpenBadgeCredential",
"format": "vc+sd-jwt",
"policies": [
"signature",
{
"policy": "webhook",
"args": "https://example.org/abc/xyz"
}
]
}
]
}
Key points from this example:
OpenBadgeCredential object in request_credentials is extended with a policies
array so that additional checks apply only to this credential."signature" does not require arguments and is therefore provided as a string."webhook" requires an argument and is therefore provided as an object with a policy and args field."VerifiableId" and "ProofOfResidence",
do not define custom policies and are verified against the globally defined vp_policies and vc_policies.Initiation Request
curl -X 'POST' \
'https://verifier.demo.walt.id/openid4vc/verify' \
-H 'accept: */*' \
-H 'authorizeBaseUrl: openid4vp://authorize' \
-H 'responseMode: direct_post' \
-H 'successRedirectUri: https://example.com/success?id=$id' \
-H 'errorRedirectUri: https://example.com/error?id=$id' \
-H 'statusCallbackUri: https://example.com/verificationResult' \
-H 'statusCallbackApiKey: myAPIKey' \
-H 'stateId: myUniqueStateValue' \
-H 'Content-Type: application/json' \
-d '{
"vp_policies": [
"signature",
"expired"
],
"vc_policies": [
"signature",
"expired"
],
"request_credentials": [
{
"vct": "VerifiableId",
"format": "vc+sd-jwt"
},
{
"vct": "ProofOfResidence",
"format": "vc+sd-jwt"
},
{
"vct": "OpenBadgeCredential",
"format": "vc+sd-jwt"
"policies": [
"signature",
{
"policy": "webhook",
"args": "https://example.org/abc/xyz"
}
]
}
]
}'
Header Parameters
openid4vp://authorize or if you don't
know the wallet the user will be using to claim the credential. If you are using the same device flow, where you
already
know the user's wallet and want the user to be able to go directly to it, you can use the wallet URL path that is able
to
receive an OIDC request as a query parameter. Our wallet for example can receive OID4VC requests here
https://wallet.demo.walt.id/wallet-api/wallet/{wallet}/exchange/useOfferRequest.direct_post as the other options are not yet supported.$id
placeholder
to get access to the id of verification session in your application in order to retrieve the verification results.
E.g. /success?id=$id will be replaced with /success?id=1234567890$id
placeholder
to get access to the id of verification session in your application in order to retrieve the verification results.
E.g. /error?id=$id will be replaced with /error?id=1234567890POST including the whole presentation
result. See Verification Status Policies ResponsestatusCallbackUri is protected, you can use
the statusCallbackApiKey to authenticate.
The provided key will be appended as Authorization Header to the request.state value which gets created for each verification request with your
own.DEFAULT.
Apart from that, you can choose from the following options:HAIP: For the OID4VC HAIP profile.EBSIV3: For EBSI V3 compliant VP. Learn more here.ISO_18013_7_MDOC: For mdoc Openid4VP.Body Parameters
Below are the possible credential types and their respective object structures:
vct
attribute in the SD-JWT VC credential.vc+sd-jwt.
{ "vct": "test.com/identity_credential", "format": "vc+sd-jwt" }
VerifiableID, VerifiableDiploma). This maps to the type
attribute in W3C credentials.jwt_vc_json.
{ "type": "ProofOfResidence", "format": "jwt_vc_json" }
mso_mdoc.
{ "doc_type": "org.iso.18013.5.1.mDL", "format": "mso_mdoc" }
Optional Parameters
Next to describing the type and format of the credential, the objects also take an optional policies and id
attribute
Full Examples
{
"vct": "ProofOfResidence",
"format": "jwt_vc_json",
"policies": [
"schema",
{
"policy": "webhook",
"args": "https://example.org/abc/xyz"
}
],
"id": "test123"
}
Upon execution, the system generates a URL, which can be shared directly with users or displayed as a QR code.
In this example, we explore how you can provide your own input_descriptor that will be merged with the autogenerated
presentation definition.
To implement a custom presentation definition:
input_descriptor for the
presentation definition.input_descriptor as part of an object in the request_credentials array so it can be merged with the
auto-generated definition (see example below).Important: Please also provide an id in the input_descriptor object.
Example
{
"vp_policies": [
...
],
"vc_policies": [
...
],
"request_credentials": [
{ "vct": "VerifiableId", "format": "vc+sd-jwt" },
{
"format": "vc+sd-jwt",
"vct": "https://issuer.com/identity_credential",
"input_descriptor": {
"id": "234",
"constraints": {
"fields": [
{
"path": [
"$.birthdate"
],
"filter": {
"type": "string",
"pattern": ".*"
}
}
]
}
}
}
]
}
On execution the verifier API will auto-generate the input descriptor for the VerifiableId credential that we specified via
the regular object and merge it with our custom input descriptor of the identity_credential to form the final presentation definition.
When using the input_descriptor make sure to also provide the presentation-definition policy in the
vp_policies array to ensure the constraints specified are checked during verification.
The presentation-definition policy also implements the
relational constraint feature.
These constraints let you define relations between issuer, holder and multiple credentials
within the input_descriptor.
Use this constraint when you want to ensure that the credential was self issued by the presenter. The verification will only succeed if the issuer DID matches the credential subject.
{
"vp_policies": ["presentation-definition"],
"request_credentials": [
{
"input_descriptor": {
"id": "OpenBadgeCredential",
"format": { "jwt_vc_json": { "alg": ["EdDSA"] } },
"constraints": {
"subject_is_issuer": "required",
"fields": [
{
"path": ["$.vc.type"],
"filter": { "type": "string", "pattern": "OpenBadgeCredential" }
}
]
}
}
}
]
}
is_holder ensures the presenter actually holds the credential referenced by
the selected field(s). It checks that the credential was issued to the holder
who is submitting the presentation.
{
"vp_policies": ["presentation-definition"],
"request_credentials": [
{
"input_descriptor": {
"id": "OpenBadgeCredential",
"format": { "jwt_vc_json": { "alg": ["EdDSA"] } },
"constraints": {
"is_holder": [
{ "field_id": ["achname"], "directive": "required" }
],
"fields": [
{
"path": ["$.vc.type"],
"filter": { "type": "string", "pattern": "OpenBadgeCredential" }
},
{
"id": "achname",
"path": ["$.vc.credentialSubject.achievement.name"]
}
]
}
}
}
]
}
This constraint enforces that the fields referenced across several credentials all relate to the same subject DID. Use it when multiple credentials must refer to one entity.
{
"vp_policies": ["presentation-definition"],
"request_credentials": [
{
"input_descriptor": {
"id": "OpenBadgeCredential",
"format": { "jwt_vc_json": { "alg": ["EdDSA"] } },
"constraints": {
"same_subject": [
{ "field_id": ["obc_achievement", "udc_degree"], "directive": "required" }
],
"fields": [
{
"path": ["$.vc.type"],
"filter": { "type": "string", "pattern": "OpenBadgeCredential" }
},
{
"id": "obc_achievement",
"path": ["$.vc.credentialSubject.achievement.name"]
}
]
}
}
},
{
"input_descriptor": {
"id": "UniversityDegreeCredential",
"format": { "jwt_vc_json": { "alg": ["EdDSA"] } },
"constraints": {
"fields": [
{
"path": ["$.vc.type"],
"filter": { "type": "string", "pattern": "UniversityDegreeCredential" }
},
{
"id": "udc_degree",
"path": ["$.vc.credentialSubject.degree.name"]
}
]
}
}
}
]
}
Using the URL returned by the verification request, we can fulfill the request using the hosted wallet by walt.id. Either show the URL as QR code and scan it with a camera or provide the URL as is in the text field below the camera once you click on "Scan to receive or present credentials" in the web wallet credentials overview page in the top right corner.
After the user presents the credential(s), you can verify the status by performing the following call with the
state value obtained from the URL query params you shared with the user previously.
Example
openid4vp://authorize?...state=a07bdb17-7d87-4965-9296-1adefcaaddd9...
Making the call to receive the verification result
curl -X 'GET' \
'https://verifier.demo.walt.id/openid4vc/session/$state' \
-H 'accept: */*'
The response of the verification status call will contain the status of the verification policies applied to the credential(s) presented by the user.
Example Response
{
"id": "HMUgYMpanNr8",
"presentationDefinition": {
"id": "Yk6xnKjuQW5h",
"input_descriptors": [
{
"id": "https://issuer.demo.walt.id/draft13/UniversityDegree",
"format": {
"vc+sd-jwt": {}
},
"constraints": {
"fields": [
{
"path": [
"$.vct"
],
"filter": {
"type": "string",
"pattern": "https://issuer.demo.walt.id/draft13/UniversityDegree"
}
}
],
"limit_disclosure": "required"
}
}
],
"customParameters": {}
},
"tokenResponse": {
"vp_token": "eyJraWQiOiJkaWQ6andrOmV5SnJkSGtpT2lKRlF5SXNJbU55ZGlJNklsQXRNalUySWl3aWEybGtJam9pTTFsT1pEbEdibmc1U214NVVGWlpkMmRYUmtVek4wVXpSM2RKTUdWSGJFTkxPSGRHYkZkNFIyWndUU0lzSW5naU9pSkdiM1paTWpGTVFVRlBWR3huTFcwdFRtVkxWMmhhUlV3MVlVWnlibEl3ZFdOS2FrUTFWRXR3UjNWbklpd2llU0k2SWtOeVJrcG1SMVJrVURJNVNrcGpZM0JSV0hWNVRVOHpiMmgwZW5KVWNWQjZRbEJDU1ZSWmFqQnZaMEVpZlEjM1lOZDlGbng5Smx5UFZZd2dXRkUzN0UzR3dJMGVHbENLOHdGbFd4R2ZwTSIsInR5cCI6InZjK3NkLWp3dCIsImFsZyI6IkVTMjU2In0.eyJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMifSwiaWF0IjoxNzQ3MDM0NTA0LCJuYmYiOjE3NDcwMzQ1MDQsImV4cCI6MTc3ODU3MDUwNCwiaXNzIjoiZGlkOmp3azpleUpyZEhraU9pSkZReUlzSW1OeWRpSTZJbEF0TWpVMklpd2lhMmxrSWpvaU0xbE9aRGxHYm5nNVNteDVVRlpaZDJkWFJrVXpOMFV6UjNkSk1HVkhiRU5MT0hkR2JGZDRSMlp3VFNJc0luZ2lPaUpHYjNaWk1qRk1RVUZQVkd4bkxXMHRUbVZMVjJoYVJVdzFZVVp5YmxJd2RXTktha1ExVkV0d1IzVm5JaXdpZVNJNklrTnlSa3BtUjFSa1VESTVTa3BqWTNCUldIVjVUVTh6YjJoMGVuSlVjVkI2UWxCQ1NWUlphakJ2WjBFaWZRIiwiY25mIjp7Imp3ayI6eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5Iiwia2lkIjoiTHFRb1g5SDI2MFVEWVJRVS1hOG9mUVZqd1V4R2FOT0s1UnVsaXVUSy1RbyIsIngiOiJpM0MtaF9tZzQ2Y3Z5YUZlZWNZUkRyUkJiZ1ZwZXZiS3JldmlrT3BwaTQ0In19LCJ2Y3QiOiJodHRwczovL2lzc3Vlci5kZW1vLndhbHQuaWQvZHJhZnQxMy9Vbml2ZXJzaXR5RGVncmVlIiwiZGlzcGxheSI6W10sIl9zZCI6WyJQWW9XY2h1cnZiUHVkbGtQa3RCTmZDbnlOS2JVZWpCcENsNzhQblZodElrIl19.7-Qx3wnY2kzMVnN4No-jylEy9-ZuNzWcgY77_UzqqWxZLtcmsYi4qgL7ICfZMP7Ffdt4Eiu--0DS15K82aTwGg~WyJ2ZnBTY2w2V1hveGZxZURrWHJ3NEp3IiwiaWQiLCJ1cm46dXVpZDpkYjVmZTIyNS1lYWM0LTQxYjctODA5My0zMDEyNTk3ZjlmOTAiXQ~eyJraWQiOiJMcVFvWDlIMjYwVURZUlFVLWE4b2ZRVmp3VXhHYU5PSzVSdWxpdVRLLVFvIiwidHlwIjoia2Irand0IiwiYWxnIjoiRWREU0EifQ.eyJpYXQiOjE3NDcwMzQ1NDgsImF1ZCI6Imh0dHBzOi8vdmVyaWZpZXIuZGVtby53YWx0LmlkL29wZW5pZDR2Yy92ZXJpZnkiLCJub25jZSI6ImIwMDQyNGZlLTg4MTAtNDQ0YS04MjgxLWJkZjA3MTQyOTU2ZiIsInNkX2hhc2giOiJjTmtKR200UzZWUWowdU5NQ3ktcEZBLXNqUk5jTE1GUzc5VXdXd1IyU1cwIn0.ORfyjO36JPY5Rzn5f1zt4rYZ12rrD7uj0I28lN77TWsKYSdR5pwaAGAQbUSUCD2ah9RidjgaeQo15DaFd82kAw",
"presentation_submission": {
"id": "Yk6xnKjuQW5h",
"definition_id": "Yk6xnKjuQW5h",
"descriptor_map": [
{
"id": "Yk6xnKjuQW5h",
"format": "vc+sd-jwt",
"path": "$"
}
]
},
"state": "HMUgYMpanNr8",
"customParameters": {}
},
"verificationResult": true,
"policyResults": {
"results": [
{
"credential": "eyJraWQiOiJkaWQ6andrOmV5SnJkSGtpT2lKRlF5SXNJbU55ZGlJNklsQXRNalUySWl3aWEybGtJam9pTTFsT1pEbEdibmc1U214NVVGWlpkMmRYUmtVek4wVXpSM2RKTUdWSGJFTkxPSGRHYkZkNFIyWndUU0lzSW5naU9pSkdiM1paTWpGTVFVRlBWR3huTFcwdFRtVkxWMmhhUlV3MVlVWnlibEl3ZFdOS2FrUTFWRXR3UjNWbklpd2llU0k2SWtOeVJrcG1SMVJrVURJNVNrcGpZM0JSV0hWNVRVOHpiMmgwZW5KVWNWQjZRbEJDU1ZSWmFqQnZaMEVpZlEjM1lOZDlGbng5Smx5UFZZd2dXRkUzN0UzR3dJMGVHbENLOHdGbFd4R2ZwTSIsInR5cCI6InZjK3NkLWp3dCIsImFsZyI6IkVTMjU2In0.eyJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IkJhY2hlbG9yIG9mIFNjaWVuY2UgYW5kIEFydHMifSwiaWF0IjoxNzQ3MDM0NTA0LCJuYmYiOjE3NDcwMzQ1MDQsImV4cCI6MTc3ODU3MDUwNCwiaXNzIjoiZGlkOmp3azpleUpyZEhraU9pSkZReUlzSW1OeWRpSTZJbEF0TWpVMklpd2lhMmxrSWpvaU0xbE9aRGxHYm5nNVNteDVVRlpaZDJkWFJrVXpOMFV6UjNkSk1HVkhiRU5MT0hkR2JGZDRSMlp3VFNJc0luZ2lPaUpHYjNaWk1qRk1RVUZQVkd4bkxXMHRUbVZMVjJoYVJVdzFZVVp5YmxJd2RXTktha1ExVkV0d1IzVm5JaXdpZVNJNklrTnlSa3BtUjFSa1VESTVTa3BqWTNCUldIVjVUVTh6YjJoMGVuSlVjVkI2UWxCQ1NWUlphakJ2WjBFaWZRIiwiY25mIjp7Imp3ayI6eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5Iiwia2lkIjoiTHFRb1g5SDI2MFVEWVJRVS1hOG9mUVZqd1V4R2FOT0s1UnVsaXVUSy1RbyIsIngiOiJpM0MtaF9tZzQ2Y3Z5YUZlZWNZUkRyUkJiZ1ZwZXZiS3JldmlrT3BwaTQ0In19LCJ2Y3QiOiJodHRwczovL2lzc3Vlci5kZW1vLndhbHQuaWQvZHJhZnQxMy9Vbml2ZXJzaXR5RGVncmVlIiwiZGlzcGxheSI6W10sIl9zZCI6WyJQWW9XY2h1cnZiUHVkbGtQa3RCTmZDbnlOS2JVZWpCcENsNzhQblZodElrIl19.7-Qx3wnY2kzMVnN4No-jylEy9-ZuNzWcgY77_UzqqWxZLtcmsYi4qgL7ICfZMP7Ffdt4Eiu--0DS15K82aTwGg~WyJ2ZnBTY2w2V1hveGZxZURrWHJ3NEp3IiwiaWQiLCJ1cm46dXVpZDpkYjVmZTIyNS1lYWM0LTQxYjctODA5My0zMDEyNTk3ZjlmOTAiXQ~eyJraWQiOiJMcVFvWDlIMjYwVURZUlFVLWE4b2ZRVmp3VXhHYU5PSzVSdWxpdVRLLVFvIiwidHlwIjoia2Irand0IiwiYWxnIjoiRWREU0EifQ.eyJpYXQiOjE3NDcwMzQ1NDgsImF1ZCI6Imh0dHBzOi8vdmVyaWZpZXIuZGVtby53YWx0LmlkL29wZW5pZDR2Yy92ZXJpZnkiLCJub25jZSI6ImIwMDQyNGZlLTg4MTAtNDQ0YS04MjgxLWJkZjA3MTQyOTU2ZiIsInNkX2hhc2giOiJjTmtKR200UzZWUWowdU5NQ3ktcEZBLXNqUk5jTE1GUzc5VXdXd1IyU1cwIn0.ORfyjO36JPY5Rzn5f1zt4rYZ12rrD7uj0I28lN77TWsKYSdR5pwaAGAQbUSUCD2ah9RidjgaeQo15DaFd82kAw",
"policyResults": [
{
"policy": "signature_sd-jwt-vc",
"description": "Checks a SD-JWT-VC credential by verifying its cryptographic signature using the key referenced by the DID in `iss`.",
"is_success": true,
"result": {
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
},
"iat": 1747034504,
"nbf": 1747034504,
"exp": 1778570504,
"iss": "did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2Iiwia2lkIjoiM1lOZDlGbng5Smx5UFZZd2dXRkUzN0UzR3dJMGVHbENLOHdGbFd4R2ZwTSIsIngiOiJGb3ZZMjFMQUFPVGxnLW0tTmVLV2haRUw1YUZyblIwdWNKakQ1VEtwR3VnIiwieSI6IkNyRkpmR1RkUDI5SkpjY3BRWHV5TU8zb2h0enJUcVB6QlBCSVRZajBvZ0EifQ",
"cnf": {
"jwk": {
"kty": "OKP",
"crv": "Ed25519",
"kid": "LqQoX9H260UDYRQU-a8ofQVjwUxGaNOK5RuliuTK-Qo",
"x": "i3C-h_mg46cvyaFeecYRDrRBbgVpevbKrevikOppi44"
}
},
"vct": "https://issuer.demo.walt.id/draft13/UniversityDegree",
"display": [],
"_sd": [
"PYoWchurvbPudlkPktBNfCnyNKbUejBpCl78PnVhtIk"
]
}
}
]
}
],
"time": "PT0.012000955S",
"policiesRun": 1
},
"customParameters": {}
}
The most relevant fields in the response are:
verificationResult: Indicates whether all applied policies were successful (true) or if any policy failed
(false).policyResults: Contains the results of the policies applied to each credential:
credential: Name or identifier of the credential.policies / policyResults entries:
policy: Name of the policy that was executed.is_success: Boolean result of the policy execution.After a successful presentation session (verificationResult is true), you can retrieve a decoded and formatted
view of all credentials presented by the holder.
You can choose between two view modes:
simple: Recommended default view; provides a concise, human-friendly representation suitable for most use cases.verbose: Provides additional technical detail useful for debugging, auditing, and in-depth inspection.Endpoint: /openid4vc/session/{id}/presented-credentials | API Reference
Path Parameters
id (required)- The identifier of the presentation session whose credentials should be retrieved.Query Parameters
viewMode (optional) - Controls how detailed the response will be. Available values are simple and verbose
(defaults to simple).Response Body
viewMode - Echoed request value (or the default if it was not specified).credentialsByFormat : A map where each key is a presentation format (jwt_vc_json, sd_jwt_vc, mso_mdoc)
and the value is an array of decoded presented credentials, formatted as JSON objects and whose properties vary
according to the value of viewMode:sd_jwt_vc in simple view mode:vc - JSON object that provides the decoded IETF SD-JWT-VC credential and is composed of the following properties:
header - The JWT header section of the credential.payload - The JWT payload section of the verifiable credential provided as a JSON
object with all disclosures (if provided) substituted.keyBinding - JSON object that provides the decoded Key Binding JWT, assuming it was requested/provided in
the context of the presentation session and is composed of the following properties:
header - The JWT header section of the verifiable presentation provided as a JSON object.payload - The JWT payload section of the verifiable presentation provided as a JSON object.sd_jwt_vc in verbose view mode:raw - The compact serialized IETF SD-JWT-VC.vc - JSON object that provides verbosely decoded IETF SD-JWT-VC and is composed of the following
properties:
header - The JWT header section of the IETF SD-JWT-VC provided as a JSON object.fullPayload - The JWT payload section of the IETF SD-JWT-VC provided as a JSON
object with all disclosures (if provided) substituted.undisclosedPayload - The JWT payload section of the IETF SD-JWT-VC provided as a JSON
object without any disclosures substituted (if provided).disclosures - A map between selective disclosure (hashed) values and a JSON object that provides
their decoded representation as provided by the wallet. This property is only present if disclosable
claims were requested/provided in the context of the presentation session.keyBinding - JSON object that provides the decoded Key Binding JWT, assuming it was requested/provided in
the context of the presentation session and is composed of the following properties:
header - The JWT header section of the verifiable presentation provided as a JSON object.payload - The JWT payload section of the verifiable presentation provided as a JSON object.In the following we provide an example that involves the presentation of an IETF SD-JWT-VC Identity Credential
with two disclosable claims, namely, the family_name and birthdate properties.
Example Request
curl -X 'GET' \
'http://0.0.0.0:7003/openid4vc/session/{id}/presented-credentials' \
-H 'accept: application/json'
Example Response
{
"credentialsByFormat": {
"vc+sd-jwt": [
{
"type": "sd_jwt_vc_view_simple",
"vc": {
"header": {
"x5c": [
"-----BEGIN CERTIFICATE-----\nMIIBeTCCAR8CFHrWgrGl5KdefSvRQhR+aoqdf48+MAoGCCqGSM49BAMCMBcxFTATBgNVBAMMDE1ET0MgUk9PVCBDQTAgFw0yNTA1MTQxNDA4MDlaGA8yMDc1MDUwMjE0MDgwOVowZTELMAkGA1UEBhMCQVQxDzANBgNVBAgMBlZpZW5uYTEPMA0GA1UEBwwGVmllbm5hMRAwDgYDVQQKDAd3YWx0LmlkMRAwDgYDVQQLDAd3YWx0LmlkMRAwDgYDVQQDDAd3YWx0LmlzMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEG0RINBiF+oQUD3d5DGnegQuXenI29JDaMGoMvioKRBN53d4UazakS2unu8BnsEtxutS2kqRhYBPYk9RAriU3gTAKBggqhkjOPQQDAgNIADBFAiAOMwM7hH7q9Di+mT6qCi4LvB+kH8OxMheIrZ2eRPxtDQIhALHzTxwvN8Udt0Z2Cpo8JBihqacfeXkIxVAO8XkxmXhB\n-----END CERTIFICATE-----"
],
"kid": "9vuaJyUxRx4KmHyoZ9kjJxMs_mjpnnf-mPM9nPMG51A",
"typ": "vc+sd-jwt",
"alg": "ES256"
},
"payload": {
"given_name": "John",
"email": "johndoe@example.com",
"phone_number": "+1-202-555-0101",
"address": {
"street_address": "123 Main St",
"locality": "Anytown",
"region": "Anystate",
"country": "US"
},
"is_over_18": true,
"is_over_21": true,
"is_over_65": true,
"id": "urn:uuid:f4411ed9-d3eb-4c5d-971a-ffb2872b616d",
"iat": 1752648454,
"nbf": 1752648454,
"exp": 1784184454,
"iss": "http://localhost:22222/draft13",
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"kid": "pE7QRzzJ3utoKynTja7JyeAzcQefzZO24rEdWwkGtT0",
"x": "oRIMe5XVIcJGDSW10r19w5jym8W-btkxChzecsuXUhc",
"y": "XQrS0p2BJf_WXIcn-RAdFoX17DJsefpED3Ct4t4W-X0"
}
},
"vct": "http://localhost:22222/identity_credential",
"display": [],
"family_name": "Doe",
"birthdate": "1940-01-01"
}
},
"keyBinding": {
"header": {
"kid": "pE7QRzzJ3utoKynTja7JyeAzcQefzZO24rEdWwkGtT0",
"typ": "kb+jwt",
"alg": "ES256"
},
"payload": {
"iat": 1752648455,
"aud": "http://localhost:22222/openid4vc/verify",
"nonce": "196b37da-77d0-463f-897c-5a0c1c6d5623",
"sd_hash": "iywnYcva2cWTVcclB1gECoI-x-y3IGz07snR_4QiWyE"
}
}
}
]
},
"viewMode": "simple"
}
On this page