Decentralized Identity

Overview

Claim, credential, and attestation are used interchangeably in the wild.
The original terms come from the W3C standards on Decentralized Identifiers and Verifiable Claims.
From Júlio's pre-launch Medium post:
As a KYC provider for many blockchain-based projects, we rapidly became experts in the field of identity and its verification, but we shouldn’t be the custodians of people’s data — people should do so themselves, and we want to help them. Decentralized identity and verifiable credentials are not a novel idea, but are made possible with the help of blockchain technology. The concept works very much like in the physical world, where a person is given a physical credential by an authority (like a national ID issued by a government) and disclose it, voluntarily and without requiring government participation or knowledge, to a third party. By distributing these credentials to their legitimate owners, rather than centralizing them on our side, we can eliminate the security risk that any data honeypot poses while making sure users keep what’s theirs, regardless of what happens to us.
There’s a little magic trick that physical credentials can’t do, called selective disclosure. Say I want to get into a place that restricts patronage by age: I might be asked for a recognized identity document in order to prove how old I am. For example, I might hand my driver’s license to a club bouncer, who inspects the document for authenticity and calculates my age from my date of birth. The problem with this is that I ended up having to share much more with the bouncer than I wanted: they now know my name and a series of other attributes that are irrelevant for what they are trying to do.
Coupling verifiable credentials with the privacy-preserving properties of zero-knowledge proofs enables us to mathematically prove to any digital bouncer that we are over a certain age without revealing our name — or even our date of birth. Several technologies have proven successful in this regard, such as zk-SNARKS, zk-STARKS, and Bulletproofs. By leveraging them, the Fractal Protocol enables people to share only the information they want to, and no more.

DIDs: Decentralized Identifiers

DID stands for Decentralized Identifier, and represents a new identifier for an identity that is detached from central control. From the horse’s mouth:
Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, “self-sovereign” digital identity. DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority.
DIDs are URLs that relate a DID subject to means for trustable interactions with that subject. DIDs resolve to DID Documents — simple documents that describe how to use that specific DID.
Here’s an example of what a DID Document could look like:
1
{
2
"did": "did:example:person-123456789",
3
"pubKey": "DDoFgPQ4JyjrsBwqGg2yCoZdGk5x11k7nGXXeg3wokFy"
4
}
Copied!
This simple document declares a DID and its corresponding public key (more complex documents can include other info, such as the location of associated personal data, or the DID owner’s agent). There isn’t much one can do with this in isolation. However, combining a DID with verifiable claims is quite powerful. Proving ownership of a DID on which a trusted claim has been made would grant you access to whatever the claim grants you access to.

VCs: Verifiable Claims

Verifiable Claims are a method for trusted parties to provably issue a credential on a DID (claim and credential are used interchangeably in this post). Again, the W3C:
Driver’s licenses are used to claim that we are capable of operating a motor vehicle, university degrees can be used to claim our education status, and government-issued passports enable holders to travel between countries. This specification provides a standard way to express these sorts of claims on the Web in a way that is cryptographically secure, privacy respecting, and automatically verifiable.
Think of a traditional driver’s license. It’s usually issued by a trusted party (your local motor vehicle authority) on a person identified by a government ID. They evaluate your driving skills and, if you pass muster, they’ll associate a claim with your government ID saying you’re fit to drive.
Verifiable claims are a more secure way to achieve the same result on DIDs. If my identifier with the motor vehicle authority is not my government-issued ID, but a DID, how would this work?
First, they’ll need to verify that the applicant owns the DID they claim to. This is done through the use of public-key cryptography, as will be described later in this post.
Once that verification is completed, the authority can issue a claim confirming the applicant’s ability to drive. This is what it could look like.
1
{
2
"issuer": "did:example:trusted-authority-123",
3
"issued": "2010-01-01",
4
"claim": {
5
"id": "did:example:person-123456789",
6
"canDrive": true
7
},
8
"signature": "g4j9UrpHM4..."
9
}
10
}
Copied!
This represents a claim by did:example:trusted-authority-123 that the DID did:example:person-123456789 can drive. Anyone could produce a similar document. What makes this claim verifiable is that it’s signed. That is, we know that the signature value could only be correctly produced by the owner of did:example:trusted-authority-123 (because cryptography). This means that, if we know that did:example:trusted-authority-123 indeed represents the authority it claims to be, we can trust this claim to be legitimate, and ascribe did:example:person-123456789 the ability to drive.
Here’s a use case. Suppose you’re stopped by your local transit authority for a random document check. All they really need to know is that you’re authorized to drive. However, a traditional driver’s license contains a lot of other unrelated data (such as your name and address), and all that data leaks in the document check process. Proving ownership of your DID and showing the associated claim will yield only the information required and no more.

ERC 725 and 735

These are Ethereum-based standards to implement DIDs and VCs:
  • ERC 725 is a standard for publishing and managing an identity via a smart contract on an EVM-based blockchain, such as Ethereum. This identity is represented by its chain address.
  • ERC 735 deals with the management of claims made about an ERC 725 identity. It facilitates an emergence of a web of trust, by relying on the claims of trusted third parties about a given identity.
First impressions with ERC 725 and ERC 735 — identity and claims
Medium
(written in 2018 — possibly outdated)

KILT Protocol

KILT is building an ecosystem around their implementation of the W3C standards on their Substrate chain. From their FAQ:
KILT is an open-source fat blockchain protocol for issuing claim-based verifiable, revocable, and anonymous credentials in the Web 3.0. It allows end users to claim arbitrary attributes about themselves, get them attested by trusted entities, and store the claims as self-sovereign credentials (certificates). As trusted entities can issue credentials in return for money, KILT aims to foster new business models for anyone who owns trust or wants to build up trust.

Basic KILT flow

  • claimer
    • pays the attester for an attestation on their claim (a credential)
    • sends the credential to a verifier
  • attester
    • verifies the claim and attests it, creating a credential
    • returns a credential to the claimer
    • stores the credential hash on-chain
  • verifier
    • trusts attester
    • gets credential from claimer
    • verifies the credential hash exists on-chain
    • asks the claimer for a signature to confirm credential ownership

CTYPEs

For a claim to be made, it needs to conform to a claim type. A claim type (CTYPE for short) is a KILT-specific term, but the concept is simple: it defines the structure of a claim. You can think of it as the data model for your claim.
For example, a very basic CTYPE for a driver’s license (with only "name" and "age" attributes) could look like this:
1
{
2
"schema": {
3
"$id": "kilt:ctype:0xd8ad043d91d8fdbc382ee0ce33dc96af4ee62ab2d20f7980c49d3e577d80e5f5",
4
"$schema": "http://kilt-protocol.org/draft-01/ctype#",
5
"title": "Drivers License",
6
"properties": {
7
"name": {
8
"type": "string"
9
},
10
"age": {
11
"type": "integer"
12
}
13
},
14
"type": "object"
15
},
16
"owner": "5DD7fAZKSpgctg1ZQigAYuk3ypBtr2Q9RPKJBx5UpUwQw4vB",
17
"hash": "0xd8ad043d91d8fdbc382ee0ce33dc96af4ee62ab2d20f7980c49d3e577d80e5f5"
18
}
Copied!

See Also

KILT Tutorial 101
Last modified 5mo ago