Skip to main content

Verify Credentials with OpenID4VP

In the realm of digital identity, verifiers, also known as Relying Parties (RP), play a crucial role in validating the authenticity of presented credentials. Utilising the OpenID for Verifiable Presentations (OpenID4VP) protocol, verifiers can request, receive, and assess verifiable credentials in a secure and standardised manner.​ This guide outlines the process for verifiers to follow:

  • Define the specific credentials or claims they require through a presentation definition.
  • Initiate a verification request to holders, often facilitated via QR codes or direct links.
  • Receive and validate the verifiable presentation returned by the holder's wallet, ensuring the data's integrity and authenticity.​

By following the steps below, verifiers can request digital credentials and verify them, fostering trust in digital interactions.

Step 1: Get the API Key​

To obtain your API key, please contact [email protected]. Once you have received your API key, enter it in the field below and click the Set API Key button to save it for future use.

Signing keys: The requests on this page sign with an x509 key of your organisation: a key with a certificate chain. After you set the API key, the page fills in such a key. If no key has a certificate, it fills in your default key with did:key, for tests only. To choose another key, click the key label next to a signing key field in a request, for example cryptographicKeyIdentifier. To create a key, attach a certificate or see your keys, follow the key management guide. To add your certificate to the NXD trust list, see trust list registration.

Step 2: Create Presentation Definition (Verifier Admin)​

To create a presentation definition for requesting proof, you can run the code block below using the Run button. Alternatively, you can manually copy the code block and use it in the body of the API request provided here.

Request

Version 01
W3C VC (JWT)

Response

Tip: Once a presentation definition is created, the presentationDefinitionId can be reused to verify multiple credentials (Step 3).

Step 3: Create Verification Request (Verifier/Relying Party)​

When you run Step 2 on this page, the presentationDefinitionId field below is autofilled automatically (and updated whenever Step 2 is re-run). If you are executing the APIs yourself, replace <presentationDefinitionId> with the ID obtained in Step 2. To create the verification request, execute the code block below using the Run button. Alternatively, you can manually copy the code block and use it in the body of the API request available here.

After receiving the response, toggle the button provided to dynamically generate a QR code. The EUDI Wallet/Holder can then answer the verification request using the Data Wallet (or any other EU Digital Identity Wallet) by either scanning the QR code or directly accessing the verification request on their mobile device, such as via a browser.

Request

Version 01
W3C VC (JWT)

Response

The presentation definition holds a Digital Credentials Query Language (DCQL) query (OpenID4VP 1.0). It signs the request with an X.509 key: cryptographicKeyFormat is x509, and the server takes x509_hash as the client ID scheme when the body has no clientIdScheme.

More DCQL examples

Start with the DCQL overview, then work through a runnable, step-by-step tutorial for your scenario:

Step 4: Send and Receive Verifiable Presentation (Holder)​

The holder wallet accepts (consents) to send the requested credentials.

Step 5: Send and Receive Verifiable Presentation (Verifier/Relying Party)​

  • The verifier (relying party) receives the requested credentials. Read them with the Read Verification History API. In the response, verified holds the result, presentation holds the disclosed claims of each credential, and presentationValidity holds the result of each check.
  • vpTokenResponse holds the raw tokens that the wallet sent. Decode an SD-JWT or a JWT token with the JWT Decoder.
Trust status of the verifier

The holder wallet checks whether the verifier can be matched against a recognised trust list. If the verifier cannot be matched, the Data Wallet shows a "Service provider not verified" warning. In your verification record, presentationValidity[].issuerTrustServiceProvider holds the trust result of each issuer: isVerified, trustServiceProvider and errors. See The "Service provider not verified" notice and Trust in the Wallet Ecosystem.

Try It Yourself (With Demo Video)​

Watch the below demo to learn verify credential API and try it out yourselves:

OpenID4VP Verification Demo: Learn how to send and verify credentials using OpenID4VP protocol with iGrant.io Digital Wallets.