Requesting Verifiable Presentations
The credential verification process involves the customer application, Partisia's Credential Verification Service (CVS), and the holder's wallet, each with a specific role in enabling credential verification.
The CVS handles the specifics of verifying a credential presentation. Your application remain responsible for managing the process of requesting a verifiable presentation from the holder, and forwarding it to the CVS.
This section describes the communication flows and configuration requirements for initiating the verifiable presentation submission as well as the reception of the verification results from the CVS.
1. Start interaction
The process begins when the holder interacts with your application, usually by opening a website or a mobile app. The application recognizes the holder's input and responds, initiating the engagement.
2. Application starts verification
Your application initiates the presentation process by sending an API POST request to the CVS.
To create a new request you must provide the ID of a presentation definition
as an input. If no presentation definition is specified,
the CVS will return a Bad Request
response.
This initial request signals the CVS to prepare for the interaction but does not include any personal information about the holder. For example:
Example
curl -X 'POST' \
'URL_to_your_CVS/presentation/oid4vp/new-request' \
-H 'accept: application/json' \
Once the CVS receives the POST request, it creates a new verification request.
The returned request_id
is later used by the wallet to interact with the correct verification request.
3. CVS returns verification session info
Once the presentation session is set up, the CVS responds to the initial POST request with a Request URI. This response from the CVS also includes the request ID. For example:
{
"request_id": "029f3095d16a55ea59ef2ae18e9d2233d6be825838",
"request_uri": "http://localhost:8081/presentation/oid4vp/authorization-request/029f3095d16a55ea59ef2ae18e9d2233d6be825838"
}
4. Application forwards request URI to wallet
After receiving a response from the CVS, your application must forward the request URI to the holder's wallet. This can be achieved through various methods, such as generating a QR code for the user to scan with their wallet, or sending the URI via email or another communication channel.
The customer application is responsible for ensuring the URI is shared in a format supported by the wallet. Misalignment here—such as using a communication method the wallet does not recognize—can disrupt the presentation flow.
5. Verification Black Box
The following steps are carried out by Partisia's CVS, which carry out the rest of the OID4VP protocol. If you have configured your application correctly, the results will be pushed to the correct endpoint in your application (see next point).
In short, the CVS receives the verifiable presentation from the holder's wallet and verifies the wallet's signature of the presentation and the issuer's signature of the credential. See a detailed explanation of the verification flow here.
6. CVS pushes results to application
Once the presentation is validated, the CVS sends the verification result and verified claims to the application via a POST request to a pre-configured endpoint.
The customer application must ensure its application endpoint is correctly configured and that the CVS is configured to send the data to that endpoint. If the endpoint is missing or misconfigured, the result cannot be delivered. Upon receiving the data, the customer application can process the information as needed.
Here's an example a POST request sent by the CVS:
curl -X 'POST' \
'http://localhost:8090/presentation/verification-result' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer 5I90CwXlZoolopOSplVBOoV63qXSTEo4piJKJ0iizFau79HU6viEvzgGReWycN8V' \
-d '{
"request_id": "02d623f4d4bab3bdb01eb36b5222a65125db9458af",
"verificationResult": true,
"claims": [
{
"id": "studentId",
"name": "Student ID",
"value": 200014762
}
]
}'