Build a PoC with Affinidi in One Evening — Driving License as a Verifiable Credential
In this article, let's look at the practical implementation of the Driver’s License use case. This article explains how you can build a Proof of Concept VC based application in one evening ⏰ 😱
You may choose to create your own custom implementation, in which case you can create a react app and create your custom UI. In this tutorial, we will be leveraging a demo implementation that’s open source. By the end of this article, you will have issued your first VC, store it in a wallet, and have it verified.
STEP 1: Clone / Fork repos
Clone or fork the open source repos for the issuer, holder, and the verifier apps on your machine. These are react apps that use Affinidi’s APIs and SDK to do VC creation, VC issuance, VC storage, and verification.
STEP 2: Environment setup
Moving on, get the API key (used for SDK interaction)and API key hash (used for making API calls) from https://apikey.affinidi.com/?source=vcms-api-sandbox and add in .env file with these keys in all 3 apps. Set REACT_APP_ENVIRONMENT as prod
// .env file REACT_APP_API_KEY= REACT_APP_API_KEY_HASH= REACT_APP_ENVIRONMENT=
The issuer react app issues a credential which can be claimed by a holder via email. Which means an email needs to be triggered by the issuer app. Follow instructions in the readme here to setup Amazon SES for email. You can alternatively use a different email setup but you’ll have to modify the corresponding code accordingly. Firebase setup on the issuer side is optional. We use firebase DB to store applicant information for the issuer. Issuer App after running.
STEP 3: Run, sign-up, and apply for a VC
Run all 3 apps using npm start as per instructions in the issuer, holder, and verifier readmes.
Now, sign up 3 users issuer holder (applicant/traveler who wants a digital driver’s license), (a startup that does a background check and issue a driver license VC), and verifier (car rental company) accounts using the holder portal. The sign up operation uses this API and login operation uses this API.
Now all 3 users — issuer, holder, and verifier — have their own DIDs.
The applicant logs in and fills the form and submits it to get a VC (Verifiable Credential) for their Driving License. Applicant’s view of the page after login
STEP 4: Issue the first VC
When the issuer logs in using “Sign in as admin”, the list of all applications will be shown (get call from firebase). The issuer now checks the applications and issues a VC for the same. Issuing the VC involves two APIs: creating an unsigned VC and signing the credential. In this case the unsigned VC is of type IDDocumentCredentialPersonV1 but you can use your any of the supported VC types available at https://vc-generator.com/
STEP 5: Share the VC with the applicant / holder
Once the VC is signed, it can be saved to the issuer’s wallet using this API. The VC is stored in the issuer wallet until the holder claims it. The VC is shared from the issuer application automatically after approval / signing. For this, the Share Credential API endpoint is used. This creates a shareable link with expiry date and QR code(it contains the shareable link URL). This link can be via email or as a QR code to the applicant.
STEP 6: Holder claims the VC
Finally, when the holders/applicants click the link, they are redirected to their respective wallet app and prompted to store or reject the VC. The holder / applicant (in this case the traveler who applied for the digital driver’s license) needs to login to their wallet first. Once the traveler accepts the request, the VC is stored to their wallet using the Store Credential endpoint.
When the holder logs in, they should now be able to see the list of all VCs stored in their wallet using the GetCredential endpoint.
STEP 7: VC Sharing — Initiate credential share request
Let’s say, the holder now wants to rent a car from a Car Rental Company (Verifier). To prove the authenticity of the holder’s VC and to avoid its misuse, the holder shares the VC with the verifier. There are a series of handshakes that happen to safely transfer the VC from the holder to the verifier as follows.
As a verifier, you need to first generate a token via a generic verifier portal for request token generation. You login with the verifiers credential (same as the one created in step 3). As a verifier, you specify the type(s) of credentials you are interested in receiving. You can optionally add a Holder DID if you wish to get VCs only from a specific holder, but we’ll leave it empty. Then you can generate a Credential share request JWT token.
The car rental company displays this credential share request token in the form of a link on their web portal (or a QR code in their shop). This JWT token has the list of encoded credentials required for the share. Our verifier app displays the share request link like so:
Credential share request token displayed by verifier
STEP 8: Holder Shares a Credential
The link in the above image redirects to the wallet application with Token Request in the query parameter. When the holder logs in using that link, they see a list of all VCs matching the criteria set while creating the Credential share request token. In this case, this account is able to see 1 VC of type IDDocumentCredentialPersonV1
The holder clicks on the Share button, thereby accepting the request to share the credential to the car rental company.
STEP 9: Credential Shared in the form of a VP
VCs are shared in the form of a Verifiable Presentation (VP). A VP is a collection of VCs and is a standard SSI way to share VCs. Also, the VCs present inside the Verifiable Presentation are not the actual VCs. This is done with the intention to avoid letting the verifier misuse the VC. At the same time, it also has the necessary information to prove the authenticity of VC as it has a Response Token (JWT token with Verifiable Presentation encoded in it).
This VP is generated by the holder like this and shared to the verifier via the encrypted messaging service API, like this.
STEP 10: Validate the shared VP and finish Verification
When the verifier logs into the account, the list of validated credentials shared can be seen by pulling them using the messaging service API like this. The verifier portal validates the Verifiable Presentation shared by the holder in the form a Credential Share Response Token, similar to this code sample. This returns a variable called isValid. If the isValid is true then the validation is successful.
The verifier portal checks for new VPs shared every 10 seconds. The verifier now knows the digital driver’s license can be trusted and the request for a car rental can now be approved.
To recap, in this tutorial we learnt:
- How to create an account with a DID for issuer, holder, and verifiers
- A starter kit to create web UI for the 3 roles in the driver license use case
- Issue your first VC and have the holder claim it
- Verification flow using Credential Share Request and Response tokens
- Validation of VP
Affinidi provides building blocks for an open and interoperable Self-Sovereign Identity ecosystem. Check out our developer portal for more information.