Skip to main content

Protocol

These are the core components of the BLOOCK Identity product.

The Issuer​

The Issuer is an entity (person, organization, or thing) that issues Verifiable Credentials (VCs) to the Holders. VCs are cryptographically signed by the Issuer. Every VC comes from an Issuer.

The role of an Issuer on BLOOCK Identity is to issue digital credentials to users that can be used to prove aspects of their identity and enable various features and actions for users.

The Issuer in BLOOCK​

  • Each Issuer generates a DID and therefore a unique and public identifier that represents that identity. For example: did:polygonid:polygon:main:2qCU58EJgrELSJT6EzT27Rw9DhvwamAdbMLpePztYq.
  • To create an Issuer you need to have a key of type Baby JubJub (BJJ), with BLOOCK Keys product you can create a managed key where you only need to save its identifier. For example: 6f36448d-49f3-4b0e-aa72-6e55863302e8.

    You can also create an identity with your own local key of type BJJ. But then, you will have to maintain it on your own.

  • Every Issuer must configure how often they want their credentials to be transacted to the blockchain. Learn more about Issuer intervals.

Issuer intervals​

To understand this section, you must first understand what a Sparse Merkle Tree Proof is and how important it is to your business.

When an Issuer creates a credential, it will be instantly available synchronously. However, when you create an Issuer you will have to choose the transaction interval you want to apply (the cost of use will vary depending on the interval). When we talk about transaction, we talk about transacting your credentials to blockchain and get a proof of integrity of them that is transformed into a verifiable proof called Sparse Merkle Tree Proof (SMTP).

We currently offer these intervals.

  • 1 minute frequency.
  • 5 minute frequency.
  • 15 minute frequency.
  • 60 minute frequency.

Example: Let's imagine that you choose a frequency interval of 60 minutes. What it means is that all the credentials created during the last hour (60 minutes), will asynchronously run a job that will collect them and execute a transaction on the blockchain. Once the transaction is completed and confirmed, an integrity proof (SMTP) will be automatically generated on all those credentials (each credential will have its own proof). In the case of using a did:polygonid Issuer the network where the transaction is made is the one marked in the blockchain and network DID, i.e. did:polygonid:polygon:main will be transacted over the polygon blockchain and the mainnet network.

The Verifiable Credential (VC)​

The first thing is to be clear what a claim is. A credential is a set of one or more claims made by an Issuer. Credentials might also include an identifier and metadata to describe properties of the credential, such as the validity date and time period, verification material, the revocation mechanism, and so on. The metadata might be signed by the Issuer. A Verifiable Credential (VC) is a set of tamper-evident claims and metadata that cryptographically prove who issued it.

https://cdn.discordapp.com/attachments/1151100469490487307/1207640880496906271/Group_1325.png?ex=65e06236&is=65cded36&hm=37f9f2c8351494ea9014baaa4418cc82808315165a65128e2f831aa376856d9f&

Verifiable Credential in BLOOCK...​

Schemas​

The reusability of credentials across platforms and services is guaranteed by credential schemas.

BLOOCK Identity use JSON-LD documents to represent credential schemas.

You must create a schema, which in the end will serve as a template for your credentials, these schemas contain the attributes (claims) that your credentials (VCs) will have. This way, you will be able to reuse your schemas and have more control over the structure of your credentials.

Therefore, to create a credential you must first create a schema and associate it.

These schemas are published in IPFS and therefore generate an id of this type QmadTvnNKvj2fBDgen35uAp1TfP9pSPVCNeDWw4fitqqne. This is the identifier of your schema.

Proofs​

Both proofs guarantee that the claim is tamper-resistant.

Signature Proof​

The claim gets signed by the Issuer using his private key. The proof of issuance is the signature itself. This action doesn't modify the identity state of the Issuer, so there's no on-chain transaction involved.

This proof is always generated synchronously when the credential is created.

Sparse Merkle Tree Proof (SMTP)​

All the credentials that the Issuer creates are stored in a tree structure, specifically in a Sparse Merkle Tree.

When an identity adds a new claim to his Claims Tree, the root of the tree and, consequently, the identity state change. The process of moving from one state to another is defined using State Transition.

State Transition​

The Issuer states are published on the blockchain under the identifier, anchoring the state of the Issuer with the timestamp when it is published. In this way, the credentials of the Issuer can be proved against the anchored Issuer state at a certain timestamp. To transition from one state to the other, issuers follow the transition process.

Revocation​

Revocation is the process of invalidating a credential (VC). Just as we have a tree structure (SMT) to store Issuer credentials, we also store revocations in a separate tree (SMT). These two structures will then mark the actual state of the Issuer. Therefore, the action of adding the revocation to the revocation tree modifies the root of the revocation tree and, consequently, the identity state.

The most important thing to keep in mind is that the revocation will only be effective at the moment the Issuer's state is transacted on the blockchain. So, the effectiveness of the revocation will be marked by the interval you have defined in the Issuer.

The Holder​

The Holder or the user receiving credentials. It is an identity and therefore has its own public DID. It is important that the Holder is of the same topology as the Issuer that will issue the credential. Currently we only accept did:polygonid issuers and holders.

For example.

  • Issuer: did:polygonid:polygon:main:2qCU58EJgrELSJT6EzT27Rw9DhvwamAdbMLpePztYq.
  • Holder: did:polygonid:polygon:main:2q544HUegzeRpwr3V2qu9eMwgrAmF5x4E1NCPzbQc4.

Currently your users will be able to create an identity using the PolygonID wallet, which can be downloaded here.

BLOOCK Identity will soon expand support for more identity wallets.

What is a wallet?​

A digital wallet is an application or software designed to protect and manage identities or holders. A wallet allows you to interact with the Issuer when we want to obtain or acquire our credentials and interact with the Verifier to share and verify our proofs contained in our credentials.

A wallet is controlled by an identity and therefore must have its own DID. That is why, in most of these wallets when we install the application the identity it's created. That identity will control the wallet. For example, the PolygonID wallet creates an identity like this: did:polygonid:polygon:main:2q544HUegzeRpwr3V2qu9eMwgrAmF5x4E1NCPzbQc4.

Each wallet must follow a communication protocol in order to interact with the Issuer and the Verifier. For example, PolygonID wallet follows the DIDComm protocol.

The Verifier​

The Verifier is the entity responsible for receiving and processing verifiable credentials.

The verification process consists of the evaluation of whether a Verifiable Credential is an authentic and current statement of the Issuer. This includes checking that: the credential conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds.

The Verifier is responsible for issuing a request to the Holder. This request contains the queries that the Holder must fulfill to be verified. Here to learn more about queries. The request of the Verifier is designed and encapsulated into a QR code to be shown to the Holder. The Holder scans the QR code with its Wallet to prompt the proof generation.

The verification process doesn't involve any interaction between the Verifier and the Issuer of the requested credential. As part of the Query, the Verifier includes the identifiers of the trusted issuers.

At the end of the process, the verifier gets a cryptographic proof that the Holder satisfies or not the query.

This is the process that a verifier would perform:

  1. Generates the Query request and display it for the Holder to be checked.
  2. Initiate a waiting process to obtain verification.
  3. Validate the cryptographic proof generated by the Holder and allow access, or otherwise, if it is invalidated, block access.

At BLOOCK Identity we offer you a verification model, but it is important that depending on your business model, you can customize it as much as you want. We perform a polling and expiration verification. Once the Verifier creates the Query request to the Holder, it starts what we call a verification process, which consists of simply polling a function that returns whether the request has been verified correctly or not (it returns a boolean). This polling process also has a timeout that you can configure. In addition, the verifications have a default expiration of 60 minutes, meaning that the Query request has an expiration of 60 minutes. If a user is already validated but the 60 minutes time expires, he/she will have to be validated again, this expiration period is also customizable.

The Verifier must choose which type of proof to verify (you can only verify one type of proof).

Verification queries​

BLOOCK Identity works with Zero-knowledge proof (learn more about it here). For this, we work with Query language specification, to provide a simple way for developers to design customized authentication requirements for someone's credentials.

As long as the user holds a credential of a specific type, the Verifier can design a query based on 6 operators, for example:

  1. Must have an employment status of "active" to access sensitive company data - equals (operator 1).
  2. Must have joined the company before 2020-01-01 to be eligible for the company's pension plan - less-than (operator 2).
  3. Must have a monthly salary greater than $2000 to qualify for a company car lease - greater-than (operator 3).
  4. Must be a manager or an IT specialist at BLOOCK to access the server room - ìn (operator 4).
  5. Must not be a resident of a country in the list of restricted travel destinations to attend company events abroad - not-in (operator 5).
  6. Must not be a resident of the state where the company's rival firm is located to be considered for a promotion - not-equal (operator 6).

Currently you can only verify a single attribute of a Verifiable Credential. This means that your Query request will only be able to verify for example that the BLOOCK employee is born before 2020-01-01. If, for example, you want to verify another attribute you will have to generate a new Query request.

Zero-knowledge proof​

In cryptography, a zero-knowledge proof or zero-knowledge protocol is a method by which one party (the prover) can prove to another party (the verifier) that they know a value x, without conveying any information apart from the fact that they know the value x. (Source)

In other words, zero-knowledge proofs allow us to prove something specific without revealing any extra information.

BLOOCK Identity works with this type of proofs technology, so the security and privacy of your users' credentials is very high, because when they verify their credentials, the data itself is never shared.

DIDComm messaging​

BLOOCK Identity uses the DIDComm messaging protocol for communication between agents and wallets. The purpose of DIDComm Messaging is to provide a secure, private communication methodology built atop the decentralized design of DIDs. We use this protocol with the Iden3comm.

Last updated on