Blockchain for Decentralized Identity — Layer 3 — The Trust Triangle
To issue a credential, the issuer first writes a DID (decentralized Identifier), its definition, the schema of the verifiable credential, and its public key to the blockchain. Next, the issuer issues a Verifiable Credential composed of claims that the holder can use to provide proof (a cryptographic verification of a claim). For example, a driver’s license is a verifiable credential with claims that include driver’s license number, Name, Photo, Expiration Date, etc. Each is a claim from the driver’s license and can be used independently for proof without sharing the full license. Selective disclosure of identity information is known as zero-knowledge proof. Finally, any verifier or “relying party” can request proof of claims from a holder to complete a transaction.
The three essential components of a Verifiable Credential include:
1. Metadata: describes the properties of the Verifiable Credential, e.g., issuer, expiration date, an image, or a public key.
2. Claims: A statement; e.g., John Smith’s DOB is 04/23/91.
3. Proofs: contain data about the identity holder that allows others to verify the source of data (issuer), check that the data belongs to the holder, enable ZKPs (zero-knowledge proofs), create compound proofs, verify that the data has not been tampered with, and not been revoked by the issuer.
The agent’s controller manages the correct sequence of the messages. Business logic driven by a rules engine defines the series of events executed in a transaction. For example, after the issuer registers on the blockchain with their public key, they connect securely with the holder to issue a verifiable credential.
The transaction can include four message types:
1. The issuer proposes an offer to issue a credential to the holder
2. The holder accepts the request from the issuer
3. The issuer then issues the credential
4. The holder sends a confirmation of the receipt of the credential to the issuer
The claims in a Verifiable Credential respond to a request for attestation utilizing the concept of zero-knowledge proof (ZKP). A zero-knowledge proof is a method of authentication using cryptography that allows an entity to prove to another that specific requirements for a transaction are met instead of disclosing all the data. The verifier has zero knowledge of the underlying data. Since the source is reliable, it meets the verifier’s condition. First, it protects the holder’s privacy and prevents over-sharing data for a transaction. Next, it implements the minimization principle in self-sovereign identity when the holder only shares what is necessary to complete a transaction.
The holder can use claims from multiple verifiable credentials to respond to an attestation request. It would constitute a compound proof, also referred to as compound verification presentation.
The proofs or verifiable presentation to a verifier contain the issuer information, the holder information, the unchanged claims, and confirmation that the claims are not revoked. While entering the credential in the registry, the issuer also enters a record in the revocation registry. Both registries are on the blockchain. If required, the record gets called to revoke the credential in the future. Only the holder knows when the credential gets revoked. With zero-knowledge proof, the holder can prove, and the verifier can verify that the credential is not revoked. Each revoked credential has a unique identifier on the ledger. Constructing the proof of non-revocation is done by the holder/verifier. The verifier gets the DID and other cryptographic content of the issuer from the blockchain and decides whether it is a trusted source.
The benefits of using Verifiable Credentials (VC) include:
1. They are private
2. The identity holder can choose what attributes of the VC to share
3. Enables Zero-Knowledge Proofs
4. The identity holder is always in control
5. They are tamper-proof through cryptography
6. They are verified anytime, anywhere
7. They are portable
The exchange of data at the endpoints uses QR codes. For example, the issuer sends the holder a verifiable credential via a QR code. The holder reads, accepts, and then stores it in the Digital Wallet. Similarly, when the verifier sends or receives an attestation request, it is read at the endpoint using a QR code. In addition, biometrics used as claims in verifiable credentials get delivered to endpoints utilizing a QR code. The holder scans and stores them following the same protocols as other verifiable credentials.
In the next post, I will cover Layer 4 of the stack.
To reference previous posts refer to this link. Again, I would suggest reading the posts in succession.
Glossary:
Holder
A user with a Digital Wallet; receives, stores, controls verifiable credentials that they own. In addition, the holder approves attestation requests from Verifiers.
Issuer
An issuer is a credible provider of identification documents; their signature attests to the credentials’ validity. Issuers within a business ecosystem of trusted entities issue documents/credentials with claims data. Issuers will have the infrastructure to access a public blockchain to issue and revoke credentials.
Verifier (sometimes referred to as Relying Party)
People or organizations who want to verify claims from a holder to close a transaction. The verification is required for the holder to perform a transaction. The verifier can request proofs via blockchain and read the response via a QR code.
Verifiable Credential
A credential is an attestation of authority, competence, or qualification given by an authorized party (issuer) to an entity (holder). It consists of metadata, claims, and proofs and has one or many claims related to an entity’s identity. It is to respond to attestations for proof of a claim. Claims from multiple verifiable credentials consolidated to respond to a request for proof, is called a compound verifiable credential.
Zero-Knowledge Proof
A zero-knowledge proof is a method of authentication using cryptography that allows an entity to prove to another that specific requirements for a transaction are met instead of disclosing all the data (selective disclosure).
Reference:
1. W3C https://www.w3.org/TR/vc-data-model/
Contact
Linkedin https://www.linkedin.com/in/anitarao/,
Twitter @anitaprao,
#SSI; #decentralizedidentity; #blockchain; #digitalidentity; #selfsovereignidentity; #identity; #dlt; #web3; #web3.0; #dApps; #digitalwallets; #distributedledger
