Multiple Identity One Subject | Photo by Carson Arias on Unsplash

Self Sovereign Identity with Decentralized Identifiers, Verifiable Credentials, Verifiable Presentations and Ethereum

9 min readAug 14, 2020

original article https://blog.cogarius.com/index.php/2020/04/05/complete-guide-to-ci-cd-pipelines-with-drone-io-on-kubernetes-3-3-drone-metrics-with-prometheus/

TL;DR;

We will briefly discuss about why SSI is needed. Then we will talk about what are DIDs and how to resolve them using ethr-did from uport. This will lead to Verifiable Credential and Verifiable Presentation and how all these can help in a real life use case.

Self Sovereign Identity (SSI)

If you are here you probably already have the feeling that we need to have the sole ownership of our identity and total control over how our personal data is shared and used. This is by the way pretty much the definition of SSI.

The fact that one organization can have control over your identity and all your data have led to numerous scandals across history.

Of course you have heard about the revelations about the data analysis firm Cambridge Analytica and its influence on the U.S. election campaign. I am sure that you know about the internet giants monetizing and processing all your data and you are probably doubtful about data protection law offering a viable long term protection. So instead I will tell you about how a nice system built for good reason ended up a killing machine in the hand of the wrong people.

During the World War II the netherlands had the greatest number of jewish victims in western europe. Indeed Three quarters of the Dutch Jews were murdered during the Second World War. In other Western European countries such as Belgium and France, these percentages were much lower. One reason for that is that the German police had controlled over the civil administration’s data.They had access to all the identity card of all the citizens and could even detect identity card forgery. Indeed in 1936 all Netherlands resident was required to have a personal identity card stored in the civil archives and controlled from a single office. This system ensured that all citizens had access to basic civil services. At that time the dutch civil service was among the most efficient in Europe due to the work of JL Letz who even received a royal award for his work.

Although a centralized system is convenient and easy, only a decentralized one can prevent us from censorship and tyranny. Nobody but us should be in control of our identity and data. Luckily for us we now have all the tools to reach the self sovereign identity phase.

You can dig more on what is SSI and what is needed for it to be successful by reading Christopher Allen’s path to self sovereign identity

Architecture

For a SSI system to work we need several key components.

A public decentralized ledger to make registering our decentralized identity tampered proof, censorship resistant and widely available. We can use ethereum for that purpose.

A mechanism to issue proof of ownership without requiring a third party to verify and or issue the proof. We can use asymmetric cryptography for digital signature using the same algorithm used when signing an Ethereum transaction. Note that It can also be used to identify yourself. Also if your are familiar with OpenID you may have discovered the chapter 7 of the specifications, Self Issued OpenID Provider. There is a working group that aims to use DID and SIOP.

A specification that can standardize the way we identify and express credentials on internet. This is the ongoing work of the W3C. They have defined a new type of identifier that enables verifiable, decentralized digital identity aka Decentralized identifiers (DIDs) along with a standard way to express credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable. .

Let’s put all that together.

We can easily and with no third party generate a key pair that we can use to interact with Ethereum to sign and prove the ownership of that key pair.
Based on the keys we can construct a DID that will be resolvable by anyone with no third party simply by going through the transactions that was send to a smart contract. NB: The ERC1056 let us go even further and link to this DID attributes such as public encryption keys and temporary delegates that can sign on your behalf.
With our DID we can ask for and hold Verifiable Credentials (VC). Verifiable Credential can represent all of the same information that a physical credential represents. Digital signatures makes it more tamper-evident and more trustworthy than their physical counterparts. An issuer (e.g. corporations, governments or individuals) creating a verifiable credential is asserting claims (e.g. diploma, nationality, driving license) about one or more subjects (e.g. human beings, animals, and things) and transmitting the verifiable credential to a holder (e.g. students, employees, customers)
We can bundle Verifiable Credentials into Verifiable Presentations(VP) to express only the portions of our identity that are appropriate for a given situation. Data in VP is packaged in such a way that the authorship of the data is verifiable. Verifiers can also based on a VP issue a VC as we will see in our real life example use case.

Decentralized Identifiers

First we need to identify our self, let’s introduce DIDs in a few key points

Self sovereign identifiers for individuals, organization, things ..
Persistent, decentralized, cryptographically verifiable
Registered using wallets and blockchains or other decentralized architecture (Ledger agnostic)
Dereference able (meaning everybody can resolve it and find more about it like url)
Generation and control over DID lies with identity owner through private keys in a wallet
Ex of dids: did:ebsi:0xE6A534760965692b457076B8F0C1756CB8514698, did:ethr:0xE6A534760965692b457076B8F0C1756CB8514698, did:btcr:xz35-jznz-q9yu-ply, did:sov:WRfXPg8dantKVubE3HX8pw

What compose the did ?

DID is a URI composed of three parts the scheme “did:”, a method identifier (e.g. ethr, btcr, sov etc…) , and a unique, method-specific identifier generated by the DID method. DIDs are resolvable to DID documents. A DID URL extends the syntax of a basic DID to incorporate other standard URI components (path, query, fragment) in order to locate a particular resource — for example, a public key inside a DID document. Let’s take the example of the ethr method.

To create your own custom Decentralized Identity based on the Ethereum blockhain you will need:

A recipe to explain how DID and its associated DID document are created, resolved, updated, and deactivated using Ethereum. This recipe is the DID Method specification. Here is the ethr did method spec.
Some metadata associated to your DID like public keys or services to interact with the subject of the DID. These are bundled in the DID Document. DID Document can include set of pub keys, set of service endpoints, timestamp and proofs and other identifier metadata

Here is an example for did:uport:2osnfJ4Wy7LBAm2nPBXire1WfQn75RrV6Ts

{
  "@context": "https://w3id.org/did/v1",
  "id": "did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6",
  "authentication": [
    {
      "type": "Secp256k1SignatureAuthentication2018",
      "publicKey": [
        "did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6#owner"
      ]
    }
  ],
  "publicKey": [
    {
      "id": "did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6#owner",
      "type": "Secp256k1VerificationKey2018",
      "ethereumAddress": "0xe6fe788d8ca214a080b0f6ac7f48480b2aefa9a6",
      "owner": "did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6"
    },
    {
      "id": "did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6#delegate-1",
      "type": "Secp256k1VerificationKey2018",
      "owner": "did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6",
      "publicKeyHex": "0295dda1dca7f80e308ef60155ddeac00e46b797fd40ef407f422e88d2467a27eb"
    }
  ]
}

Note that here public keys ids are in fact DID URL like did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6#owner

A way to store DID Document that you can trust and easily accessible like distributed ledgers, decentralized file systems, databases of any kind, peer-to-peer networks. Any such system that supports recording DIDs and returning data necessary to produce DID documents is called a verifiable data registry. For ethr it is simply a smart contract on Ethereum
A way to resolve the DID to DID document. In our example it is how based on a DID I can read the transactions that happened on Ethereum to construct the DID document. This piece of software and/or hardware is called a DID Resolver. There is a Universal Resolver accessible online if you want to give it a try.
There are cases when the entity that controls the DID is different from the DID subject. For instance if you want your pet to have a Digital Identity you as the DID controller will be able to make changes to the DID document identifying your pet. Your pet is in this case the DID Subject. Indeed a DID may have more than one controller, and the controller(s) may include the DID subject.

Here is the overall architecture.

Verifiable Credentials and Verifiable Presentations

Now we want to be able to claim things related to DID. For instance how can we prove that our pet won the halloween costume contest.

We would need the dog show company (aka the Issuer) to issue a proof (a Verifiable Credential) that wolfy our dog (aka the Subject) won the contest (aka the Claim). We would then store that proof (that makes us the Holder) to throw in the face of whoever doubt wolfy curriculum (aka a Verifier). We could also assemble all kind of proof (VC bundled in a Verifiable Presentation) about wolfy handsomeness in a single document to make it even more powerful !

Here is what we can do with VC and VP

The VC is statement made by an Issuer about a Subject in a tamper-evident and privacy-respecting manner.
Holders assemble collections of verifiable credentials from different issuers into a single artifact, a verifiable presentation.
Verifiable presentations allow any verifier to verify the authenticity of verifiable credentials from any issuer.
Holders can store verifiable credentials in any location, without affecting their verifiability and without the issuer knowing anything about where they are stored or when they are accessed.
Acting as issuer, holder, or verifier requires neither registration nor approval by any authority, as the trust involved is bilateral between parties.
Issuers can issue revocable verifiable credentials. They would never do that to wolfy !

Here are some examples

alumni verifiable credential from a university

Verifiable Presentation of an alumni Verifiable Credential from a university

Use case

Ana wants to benefits from a mobile plan discount restricted the red university alumni. In order to register she needs to disclose a proof from the university and a her bank account.

Here is how it would work with the ethr method DID, VC and VP.

The telecom company is provided with tamper-evident, cryptographically signed and verfiable proofs about an eligible DID. It doesn’t leak too much personal data only what is required. Indeed first of all the company only knows that the did:eth:0xcAc6EF… is eligible not Ana. The company doesn’t know what kind of diploma is related to the DID only that it is an alumni.

An interesting property of Verifiable presentations is that it can either disclose the attributes of a verifiable credential, or satisfy derived predicates requested by the verifier. Derived predicates are a verifiable, boolean assertion about the value of another attribute in a verifiable credential. These are useful in zero-knowledge-proof-style verifiable presentations because they can limit information disclosure. For example, if a verifiable credential contains an attribute for expressing a specific height in centimeters, a derived predicate might reference the height attribute in the verifiable credential demonstrating that the issuer attests to a height value meeting the minimum height requirement, without actually disclosing the specific height value. For example, the subject is taller than 150 centimeters.

If you have questions remarks you can PM me: telegram:@Zgorizzo mail: ben@cogarius.com