The standard process of getting a mobile sim card in India is visiting a telecom operator store which will perform Aadhar e-KYC i.e. taking the customer’s biometric data and sending it to the UIDAI to get the customer details. Once the customer is verified the sim card is issued. I am using SSI technology to reimagine the situation. The customer data will be verified without calling the Issuer i.e UIDAI.
NOTE: Use docker version V2. I am using Docker Compose version v2.12.2. The network fails when run with docker-compose version 1.25.5.
Create .env file from .env-sample in each of the issuer, holder and verifer folder. And run the following command from the root directory of this repo.
NOTE: The below command will build the docker images and create the network this will take more than 7 minutes. The indy-sdk libraries such as libzmq3-dev, libsodium-dev, pkg-config, libssl-dev, libindy etc that is the reason for selecting ubuntu 18 as the base image instead of light weight image such as "node:16.13-slim".
docker compose up -d --build
It will create a network with three servers. You check the logs of each of the server by:
docker logs issuer -f
docker logs holder -f
docker logs issuer -f
- Docker
- Docker Compose V2
NOTE: Internet connection is a must because application interacts with online BCovrin Test Indy network and online mediator provided by Animo.
- Use the all three agents in the project.
- Use your mobile digital wallet as a holder (USE BC WALLET by British Columbia, the app is available in Play Store) to perform the interaction. All three agents use online mediator which makes it possible to communicate outside the local system.
Postman collections are added in the docs folder. This need to be imported and used to communicate with the agents. I have used the following global variable, please set these global variables for the project.
- "issuerbase" and it's value is "localhost:3000"
- "holderbase" and it's value is "localhost:5000"
- "verifierbase" and it's value is "localhost:4000"
- "version1" and its' value is "api/v1"
I am going to decribe the flow of
-
Agent Setup.
-
Connection Establishment.
-
Issuance.
a. Credential offer. b. Acceptiong credential offer. c. Receiving credential. -
Verification
a. Proof request b. Acceptance of proof request c. Verification of proof d. Issuance of phone number in form of credential (TODO)
These numbering are seperate from the above project flow.
8000 At the start each of the agent are intialized and are connected to ledger and mediator.
To check if a particular agent is connected to the mediator call the "get all connections" API under the folder collection "connections" that is under each respective agent folder name in the Postman collection.
The request was sent to issuer agent and it says the connection status is completed with Animo Mediator.
At the start, the issuer agent writes the necessary crypto material into the ledger i.e. schema and credential definition. The below screenshot display the query request. If schema Id or Credential Def Id is not passed as a value in the respected API calls then initally registered schema Id or Credential Def Id is picked and queried from the ledger and sent as a response to the API call.
When the agent is setup it created OOB invitation and displays QR code.
If you lost it you can query the agent which you want to get connected with. The agent send the invitation url as json response and aslo displays the qrcode in the logs of the container.
The agent which wants to establish connection can scan the QR code or call the '/api/v1//out-of-band/receive-invitation' API by passing the invitation url to get connected. The
The issuer agent listner listens to the connection request by OOB record once the connection is established it send a message to the agent and the connection ID of the holder is stored and exported for other services to use.
The issuer agent can send the credential offer when called at '/api/v1/issue-credential/send' API with the attributes of credential.
The holder agent has setup a listner and it listen to the credential offers it recieves and the holder agent in this code is configured to auto accept the credential offer, holder agent accepts the offer and the issuer agent send the credential
The holder agent can be called at 'api/v1/credential/all' to get all credential issued to the holder.
As mentioned in the step 2, first the verifer and the holder will establish connection.
The verifer agent can send proof request by calling 'api/v1/present-proof/request' API and in the request body it mentions the credentialDefinitionId. You can get the credentialDefinitionId by querying issuer agent as shown in the last screenshot of Agent Setup.
Both the verifer and the holder will setup a listner to handle proof request and the proof record. Both agents are configured to autoaccept the proofs.
Once the verifier agent recieve the proof record from the holder then the verifer agent will query the ledger to get credential defination and verify the proof record using the credential defination.
Once the verification is finished this verifer agents send the message that "Your credential is verified"