VP Creation and Verification¶
Did-endpoint performs the verifier function for verifying VP (Verifiable Presentation) created and submitted by the holder. Hereinafter, did-endpoint is called verifier.
The VP (Verifiable Presentation) verification is a function to submit and verify the VP generated by the holder to the verifier.
When a holder applies for a job at a company or wants to receive a rental car discount, the verifier may request the holder for a graduation certificate/resident registration card or driver’s license/discount voucher. In this case, the holder does not submit the VC (ex. graduation certificate, driver’s license, etc.) to the verifier (ex. company or rental car company) as it is. The holder extracts only the necessary properties from among the VC properties based on the content requested by the verifier to create the VP, and then add holder’s signature within VP and submit the created VP.
VP Elements¶
VP consists of the following elements: - Presentation metadata: Definition of data that can be referenced for VP verification, such as specifying the type of VP, terms of use, evidence, etc. - Verifiable Credential(s): VC is included. The VC can be put in as it is, or only claims with attributes required by the verifer can be selected and included among claims existing within the VC. - Proof(s): The value required to verify the authenticity of the VP is included. Various cryptographic techniques for verification, such as RSA and biometrics, can be used.
VP Procedures¶
VP procedures are as follows.
For example, the holder wants to apply for a job application by accessing a recruitment company (hereinafter, a verifier) homepage. In this case, the holder should be informed of the VP requirements (eg, required documents for job application) from the verifier.
Credential Schema Acquirement¶
To do this, the holder has to obtain the credential schema information required for VP creation from the verifier in order to create VP (Recruitment Application Document), and collect the data required for VP creation request from the block chain. This process requires the holder to know the verifier’s information and proceed online or offline. (Example: visiting the company’s online site for job application, etc.) In this project, it is assumed that the holder and the verifier are connected online.
The verifier registers the VP’s credential schema in the block chain through the DID Platform in advance. (Post Schema)
To inquire credential schema information (stored in the block chain) required for VP creation, the holder requests credential schema’s location information from the verifier before requesting a VP creation. The verifier sends the credential schema location information and the URL information of the service endpoint (Verifier) to send the created VP together to the holder.
The holder sends the received credential schema location information to the DID Platform, and the DID Platform inquires the credential schema on the block chain through the location information and sends the credential schema to the holder.
The holder creates VP based on the received credential schema information. In this project, VP is created by integrating multiple VCs owned by the holder’s App. And the holder sends the created VP to the verifier.
DID Document Retrieval¶
In order to prove the ownership of the DID of the holder of the VP and the issuer of the VC included in the VP, the verifier needs the operation of inquiring the DID Document of the holder’s DID and the VC issuer’s DID from the block chain.
The verifier requests the DID Document inquiry from the DID Platform through the VP’s holder DID and the VC issuer’s DID included in the VP. The DID Platform checks the location where the holder and issuer’s DID Document are stored, obtains the DID Document from the block chain, and sends it to the verifier.
VC Verification¶
The verifier needs an operation to verify the signature on the VC issued by the issuer with the public key included in the issuer’s DID document. This is to verify that the issuer is the issuer who issued the VC and whether the VC has not been forged and verified based on the issuer’s signature (Proof) included in the VC.
In addition, the verifier also checks the expiration date included in the VC. If the expiration date has passed, the verifier sends the VC verification result fail (expiration of validity period) to the holder and ends the VP verification procedure.
VP Verification¶
After that, the verifier verifies the signature of the VP received from the holder with the public key included in the DID Document of the holder. The VP is verified based on the holder’s signature (Proof) included in the VP.
DID Authentication¶
If the issuer’s VC and the holder’s VP signature verification are completed (successful), the verifier performs the DID Authentication procedure to verify that the VP’s DID owner is the holder.
The verifier sends a challenge (eg, generating a random payload) to authenticate that the DID is a DID generated by the holder, and sends a token (JWT) together in the header. JWT consists of public key, challenge, and UUID. The holder sends a response (eg, encrypting a random payload with a private key) for authentication. The verifier that has received the response verifies the holder’s response by acquiring the public key included in the holder’s DID Document. When the verification is completed, the verifier sends the DID Authentication result (true/false) to the holder.