attest
In the previous post, we, as Claimer, made a request to Attester to issue a VC. This time we will be responding to the previous request as Attester, so are you ready, Attesters? Let's get going.
Complete code example: zkid-sdk-example /src/claim-attest/attest.ts
Tutorial
Initialize @noble cryptographic library and wasm;
Get attester's DID object from mnemonic;
The method used to recover a DID object from a mnemonic is fromMnemonic
, which takes two mandatory arguments, a keyring object and a string mnemonic, where the keyring object is used to manage the keypair;
Get the latest message from the server with receiver is attester and message type is Request_Attestation;
The attester decrypts the encrypted message obtained from the previous step and gets the RawCredential object wrapped by the claimer;
Get the ctype object via ctypeHash in RawCredential;
Build the
vcBuilder
object. In this step, we build a vcBuilder object from which subsequent VCs can be built. vcBuilder provides several methods. For general purpose VCs, it is usually set to never expire and the issue time is set to the current time;
Build the
VC
object. In this step, you will use thebuild
API in vcBuilder to build the VC. The two parameters of this API are described below:issuer: issuer's DID object;
isPublic: true/false. When this parameter is false, the generated VC is private VC. If it is true, then public VC is generated.
If the claim request is approved, the VC is used as the message data to construct the encrypted message, and the corresponding message type is "Response_Approve_Attestation", and if the request is rejected, the "data" field is set to empty and the message type is set to "Response_Reject_Attestation". When constructing the encrypted message, we will use the
encryptMessage
interface to generate the encrypted message with the following interface parameters:type: Message type, approval to issue VC corresponds to message type "Response_Approve_Attestation";
data: Message data, here is VC;
sender: Message sender's DID object, here is Attester;
receiverUrl: Message receiver's keyAgreement DID URL;
reply: Prefixed message id, this parameter is only used for responding to message scenarios, here is decrypted message id;
resolver: DID resolver.
Send the encrypted message to the server. This process initiates an HTTP POST request.
Well, with the introduction of this tutorial, we have learned how to respond to a claimer's request from the Attester's perspective. For general VC usage scenarios, a trusted Attester will suffice, but for decentralized and high-trust scenarios, we'll need to see how multiple Attenders can work together to endorse a VC. In the next tutorial, you will learn how to make multiple endorsements to a VC.
Last updated