Skip to main content

Functional Flow

Let's describe how an end-to-end flow works to see how all the terms described above relate to each other in BLOOCK Identity.

1. Create Baby JubJub key​

In order to create an identity in BLOOCK Identity I will first need to create or have a Baby JubJub (BJJ) key. This key will be very important to have it saved because it will be used to control our Issuer.

You have two options to get this key.

  1. You can create a BJJ key with our managed key product (BLOOCK Keys product), your key will be identified by a UUID. This identifier will be enough to control your Issuer. Example: 6f36448d-49f3-4b0e-aa72-6e55863302e8
  2. If you have created a BJJ type key locally, i.e. you are aware of its private key, then you can use it to control your Issuer. Example: bf5e13dd8d9f784aee781b4de7836caa3499168514553eaa3d892911ad3c345j

2. Create the Issuer​

Once we have our key available, we will create the Issuer.
Before creating the Issuer we should think about how often we want the status of our Issuer to be transacted. Here you can see what intervals we have available. If you need information to make this decision you can contact us. For this example, let's imagine that I choose a 60-minute interval.

Once we have our Issuer we can see its identity represented with its DID (decentralized identifier). This is unique and totally public, this DID is directly related to the key you have created previously. Example: did:polygonid:polygon:main:2qCU58EJgrELSJT6EzT27Rw9DhvwamAdbMLpePztYq

3. Create the schema​

Next, we must think about what type of credentials we want to issue. For example, we want to issue a card that identifies BLOOCK employees. In order to create the schema I have to follow these steps.

  1. I must first think about the name of the schema type, in this case for example it would be BloockEmployee.
  2. I must define what attributes my credential will have, for example, I will put an employee number, name and date of birth.

Once this is defined, I will be able to create my schema. Notice that all we are doing is defining the attributes that our credentials will have.

The schemas are uploaded to IPFS, in order to identify the schemas we use their IPFS identifier. Example: QmadTvnNKvj2fBDgen35uAp1TfP9pSPVCNeDWw4fitqqne

4. Create the credential​

To create a credential, we will need four very important things.

  1. I need the schema identifier that it will reference, which will therefore mark which attribute structure it will have. In my case it will be my employee number, name and date of birth.
  2. I will need the BJJ key created for that Issuer, because when we create a credential let's remember that in order to be verifiable we need to be able to sign it and get a proof of authenticity.
  3. You should know who is going to be the Holder of this credential or rather which is the user who is going to receive this credential. This Holder must have created his own identity at the same time. For example, in the case of our employee for whom we are going to issue this credential, the following DID identifies him/her: did:polygonid:polygon:main:2q544HUegzeRpwr3V2qu9eMwgrAmF5x4E1NCPzbQc4.
  4. We will also be able to add additional metadata such as expiration date, version number, etc...

Once the credential is created we will obtain a UUID identifier. Example: 0e3199ac-8147-4c7a-938b-d33f9107dace

The most important thing is that this credential is already a Verifiable Credential (VC) because it already includes a signature proof, and therefore, this credential would already be valid to be verified.

But BLOOCK Identity's product offers a second proof, related to integrity in blockchain. The Sparse Merkle Tree proof is a proof that will be available depending on the interval time you have chosen and is related to the Issuer's state. As I have previously chosen a 60 minutes interval, it means that I will have my SMTP proof available after ~60 minutes.

5. Credential offering​

The credential offering process refers to the transfer of the Verifiable Credential (VC) to the assigned user or Holder. It requires two agents (Issuer and Holder) and a wallet or software where the credential will be stored. At the Holder level, this is done by scanning a QR code generated by the Issuer from the Holder's wallet. At the protocol level this communication is highly secure thanks to the DIDComm protocol used and the authentication and identity proofs mechanisms.

Therefore, to execute the offering.

  1. The Issuer generates a request QR code.
  2. The Holder autonomously scans this QR code with his credential management application or wallet.
  3. The Holder authenticates and verifies his identity to the Issuer, who, once approved, sends him the Verifiable Credential.

6. Verify the credential​

BLOOCK's identity product allows you to act as verification agents as well. Once our users or holders have their credentials, they will want to be able to verify themselves.

At this point, you have two options:

  1. Using external verifiers.
  2. Create your own verifier through BLOOCK.

If you want to use our verification process, here is how it works:

  1. You must create a request, which is nothing more than a QR code to show to the user or Holder you want to verify. In order to create the request you need to create a Verification Query. This functionality is available in our dashboard.
  2. Then, you will have to wait for your Holder to scan the request with its wallet or software and generate the proof on your request.

    It is important to note that within the request that you will show to your Holder, you can specify what things you want to validate. For example, you can determine that you only want to verify that it holds a credential of the type BloockEmployee or you can verify something more specific, such as that your employee's date of birth is less than 2000.

  3. Once you receive the proof from the Holder, it will be verified, and you will get a result of true or false, verified or not verified. The BLOOCK verification process establishes a customizable logic, adding an expiration time to the requests, by default 60 min. This means that when the request is created it will be invalidated after 60 min. If the user was already verified, after 60 minutes it will have to be verified again.

7. Revoke the credential​

Finally, Issuer may decide to revoke or invalidate any credential. Therefore, you will have to execute the revocation process. Having a credential revoked what it means is that the Holder will not be able to generate any proof. When you revoke a credential what we are doing is generate a new Sparse Merkle Tree Proof of revocation. Therefore, we need the Issuer's state to be processed once the revocation action is executed. And obviously this state transition will be marked by the interval we have set. It is important to note that the effect of the revocation will not be visible until this Issuer state transition is executed.

Last updated on