How to Verify a W3C Verifiable Credential (JWT / SD-JWT) via OID4VP with walt.id

TL;DR

This guide walks through verifying W3C JWT and SD-JWT credentials via OID4VP using the walt.id verifier API, covering request setup, policy enforcement, and result inspection. It shows how to manage redirects, callbacks, presentation definitions, and debugging data returned by the verifier endpoints.

What you’ll learn

  • Configure an OID4VP compliant authorization request using the /verify endpoint.
  • Apply VP/VC verification policies on received credentials.
  • Use custom input descriptors and relational constraints to enforce issuer, holder, or subject relationships.
  • Retrieve verification status, policy results, and inspect presented credentials via the verifier API.

This guide provides a comprehensive walkthrough for verifying a Verifiable Credential based on the W3C 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.

Verifiable Credential (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.

Preparing the Verification

First, determine the type of Verifiable Credential to be verified. Although this guide focuses on a "VerifiableDiploma," you can use any credential type compliant with the W3C standard.

The verification process will be as follows:

  1. Specify the credential type(s) to request from a user and the verification policies to be applied to the credential( s).
  2. Optionally provide a success and failure redirect URL, which the user will be redirected to after the verification process is completed.

After you have provided the required information:

  1. The API generates a Presentation Definition.
  2. API returns a URL which can passed to OIDC-compliant wallet to fulfill the request.

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.

Example Verification Request 1 - Basic

For this example, we will only do a simple verification, where we request one credential type, a Verifiable Diploma, and let the system apply the default signature policy to verify the validity of the signature of the presented credential. Optionally we can provide a success and failure redirect URL, which the user will be redirected to after the verification.

CURL
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": [
    { "type": "VerifiableDiploma", "format": "jwt_vc_json" }
  ]
}'

Header Parameters

  • authorizeBaseUrl - is used to modify the start of the OID4VC request URL. If you are using the cross-device flow, where you will display the URL as a QR code, you can leave the value as 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.
  • responseMode - should be direct_post as the other options are not yet supported.
  • successRedirectUri (optional) - is used to redirect the user if verification is successful. You can use the $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
  • errorRedirectUri (optional) - is used to redirect the user if verification is unsuccessful. You can use the $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=1234567890
  • statusCallbackUri (optional) - URL that should be called when the presentation request has been fulfilled by a wallet. The request sent will be a POST including the whole presentation result. See Verification Status Policies Response
  • statusCallbackApiKey (optional) - If the endpoint you provide via statusCallbackUri is protected, you can use the statusCallbackApiKey to authenticate. The provided key will be appended as Authorization Header to the request.
  • stateId (optional) - overwrite the unique state value which gets created for each verification request with your own.
  • openId4VPProfile (optional) - Define profile for VP (Verifiable Presentation) request. The default is W3C OpenID4VP, which can optionally provided as DEFAULT. Apart from that, you can choose from the following options:
    • EBSIV3: For EBSI V3 compliant VP. Learn more here.
    • ISO_18013_7_MDOC: For mdoc Openid4VP.

Body Parameters

  • request_credentials - An array of objects detailing the credentials to be requested from the user. Each object varies based on the type of credential being requested.
    Expand To Learn More

    Below are the possible credential types and their respective object structures:

    1. W3C JWT Credential
      • type Specifies the type of credential (e.g., VerifiableID, VerifiableDiploma). This maps to the type attribute in W3C credentials.
      • format: Describes the format of the credential. For W3C JWT credentials, this would be jwt_vc_json.
      { "type": "ProofOfResidence", "format": "jwt_vc_json" }
      
    2. SD-JWT VC Credential (IETF Standard)
      • vct: Specifies the type of credential (e.g., https://issuer.com/identity_credential). This maps to the vct attribute in the SD-JWT VC credential.
      • format: Describes the format of the credential. For SD-JWT VC credentials, this would be vc+sd-jwt.: Describes the format of the credential. For SD-JWT VC credentials, this would be vc+sd-jwt.
      { "vct": "test.com/identity_credential", "format": "vc+sd-jwt" }
      
    3. mDL Credential (ISO/IEC 18013-5)
      • doc_type: Specifies the type of credential (e.g., org.iso.18013.5.1.mDL). This maps to the doc_type attribute of the mdoc document.
      • format: Describes the format of the credential. For mDL credentials, this would be 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

    • policies: An array of policies to apply to the specified credential. A list of all policies can be found here.
    • id: Used to set a specific id for the generated Presentation Definition. If not set, the verifier API auto-assigns a generated one.

    Full Examples

     {
      "type": "ProofOfResidence",
      "format": "jwt_vc_json",
      "policies": [
        "schema",
        {
          "policy": "webhook",
          "args": "https://example.org/abc/xyz"
        }
      ],
      "id": "test123"
     }
    

Example Verification Request 2 - Defining VC/VP Policies

In this example, we not only specify the types of credentials to verify, but also define the policies that should be executed during verification:

  • VC policies (vc_policies): Applied to individual Verifiable Credentials (VCs).
  • VP policies (vp_policies): Applied to the Verifiable Presentation (VP) as a whole.
  • Default behavior: The signature policy is applied by default to both VP and VC(s).
  • Policy catalog: A list of available policies can be found here.

How VC policies are applied:

  • Global scope: Once defined, VC policies are applied globally to all requested credentials in the verification session.
  • Per-credential override: A later section shows how to customize and apply specific policies to individual credentials when needed.

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.
  • Identical structure: Both fields share the same structure.
  • Policy representation:
    • As a string if the policy does not require arguments.
    • As an object if the policy requires arguments.

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
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": [
        { "type": "VerifiableDiploma", "format": "jwt_vc_json" }
      ]
   }'

Header Parameters

  • authorizeBaseUrl - is used to modify the start of the OID4VC request URL. If you are using the cross-device flow, where you will display the URL as a QR code, you can leave the value as 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.
  • responseMode - should be direct_post as the other options are not yet supported.
  • successRedirectUri (optional) - is used to redirect the user if verification is successful. You can use the $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
  • errorRedirectUri (optional) - is used to redirect the user if verification is unsuccessful. You can use the $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=1234567890
  • statusCallbackUri (optional) - URL that should be called when the presentation request has been fulfilled by a wallet. The request sent will be a POST including the whole presentation result. See Verification Status Policies Response
  • statusCallbackApiKey (optional) - If the endpoint you provide via statusCallbackUri is protected, you can use the statusCallbackApiKey to authenticate. The provided key will be appended as Authorization Header to the request.
  • stateId (optional) - overwrite the unique state value which gets created for each verification request with your own.
  • openId4VPProfile (optional) - Define profile for VP (Verifiable Presentation) request. The default is W3C OpenID4VP, which can optionally provided as DEFAULT. Apart from that, you can choose from the following options:
    • EBSIV3: For EBSI V3 compliant VP. Learn more here.
    • ISO_18013_7_MDOC: For mdoc Openid4VP.

Body Parameters

  • vp_policies - Policies applied to the Verifiable Presentation. A list of policies can be found here
  • vc_policies - Policies applied to all requested credentials. A list of policies can be found here.
  • request_credentials - An array of objects detailing the credentials to be requested from the user. Each object varies based on the type of credential being requested.
    Expand To Learn More

    Below are the possible credential types and their respective object structures:

    1. W3C JWT Credential
      • type Specifies the type of credential (e.g., VerifiableID, VerifiableDiploma). This maps to the type attribute in W3C credentials.
      • format: Describes the format of the credential. For W3C JWT credentials, this would be jwt_vc_json.
      { "type": "ProofOfResidence", "format": "jwt_vc_json" }
      
    2. SD-JWT VC Credential (IETF Standard)
      • vct: Specifies the type of credential (e.g., https://issuer.com/identity_credential). This maps to the vct attribute in the SD-JWT VC credential.
      • format: Describes the format of the credential. For SD-JWT VC credentials, this would be vc+sd-jwt.: Describes the format of the credential. For SD-JWT VC credentials, this would be vc+sd-jwt.
      { "vct": "test.com/identity_credential", "format": "vc+sd-jwt" }
      
    3. mDL Credential (ISO/IEC 18013-5)
      • doc_type: Specifies the type of credential (e.g., org.iso.18013.5.1.mDL). This maps to the doc_type attribute of the mdoc document.
      • format: Describes the format of the credential. For mDL credentials, this would be 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

    • policies: An array of policies to apply to the specified credential. A list of all policies can be found here.
    • id: Used to set a specific id for the generated Presentation Definition. If not set, the verifier API auto-assigns a generated one.

    Full Examples

     {
      "type": "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.

Example Verification Request 3: Applying Policies to Specific Credentials

In this example, which builds up on the previous ones, we'll demonstrate how to apply specific policies to a distinct credential in the verification process. This is achieved by specifying next to the required credential type and format, the policies that should be applied as an array in the credential specification object which goes into the requested_credentials array. A list of supported policies can be found here.

Here's how it looks in practice:

{
  "vp_policies": [
    "signature",
    "expired"
  ],
  "vc_policies": [
    "signature",
    "expired"
  ],
  "request_credentials": [
    {
      "type": "VerifiableId",
      "format": "jwt_vc_json"
    },
    {
      "type": "ProofOfResidence",
      "format": "jwt_vc_json"
    },
    {
      "type": "OpenBadgeCredential",
      "format": "jwt_vc_json",
      "policies": [
        "signature",
        {
          "policy": "webhook",
          "args": "https://example.org/abc/xyz"
        }
      ]
    }
  ]
}

In this code snippet, we extended the regular credential specification object that goes into request_credentials to include policies that should be applied only to the "OpenBadgeCredential". The first policy "signature" doesn't require any arguments and can therefore be provided as a string. The "webhook" policy does require an argument and is therefore provided as an object. A list of different types of policies and their required arguments can be found here.

Meanwhile, the other requested credentials, "VerifiableId" and "ProofOfResidence", don't specify and custom policies, meaning they will be verified against the globally defined "vp_policies" and "vc_policies".

Initiation Request

CURL
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": [
    { "type": "VerifiableId", "format": "jwt_vc_json" },
    { "type": "ProofOfResidence", "format": "jwt_vc_json" },
    {
      "type": "OpenBadgeCredential",
      "format": "jwt_vc_json"
      "policies": [
        "signature",
        {
          "policy": "webhook",
          "args": "https://example.org/abc/xyz"
        }
      ]
    }
  ]
}'

Header Parameters

  • authorizeBaseUrl - is used to modify the start of the OID4VC request URL. If you are using the cross-device flow, where you will display the URL as a QR code, you can leave the value as 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.
  • responseMode - should be direct_post as the other options are not yet supported.
  • successRedirectUri (optional) - is used to redirect the user if verification is successful. You can use the $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
  • errorRedirectUri (optional) - is used to redirect the user if verification is unsuccessful. You can use the $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=1234567890
  • statusCallbackUri (optional) - URL that should be called when the presentation request has been fulfilled by a wallet. The request sent will be a POST including the whole presentation result. See Verification Status Policies Response
  • statusCallbackApiKey (optional) - If the endpoint you provide via statusCallbackUri is protected, you can use the statusCallbackApiKey to authenticate. The provided key will be appended as Authorization Header to the request.
  • stateId (optional) - overwrite the unique state value which gets created for each verification request with your own.
  • openId4VPProfile (optional) - Define profile for VP (Verifiable Presentation) request. The default is W3C OpenID4VP, which can optionally provided as DEFAULT. Apart from that, you can choose from the following options:
    • EBSIV3: For EBSI V3 compliant VP. Learn more here.
    • ISO_18013_7_MDOC: For mdoc Openid4VP.

Body Parameters

  • vp_policies - Policies applied to the Verifiable Presentation. A list of policies can be found here
  • vc_policies - Policies applied to all requested credentials. A list of policies can be found here.
  • request_credentials - An array of objects detailing the credentials to be requested from the user. Each object varies based on the type of credential being requested.
    Expand To Learn More

    Below are the possible credential types and their respective object structures:

    1. W3C JWT Credential
      • type Specifies the type of credential (e.g., VerifiableID, VerifiableDiploma). This maps to the type attribute in W3C credentials.
      • format: Describes the format of the credential. For W3C JWT credentials, this would be jwt_vc_json.
      { "type": "ProofOfResidence", "format": "jwt_vc_json" }
      
    2. SD-JWT VC Credential (IETF Standard)
      • vct: Specifies the type of credential (e.g., https://issuer.com/identity_credential). This maps to the vct attribute in the SD-JWT VC credential.
      • format: Describes the format of the credential. For SD-JWT VC credentials, this would be vc+sd-jwt.: Describes the format of the credential. For SD-JWT VC credentials, this would be vc+sd-jwt.
      { "vct": "test.com/identity_credential", "format": "vc+sd-jwt" }
      
    3. mDL Credential (ISO/IEC 18013-5)
      • doc_type: Specifies the type of credential (e.g., org.iso.18013.5.1.mDL). This maps to the doc_type attribute of the mdoc document.
      • format: Describes the format of the credential. For mDL credentials, this would be 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

    • policies: An array of policies to apply to the specified credential. A list of all policies can be found here.
    • id: Used to set a specific id for the generated Presentation Definition. If not set, the verifier API auto-assigns a generated one.

    Full Examples

     {
      "type": "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.

Example Verification Request 4: Implementing a Custom Presentation Definition

In this example, we'll explore how you can provide your own input_descriptor that will be merged with the autogenerated presentation definition. You can specify your custom input_descriptor for the presentation definition via an object in the request_credentials array, see example blow.

Important: Please also provide an id in the input_descriptor object.


Example

{
  "vp_policies": [
    ...
  ],
  "vc_policies": [
    ...
  ],
  "request_credentials": [
    {
      "type": "VerifiableId",
      "format": "jwt_vc_json"
    },
    {
      "format": "jwt_vc_json",
      "type": "OpenBadgeCredential",
      "input_descriptor": {
        "id": "234",
        "constraints": {
          "fields": [
            {
              "path": [
                "$.name"
              ],
              "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.

Example Verification Request 5: Using Relational Constraints

The presentation-definition policy also supports the relational constraint feature. It allows you to express relations between issuer, holder and multiple credentials directly within the input_descriptor.

subject_is_issuer

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

The is_holder option checks that a credential was issued to the same entity that is presenting the verifiable presentation. Use it to bind specific fields to the holder's DID.

{
  "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"]
            }
          ]
        }
      }
    }
  ]
}

same_subject

Use same_subject when multiple credentials should refer to the same underlying subject. The verifier compares the listed fields and only accepts the presentation if they share an identical subject DID.

{
  "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"]
            }
          ]
        }
      }
    }
  ]
}

Presenting the Credential via walt.id Wallet

Using the URL returned by the verification request, you can fulfill the request using the hosted wallet by walt.id.

To present the credential:

  1. Open the hosted wallet and click "Scan to receive or present credentials" on the credentials overview page in the top right corner.
  2. Choose how to provide the URL:
    • Scan a QR code that encodes the URL with your device camera.
    • Paste the URL directly into the text field below the camera.

Retrieving the Verification Status

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: */*'

Verification Status Policies Response

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": "X31C7TERsFzR",
  "presentationDefinition": {
    "id": "HbIdo1BMxEwf",
    "input_descriptors": [
      {
        "id": "UniversityDegree",
        "format": {
          "jwt_vc_json": {
            "alg": [
              "EdDSA"
            ]
          }
        },
        "constraints": {
          "fields": [
            {
              "path": [
                "$.vc.type"
              ],
              "filter": {
                "type": "string",
                "pattern": "UniversityDegree"
              }
            }
          ]
        }
      }
    ],
    "customParameters": {}
  },
  "tokenResponse": {
    "vp_token": "eyJraWQiOiJkaWQ6andrOmV5SnJkSGtpT2lKUFMxQWlMQ0pqY25ZaU9pSkZaREkxTlRFNUlpd2lhMmxrSWpvaVRIRlJiMWc1U0RJMk1GVkVXVkpSVlMxaE9HOW1VVlpxZDFWNFIyRk9UMHMxVW5Wc2FYVlVTeTFSYnlJc0luZ2lPaUpwTTBNdGFGOXRaelEyWTNaNVlVWmxaV05aVWtSeVVrSmlaMVp3WlhaaVMzSmxkbWxyVDNCd2FUUTBJbjAjMCIsInR5cCI6IkpXVCIsImFsZyI6IkVkRFNBIn0.eyJzdWIiOiJkaWQ6andrOmV5SnJkSGtpT2lKUFMxQWlMQ0pqY25ZaU9pSkZaREkxTlRFNUlpd2lhMmxrSWpvaVRIRlJiMWc1U0RJMk1GVkVXVkpSVlMxaE9HOW1VVlpxZDFWNFIyRk9UMHMxVW5Wc2FYVlVTeTFSYnlJc0luZ2lPaUpwTTBNdGFGOXRaelEyWTNaNVlVWmxaV05aVWtSeVVrSmlaMVp3WlhaaVMzSmxkbWxyVDNCd2FUUTBJbjAiLCJuYmYiOjE3NDcwMzQwMDAsImlhdCI6MTc0NzAzNDA2MCwianRpIjoiSGJJZG8xQk14RXdmIiwiaXNzIjoiZGlkOmp3azpleUpyZEhraU9pSlBTMUFpTENKamNuWWlPaUpGWkRJMU5URTVJaXdpYTJsa0lqb2lUSEZSYjFnNVNESTJNRlZFV1ZKUlZTMWhPRzltVVZacWQxVjRSMkZPVDBzMVVuVnNhWFZVU3kxUmJ5SXNJbmdpT2lKcE0wTXRhRjl0WnpRMlkzWjVZVVpsWldOWlVrUnlVa0ppWjFad1pYWmlTM0psZG1sclQzQndhVFEwSW4wIiwibm9uY2UiOiI2ZTZiN2UzYy1lN2ZkLTQxMzYtYWIyNS1iOTUyYWJiNDVmYzUiLCJhdWQiOiJodHRwczovL3ZlcmlmaWVyLmRlbW8ud2FsdC5pZC9vcGVuaWQ0dmMvdmVyaWZ5IiwidnAiOnsiQGNvbnRleHQiOlsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiXSwidHlwZSI6WyJWZXJpZmlhYmxlUHJlc2VudGF0aW9uIl0sImlkIjoiSGJJZG8xQk14RXdmIiwiaG9sZGVyIjoiZGlkOmp3azpleUpyZEhraU9pSlBTMUFpTENKamNuWWlPaUpGWkRJMU5URTVJaXdpYTJsa0lqb2lUSEZSYjFnNVNESTJNRlZFV1ZKUlZTMWhPRzltVVZacWQxVjRSMkZPVDBzMVVuVnNhWFZVU3kxUmJ5SXNJbmdpT2lKcE0wTXRhRjl0WnpRMlkzWjVZVVpsWldOWlVrUnlVa0ppWjFad1pYWmlTM0psZG1sclQzQndhVFEwSW4wIiwidmVyaWZpYWJsZUNyZWRlbnRpYWwiOlsiZXlKcmFXUWlPaUprYVdRNmFuZHJPbVY1U25Ka1NHdHBUMmxLUmxGNVNYTkpiVTU1WkdsSk5rbHNRWFJOYWxVeVNXbDNhV0V5Ykd0SmFtOXBUVEZzVDFwRWJFZGlibWMxVTIxNE5WVkdXbHBrTW1SWVVtdFZlazR3VlhwU00yUktUVWRXU0dKRlRreFBTR1JIWWtaa05GSXlXbmRVVTBselNXNW5hVTlwU2tkaU0xcGFUV3BHVFZGVlJsQldSM2h1VEZjd2RGUnRWa3hXTW1oaFVsVjNNVmxWV25saWJFbDNaRmRPUzJGclVURldSWFIzVWpOV2JrbHBkMmxsVTBrMlNXdE9lVkpyY0cxU01WSnJWVVJKTlZOcmNHcFpNMEpTVjBoV05WUlZPSHBpTW1nd1pXNUtWV05XUWpaUmJFSkRVMVpTV21GcVFuWmFNRVZwWmxFak0xbE9aRGxHYm5nNVNteDVVRlpaZDJkWFJrVXpOMFV6UjNkSk1HVkhiRU5MT0hkR2JGZDRSMlp3VFNJc0luUjVjQ0k2SWtwWFZDSXNJbUZzWnlJNklrVlRNalUySW4wLmV5SnBjM01pT2lKa2FXUTZhbmRyT21WNVNuSmtTR3RwVDJsS1JsRjVTWE5KYlU1NVpHbEpOa2xzUVhSTmFsVXlTV2wzYVdFeWJHdEphbTlwVFRGc1QxcEViRWRpYm1jMVUyMTROVlZHV2xwa01tUllVbXRWZWs0d1ZYcFNNMlJLVFVkV1NHSkZUa3hQU0dSSFlrWmtORkl5V25kVVUwbHpTVzVuYVU5cFNrZGlNMXBhVFdwR1RWRlZSbEJXUjNodVRGY3dkRlJ0Vmt4V01taGhVbFYzTVZsVldubGliRWwzWkZkT1MyRnJVVEZXUlhSM1VqTldia2xwZDJsbFUwazJTV3RPZVZKcmNHMVNNVkpyVlVSSk5WTnJjR3BaTTBKU1YwaFdOVlJWT0hwaU1tZ3daVzVLVldOV1FqWlJiRUpEVTFaU1dtRnFRblphTUVWcFpsRWlMQ0p6ZFdJaU9pSmthV1E2YW5kck9tVjVTbkprU0d0cFQybEtVRk14UVdsTVEwcHFZMjVaYVU5cFNrWmFSRWt4VGxSRk5VbHBkMmxoTW14clNXcHZhVlJJUmxKaU1XYzFVMFJKTWsxR1ZrVlhWa3BTVmxNeGFFOUhPVzFWVmxweFpERldORkl5Ums5VU1ITXhWVzVXYzJGWVZsVlRlVEZTWW5sSmMwbHVaMmxQYVVwd1RUQk5kR0ZHT1hSYWVsRXlXVE5hTlZsVldteGFWMDVhVld0U2VWVnJTbWxhTVZwM1dsaGFhVk16U214a2JXeHlWRE5DZDJGVVVUQkpiakFpTENKMll5STZleUpBWTI5dWRHVjRkQ0k2V3lKb2RIUndjem92TDNkM2R5NTNNeTV2Y21jdk1qQXhPQzlqY21Wa1pXNTBhV0ZzY3k5Mk1TSXNJbWgwZEhCek9pOHZkM2QzTG5jekxtOXlaeTh5TURFNEwyTnlaV1JsYm5ScFlXeHpMMlY0WVcxd2JHVnpMM1l4SWwwc0ltbGtJam9pZFhKdU9uVjFhV1E2TkRNMU1qUmlZbVF0WWpRM09TMDBNMlJrTFdJNU5UY3RZV1EzWVRobE1USTFNamN4SWl3aWRIbHdaU0k2V3lKV1pYSnBabWxoWW14bFEzSmxaR1Z1ZEdsaGJDSXNJbFZ1YVhabGNuTnBkSGxFWldkeVpXVWlYU3dpYVhOemRXVnlJanA3SW1sa0lqb2laR2xrT21wM2F6cGxlVXB5WkVocmFVOXBTa1pSZVVselNXMU9lV1JwU1RaSmJFRjBUV3BWTWtscGQybGhNbXhyU1dwdmFVMHhiRTlhUkd4SFltNW5OVk50ZURWVlJscGFaREprV0ZKclZYcE9NRlY2VWpOa1NrMUhWa2hpUlU1TVQwaGtSMkpHWkRSU01scDNWRk5KYzBsdVoybFBhVXBIWWpOYVdrMXFSazFSVlVaUVZrZDRia3hYTUhSVWJWWk1WakpvWVZKVmR6RlpWVnA1WW14SmQyUlhUa3RoYTFFeFZrVjBkMUl6Vm01SmFYZHBaVk5KTmtsclRubFNhM0J0VWpGU2ExVkVTVFZUYTNCcVdUTkNVbGRJVmpWVVZUaDZZakpvTUdWdVNsVmpWa0kyVVd4Q1ExTldVbHBoYWtKMldqQkZhV1pSSW4wc0ltbHpjM1ZoYm1ObFJHRjBaU0k2SWpJd01qVXRNRFV0TVRKVU1EYzZNVE02TlRFdU9UYzNNek13T0RjeldpSXNJbU55WldSbGJuUnBZV3hUZFdKcVpXTjBJanA3SW1sa0lqb2laR2xrT21wM2F6cGxlVXB5WkVocmFVOXBTbEJUTVVGcFRFTkthbU51V1dsUGFVcEdXa1JKTVU1VVJUVkphWGRwWVRKc2EwbHFiMmxVU0VaU1lqRm5OVk5FU1RKTlJsWkZWMVpLVWxaVE1XaFBSemx0VlZaYWNXUXhWalJTTWtaUFZEQnpNVlZ1Vm5OaFdGWlZVM2t4VW1KNVNYTkpibWRwVDJsS2NFMHdUWFJoUmpsMFducFJNbGt6V2pWWlZWcHNXbGRPV2xWclVubFZhMHBwV2pGYWQxcFlXbWxUTTBwc1pHMXNjbFF6UW5kaFZGRXdTVzR3SWl3aVpHVm5jbVZsSWpwN0luUjVjR1VpT2lKQ1lXTm9aV3h2Y2tSbFozSmxaU0lzSW01aGJXVWlPaUpDWVdOb1pXeHZjaUJ2WmlCVFkybGxibU5sSUdGdVpDQkJjblJ6SW4xOWZTd2lhblJwSWpvaWRYSnVPblYxYVdRNk5ETTFNalJpWW1RdFlqUTNPUzAwTTJSa0xXSTVOVGN0WVdRM1lUaGxNVEkxTWpjeElpd2lhV0YwSWpveE56UTNNRE0wTURNeExDSnVZbVlpT2pFM05EY3dNelF3TXpGOS44eUl0UklvUVRUMm04X0RtVVpCQmNOaURLdHhEU3laaDlWak9UTHVxRmw5bDJlS0ZRMlZZQm5acWNJaU1HRG1hcGJaYWp4ZjM1NURsRjgtdUZ1dHhPdyJdfX0.orHu3ZkOQ1YAU0LuOhThByfZh2ZvvkieePfwlpPuwjOxL4g-EVX6AqT8RBbSpWwIRymnlf397fE7uPNk8DUTAQ",
    "presentation_submission": {
      "id": "HbIdo1BMxEwf",
      "definition_id": "HbIdo1BMxEwf",
      "descriptor_map": [
        {
          "id": "UniversityDegree",
          "format": "jwt_vp",
          "path": "$",
          "path_nested": {
            "id": "UniversityDegree",
            "format": "jwt_vc_json",
            "path": "$.verifiableCredential[0]",
            "customParameters": {}
          }
        }
      ]
    },
    "state": "X31C7TERsFzR",
    "customParameters": {}
  },
  "verificationResult": true,
  "policyResults": {
    "results": [
      {
        "credential": "VerifiablePresentation",
        "policyResults": [
          {
            "policy": "signature",
            "description": "Checks a JWT credential by verifying its cryptographic signature using the key referenced by the DID in `iss`.",
            "is_success": true,
            "result": {
              "sub": "did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5Iiwia2lkIjoiTHFRb1g5SDI2MFVEWVJRVS1hOG9mUVZqd1V4R2FOT0s1UnVsaXVUSy1RbyIsIngiOiJpM0MtaF9tZzQ2Y3Z5YUZlZWNZUkRyUkJiZ1ZwZXZiS3JldmlrT3BwaTQ0In0",
              "nbf": 1747034000,
              "iat": 1747034060,
              "jti": "HbIdo1BMxEwf",
              "iss": "did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5Iiwia2lkIjoiTHFRb1g5SDI2MFVEWVJRVS1hOG9mUVZqd1V4R2FOT0s1UnVsaXVUSy1RbyIsIngiOiJpM0MtaF9tZzQ2Y3Z5YUZlZWNZUkRyUkJiZ1ZwZXZiS3JldmlrT3BwaTQ0In0",
              "nonce": "6e6b7e3c-e7fd-4136-ab25-b952abb45fc5",
              "aud": "https://verifier.demo.walt.id/openid4vc/verify",
              "vp": {
                "@context": [
                  "https://www.w3.org/2018/credentials/v1"
                ],
                "type": [
                  "VerifiablePresentation"
                ],
                "id": "HbIdo1BMxEwf",
                "holder": "did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5Iiwia2lkIjoiTHFRb1g5SDI2MFVEWVJRVS1hOG9mUVZqd1V4R2FOT0s1UnVsaXVUSy1RbyIsIngiOiJpM0MtaF9tZzQ2Y3Z5YUZlZWNZUkRyUkJiZ1ZwZXZiS3JldmlrT3BwaTQ0In0",
                "verifiableCredential": [
                  "eyJraWQiOiJkaWQ6andrOmV5SnJkSGtpT2lKRlF5SXNJbU55ZGlJNklsQXRNalUySWl3aWEybGtJam9pTTFsT1pEbEdibmc1U214NVVGWlpkMmRYUmtVek4wVXpSM2RKTUdWSGJFTkxPSGRHYkZkNFIyWndUU0lzSW5naU9pSkdiM1paTWpGTVFVRlBWR3huTFcwdFRtVkxWMmhhUlV3MVlVWnlibEl3ZFdOS2FrUTFWRXR3UjNWbklpd2llU0k2SWtOeVJrcG1SMVJrVURJNVNrcGpZM0JSV0hWNVRVOHpiMmgwZW5KVWNWQjZRbEJDU1ZSWmFqQnZaMEVpZlEjM1lOZDlGbng5Smx5UFZZd2dXRkUzN0UzR3dJMGVHbENLOHdGbFd4R2ZwTSIsInR5cCI6IkpXVCIsImFsZyI6IkVTMjU2In0.eyJpc3MiOiJkaWQ6andrOmV5SnJkSGtpT2lKRlF5SXNJbU55ZGlJNklsQXRNalUySWl3aWEybGtJam9pTTFsT1pEbEdibmc1U214NVVGWlpkMmRYUmtVek4wVXpSM2RKTUdWSGJFTkxPSGRHYkZkNFIyWndUU0lzSW5naU9pSkdiM1paTWpGTVFVRlBWR3huTFcwdFRtVkxWMmhhUlV3MVlVWnlibEl3ZFdOS2FrUTFWRXR3UjNWbklpd2llU0k2SWtOeVJrcG1SMVJrVURJNVNrcGpZM0JSV0hWNVRVOHpiMmgwZW5KVWNWQjZRbEJDU1ZSWmFqQnZaMEVpZlEiLCJzdWIiOiJkaWQ6andrOmV5SnJkSGtpT2lKUFMxQWlMQ0pqY25ZaU9pSkZaREkxTlRFNUlpd2lhMmxrSWpvaVRIRlJiMWc1U0RJMk1GVkVXVkpSVlMxaE9HOW1VVlpxZDFWNFIyRk9UMHMxVW5Wc2FYVlVTeTFSYnlJc0luZ2lPaUpwTTBNdGFGOXRaelEyWTNaNVlVWmxaV05aVWtSeVVrSmlaMVp3WlhaaVMzSmxkbWxyVDNCd2FUUTBJbjAiLCJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sImlkIjoidXJuOnV1aWQ6NDM1MjRiYmQtYjQ3OS00M2RkLWI5NTctYWQ3YThlMTI1MjcxIiwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCIsIlVuaXZlcnNpdHlEZWdyZWUiXSwiaXNzdWVyIjp7ImlkIjoiZGlkOmp3azpleUpyZEhraU9pSkZReUlzSW1OeWRpSTZJbEF0TWpVMklpd2lhMmxrSWpvaU0xbE9aRGxHYm5nNVNteDVVRlpaZDJkWFJrVXpOMFV6UjNkSk1HVkhiRU5MT0hkR2JGZDRSMlp3VFNJc0luZ2lPaUpHYjNaWk1qRk1RVUZQVkd4bkxXMHRUbVZMVjJoYVJVdzFZVVp5YmxJd2RXTktha1ExVkV0d1IzVm5JaXdpZVNJNklrTnlSa3BtUjFSa1VESTVTa3BqWTNCUldIVjVUVTh6YjJoMGVuSlVjVkI2UWxCQ1NWUlphakJ2WjBFaWZRIn0sImlzc3VhbmNlRGF0ZSI6IjIwMjUtMDUtMTJUMDc6MTM6NTEuOTc3MzMwODczWiIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmp3azpleUpyZEhraU9pSlBTMUFpTENKamNuWWlPaUpGWkRJMU5URTVJaXdpYTJsa0lqb2lUSEZSYjFnNVNESTJNRlZFV1ZKUlZTMWhPRzltVVZacWQxVjRSMkZPVDBzMVVuVnNhWFZVU3kxUmJ5SXNJbmdpT2lKcE0wTXRhRjl0WnpRMlkzWjVZVVpsWldOWlVrUnlVa0ppWjFad1pYWmlTM0psZG1sclQzQndhVFEwSW4wIiwiZGVncmVlIjp7InR5cGUiOiJCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn19fSwianRpIjoidXJuOnV1aWQ6NDM1MjRiYmQtYjQ3OS00M2RkLWI5NTctYWQ3YThlMTI1MjcxIiwiaWF0IjoxNzQ3MDM0MDMxLCJuYmYiOjE3NDcwMzQwMzF9.8yItRIoQTT2m8_DmUZBBcNiDKtxDSyZh9VjOTLuqFl9l2eKFQ2VYBnZqcIiMGDmapbZajxf355DlF8-uFutxOw"
                ]
              }
            }
          }
        ]
      },
      {
        "credential": "UniversityDegree",
        "policyResults": [
          {
            "policy": "signature",
            "description": "Checks a JWT credential by verifying its cryptographic signature using the key referenced by the DID in `iss`.",
            "is_success": true,
            "result": {
              "iss": "did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2Iiwia2lkIjoiM1lOZDlGbng5Smx5UFZZd2dXRkUzN0UzR3dJMGVHbENLOHdGbFd4R2ZwTSIsIngiOiJGb3ZZMjFMQUFPVGxnLW0tTmVLV2haRUw1YUZyblIwdWNKakQ1VEtwR3VnIiwieSI6IkNyRkpmR1RkUDI5SkpjY3BRWHV5TU8zb2h0enJUcVB6QlBCSVRZajBvZ0EifQ",
              "sub": "did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5Iiwia2lkIjoiTHFRb1g5SDI2MFVEWVJRVS1hOG9mUVZqd1V4R2FOT0s1UnVsaXVUSy1RbyIsIngiOiJpM0MtaF9tZzQ2Y3Z5YUZlZWNZUkRyUkJiZ1ZwZXZiS3JldmlrT3BwaTQ0In0",
              "vc": {
                "@context": [
                  "https://www.w3.org/2018/credentials/v1",
                  "https://www.w3.org/2018/credentials/examples/v1"
                ],
                "id": "urn:uuid:43524bbd-b479-43dd-b957-ad7a8e125271",
                "type": [
                  "VerifiableCredential",
                  "UniversityDegree"
                ],
                "issuer": {
                  "id": "did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2Iiwia2lkIjoiM1lOZDlGbng5Smx5UFZZd2dXRkUzN0UzR3dJMGVHbENLOHdGbFd4R2ZwTSIsIngiOiJGb3ZZMjFMQUFPVGxnLW0tTmVLV2haRUw1YUZyblIwdWNKakQ1VEtwR3VnIiwieSI6IkNyRkpmR1RkUDI5SkpjY3BRWHV5TU8zb2h0enJUcVB6QlBCSVRZajBvZ0EifQ"
                },
                "issuanceDate": "2025-05-12T07:13:51.977330873Z",
                "credentialSubject": {
                  "id": "did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5Iiwia2lkIjoiTHFRb1g5SDI2MFVEWVJRVS1hOG9mUVZqd1V4R2FOT0s1UnVsaXVUSy1RbyIsIngiOiJpM0MtaF9tZzQ2Y3Z5YUZlZWNZUkRyUkJiZ1ZwZXZiS3JldmlrT3BwaTQ0In0",
                  "degree": {
                    "type": "BachelorDegree",
                    "name": "Bachelor of Science and Arts"
                  }
                }
              },
              "jti": "urn:uuid:43524bbd-b479-43dd-b957-ad7a8e125271",
              "iat": 1747034031,
              "nbf": 1747034031
            }
          }
        ]
      }
    ],
    "time": "PT0.013413451S",
    "policiesRun": 2
  },
  "customParameters": {}
}

The verificationResult field will be true if all policies were successful, otherwise it will be false.

The response includes the following key fields:

  • verificationResult - true if all policies were successful, otherwise false.
  • policyResults - container with the results of the policies applied to each credential.
  • credential - name of the credential that a given set of policy results refers to.
  • policies - collection of individual policy evaluation results for the credential.
  • policy - name of an individual policy.
  • is_success - boolean result of the policy.

Inspecting Presented Credentials

After a successful presentation session (verificationResult is true), you can now get a decoded and formatted view of all credentials presented by the holder.

You may choose between the following view modes:

  • simple - the go-to choice for most cases.
  • verbose - useful for debugging, auditing and other detailed technical information.

Endpoint: /openid4vc/session/{id}/presented-credentials | API Reference

Request

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

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:
    • For jwt_vc_json in simple view mode:
      • holder - Corresponds to the (optional) holder property of W3C verifiable presentations.
      • verifiableCredentials - Array of decoded JOSE-secured credentials that were included in the verifiable presentation for each of which the JWT header and payload JSON objects are provided.
    • For jwt_vc_json in verbose view mode:
      • vp - JSON object that provides verbosely decoded JOSE-secured verifiable presentation and is composed of the following properties:
        • raw - The compact serialized verifiable presentation JWT.
        • 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.
      • verifiableCredentials - Array of verbose decoded JOSE-secured credentials that were included in the verifiable presentation. Each entry in the array is a JSON object that is composed of the following properties:
        • raw - The compact serialized verifiable credential JWT.
        • header - The JWT header section of the verifiable credential provided as a JSON object.
        • fullPayload - The JWT payload section of the verifiable credential provided as a JSON object with all disclosures (if provided) substituted.
        • undisclosedPayload - The JWT payload section of the verifiable credential 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.

University Degree Without Any Disclosable Claims

In the following we provide an example that involves the presentation of a University Degree W3C Verifiable Credential without any disclosable claims.

Simple
Verbose

Example Request

curl -X 'GET' \
  'http://0.0.0.0:7003/openid4vc/session/{id}/presented-credentials' \
  -H 'accept: application/json'

Example Response

{
  "credentialsByFormat": {
    "jwt_vc_json": [
      {
        "type": "jwt_vc_json_view_simple",
        "holder": "did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2Iiwia2lkIjoiZXY2a3BuS0l6akRLRTFZcXRONDJIMk9VMmxVZWVKamVpVmh4VEpRdVVJYyIsIngiOiJCdmt3bzh0Y0hLN3RsTy1lWUNZRjZLakNxTXNMeHdoTVJOQ3VtX0tJZUk4IiwieSI6IkQ3czc0WV9wdXVGdXJWNlJtWUtHRUpaTzlWdU1ycy1OdlNGeHdMd01SVVUifQ",
        "verifiableCredentials": [
          {
            "header": {
              "kid": "did:key:zDnaeqgdw7qN5J8qZbwo8PCu18he2bK7PSHfaQEhmTw4xrDCC#zDnaeqgdw7qN5J8qZbwo8PCu18he2bK7PSHfaQEhmTw4xrDCC",
              "typ": "JWT",
              "alg": "ES256"
            },
            "payload": {
              "iss": "did:key:zDnaeqgdw7qN5J8qZbwo8PCu18he2bK7PSHfaQEhmTw4xrDCC",
              "sub": "did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2Iiwia2lkIjoiZXY2a3BuS0l6akRLRTFZcXRONDJIMk9VMmxVZWVKamVpVmh4VEpRdVVJYyIsIngiOiJCdmt3bzh0Y0hLN3RsTy1lWUNZRjZLakNxTXNMeHdoTVJOQ3VtX0tJZUk4IiwieSI6IkQ3czc0WV9wdXVGdXJWNlJtWUtHRUpaTzlWdU1ycy1OdlNGeHdMd01SVVUifQ",
              "vc": {
                "@context": [
                  "https://www.w3.org/2018/credentials/v1",
                  "https://www.w3.org/2018/credentials/examples/v1"
                ],
                "id": "urn:uuid:ca31b7d7-2db6-458e-b776-c6213ee82190",
                "type": [
                  "VerifiableCredential",
                  "UniversityDegree"
                ],
                "issuer": {
                  "id": "did:key:zDnaeqgdw7qN5J8qZbwo8PCu18he2bK7PSHfaQEhmTw4xrDCC"
                },
                "issuanceDate": "2025-07-16T06:38:06.202581908Z",
                "credentialSubject": {
                  "id": "did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2Iiwia2lkIjoiZXY2a3BuS0l6akRLRTFZcXRONDJIMk9VMmxVZWVKamVpVmh4VEpRdVVJYyIsIngiOiJCdmt3bzh0Y0hLN3RsTy1lWUNZRjZLakNxTXNMeHdoTVJOQ3VtX0tJZUk4IiwieSI6IkQ3czc0WV9wdXVGdXJWNlJtWUtHRUpaTzlWdU1ycy1OdlNGeHdMd01SVVUifQ",
                  "degree": {
                    "type": "BachelorDegree",
                    "name": "Bachelor of Science and Arts"
                  }
                },
                "issuerDid": "did:key:zDnaeqgdw7qN5J8qZbwo8PCu18he2bK7PSHfaQEhmTw4xrDCC",
                "expirationDate": "2026-07-16T06:38:06.202607447Z"
              },
              "jti": "urn:uuid:ca31b7d7-2db6-458e-b776-c6213ee82190",
              "exp": 1784183886,
              "iat": 1752647886,
              "nbf": 1752647886
            }
          }
        ]
      }
    ]
  },
  "viewMode": "simple"
}

University Degree With Two Disclosable Claims

In the following we provide an example that involves the presentation of a University Degree W3C Verifiable Credential with two disclosable claims, namely, the issuanceDate and credentialSubject.degree.name properties.

Simple
Verbose

Example Request

curl -X 'GET' \
  'http://0.0.0.0:7003/openid4vc/session/{id}/presented-credentials' \
  -H 'accept: application/json'

Example Response

{
  "credentialsByFormat": {
    "jwt_vc_json": [
      {
        "type": "jwt_vc_json_view_simple",
        "holder": "did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2Iiwia2lkIjoiVkp6Qlc2bXVVMV8ydGFzcDdSTFh6N2tod0xWb3E2NTBtU0pWNGxtVzJmTSIsIngiOiI0bUx6N2RyMkxpT0JvaHEyaTI0Wk9qLWVUVWlCdC0xdEVtSm9mbFBBdzNrIiwieSI6Il9mS0JNc05WTnJ4ZUw0M1V1dVR0NVFMaUYwcUlvSEFUSkt0d1dyYXBhYlkifQ",
        "verifiableCredentials": [
          {
            "header": {
              "kid": "did:key:zDnaeqPNFZ4YdURZczMiLp5cNpP3SurXZA5b8w461xRw19shB#zDnaeqPNFZ4YdURZczMiLp5cNpP3SurXZA5b8w461xRw19shB",
              "typ": "JWT",
              "alg": "ES256"
            },
            "payload": {
              "iss": "did:key:zDnaeqPNFZ4YdURZczMiLp5cNpP3SurXZA5b8w461xRw19shB",
              "sub": "did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2Iiwia2lkIjoiVkp6Qlc2bXVVMV8ydGFzcDdSTFh6N2tod0xWb3E2NTBtU0pWNGxtVzJmTSIsIngiOiI0bUx6N2RyMkxpT0JvaHEyaTI0Wk9qLWVUVWlCdC0xdEVtSm9mbFBBdzNrIiwieSI6Il9mS0JNc05WTnJ4ZUw0M1V1dVR0NVFMaUYwcUlvSEFUSkt0d1dyYXBhYlkifQ",
              "vc": {
                "@context": [
                  "https://www.w3.org/2018/credentials/v1",
                  "https://www.w3.org/2018/credentials/examples/v1"
                ],
                "id": "urn:uuid:1d037cf4-8489-4bb8-8c20-8f2e2d13292d",
                "type": [
                  "VerifiableCredential",
                  "UniversityDegree"
                ],
                "issuer": {
                  "id": "did:key:zDnaeqPNFZ4YdURZczMiLp5cNpP3SurXZA5b8w461xRw19shB"
                },
                "credentialSubject": {
                  "id": "did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2Iiwia2lkIjoiVkp6Qlc2bXVVMV8ydGFzcDdSTFh6N2tod0xWb3E2NTBtU0pWNGxtVzJmTSIsIngiOiI0bUx6N2RyMkxpT0JvaHEyaTI0Wk9qLWVUVWlCdC0xdEVtSm9mbFBBdzNrIiwieSI6Il9mS0JNc05WTnJ4ZUw0M1V1dVR0NVFMaUYwcUlvSEFUSkt0d1dyYXBhYlkifQ",
                  "degree": {
                    "type": "BachelorDegree",
                    "name": "Bachelor of Science and Arts"
                  }
                },
                "issuerDid": "did:key:zDnaeqPNFZ4YdURZczMiLp5cNpP3SurXZA5b8w461xRw19shB",
                "expirationDate": "2026-07-16T06:52:03.063864637Z",
                "issuanceDate": "2025-07-16T06:52:03.063843966Z"
              },
              "jti": "urn:uuid:1d037cf4-8489-4bb8-8c20-8f2e2d13292d",
              "exp": 1784184723,
              "iat": 1752648723,
              "nbf": 1752648723
            }
          }
        ]
      }
    ]
  },
  "viewMode": "simple"
}
Last updated on November 18, 2025