Energy Web Discord GitHub

Self-Sovereign-Identity

This page introduces the concept of Self-Sovereign identity (SSI), the components of Decentralized Identifiers (DIDs) and verifiable credentials (VCs), and how they provide the mechanisms for identity access and management in EW-DOS.

To learn more about Energy Web's implementation of SSI technologies, visit the Identity and Access Management page.

Self-Sovereign Identity (SSI)

Self-sovereign identity (SSI) is a term used to describe the digital movement that recognizes an individual should own and control their identity without the intervening administrative authorities. SSI allows people to interact in the digital world with the same freedom and capacity for trust as they do in the offline world.

- Sovrin.org

‘Self-Sovereign Identity’ is a growing paradigm that promotes an individual’s control over their identity and their data. This is in contrast to the current paradigm where most of our official identifiers (driver’s license, birth certificate, usernames, etc.) are given to us and maintained by a central authority, and where our data can be shared without our knowledge or consent.

The SSI movement catalyzes the shift away from stratified, centralized authorities as the distributors and overseers of identity, and toward a system where individuals can maintain their own identity and where verification and data-sharing can occur via secure, digital consent.

Components of SSI

Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) are two of the most important components of SSI.

A DID is an identifier that can be generated and controlled by individuals or organizations without an external authority. It can be used to identify any subject, such as a non-tangible asset, a customer, or an organization.

A Verifiable Credential is a secure and machine-verifiable digital credential which respects a standard data model.

Together they allow users and organizations to have control over their identities. Instead of an external authority maintaining control over an identifier and its associated identity data, any individual or asset can create an identity, and then establish credentials over time through interactions with peers or authorities on a trusted, decentralized network.

Both DIDs and VCs are specifications of the W3C. The W3C is an organization which provides core technical specifications to establish guidelines and best practices for an open, inclusive and trustworthy web. Energy Web’s approach to DIDs and VCs is sufficiently abstract and flexible that it can be used with the Energy Web Chain, another blockchain, or no chain at all.

Additional Resources on Self-Sovereign Identity

Decentralized Identifiers (DIDs)

A DID is an identifier that is user-generated and not coupled to any centralized authority. It can be used to identify any subject, such as a non-tangible asset, a customer, or an organization.

Unlike traditional forms of identification, DIDs are not generated by a central authority, such as a government-issued driver’s license, or a bank-issued account number, and they are not stored in a centralized database. A user can create a DID for themselves or an asset using cryptographic or other means.

A DID for a given system resides in a decentralized DID registry. DID Registries, like VCs and DIDs themselves, are developed according to W3C standards. Most DID registries live on a decentralized ledger, or a blockchain. In the case of EW-DOS, the DID registry is on the Energy Web Chain.

How are DIDs Created?

Public-Private Key Pairs

A DID is derived from a public-private key pair that is generated programmatically through a cryptographic algorithm. The algorithm produces a private key and a corresponding public key. Crypto wallets such as MetaMask will generate these keys for you on creation of an account. The public key can be exposed and shared with others, but the private key should not be shared with anyone. The algorithm used to generate the key-pair makes it virtually impossible for any outsider to guess your private key.

Your public key serves as your address on the blockchain, and your private key serves as your private identifier, similar to a password, and is used to sign transactions on the blockchain. The signature is proof that you initiated that transaction.

DID Format

DIDs are made up of a scheme, a method and a unique method identifier. There are many DID methods that are supported by different blockchain networks. You can see a full list here. DID methods define operations to create, resolve, update and deactivate DIDs and their associated DID Documents, which are discussed below. DID Methods are often associated with a verifiable data registry, which are registries with store DIDs and their data. If the registry is implemented on a blockchain, smart contracts usually serve as the data registry. An example of this is the did:ethr registry.

Energy Web Chain uses the ETHR DID Method Specification. The string that identifies this DID method is "ethr", and the method identifier is always the user’s public key (also known as an address.)

DID Documents

Every DID resolves to a corresponding DID document, which contains metadata about the subject's authentication mechanisms and attributes, like its public key.

Below is a sample JSON document that was created by the EW-DOS DID library. For a list of required and possible DID Document properties, see the W3C documentation on DID Document Properties.

{
   "id":"did:ethr:0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75",
   "authentication":[
      {
         "type":"owner",
         "validity":{
            "_hex":"0x1fffffffffffff"
         }
      }
   ],
   "created":null,
   "delegates":null,
   "proof":null,
   "publicKey":[
      {
         "id":"did:ethr:0x5B1B89A48C1fB9b6ef7Fb77C453F2aAF4b156d45#key-owner",
         "type":"Secp256k1veriKey",
         "controller":"0x5B1B89A48C1fB9b6ef7Fb77C453F2aAF4b156d45",
         "publicKeyHex":"0x02d0e12da3425d7b01fd2e49b283f939f3a13d71273d749dd8933d3b792bb20078"
      },
      {
         "id":"did:ethr:0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75#key-owner",
         "type":"Secp256k1veriKey",
         "controller":"0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75",
         "publicKeyHex":"0x020ee3388dd3db4e3e4da39f2fdc27113161d33579c4d0350b5672bcb654ceff98"
      }
   ],
   "updated":null,
   "@context":"https://www.w3.org/ns/did/v1"
}

Additional Resources on DIDs

Medium Series on private keys and their relevance in the Ethereum Network:

MetaMask glossary on key terms:

Verifiable Credentials (VCs)

Above we discussed the role of identity. Once an identity is established, it exists in a DID registry, but nothing is known about the subject through a digital identity alone. That is where Verifiable Credentials come into play.

A credential is something that we can prove about a subject or individual. Common examples of credentials include a driver's license, that proves that one has passed a test and can drive a particular class of vehicle, or a passport, that proves one is approved to travel internationally until a specified date in the future. These traditional credentials are authorized and issued by a central authority, such as a government bureau or a bank. They are distinct and not interchangeable. For example, you cannot use your passport to show that you can drive a car, and you cannot show your driver's license to prove that you can travel.

What is a Verifiable Credential?

Verifiable Credentials are a Web3 standard for digital credentials in a decentralized ecosystem, meaning a system with no central issuer or authority.

Like traditional credentials, VCs are statements or claims made about an identity, which is referred to as the credential subject. If a battery was the credential subject, it could have a verifiable claim that it originated in a particular manufacturing plant, or that it has a specific discharge rate at the time of manufacturing.

Issuers, Holders, Verifiers

There are three primary actors in the facilitation of Verifiable Credentials.

  1. Issuer: makes a claim about a credential subject and correspondingly creates and issues credentials asserting the claim.

  2. Holder: receives, holds and shares credentials

  3. Verifier: receives and verifies proofs (proofs can be the entire credential or a piece of info from the credential)

Credential Verification

The main difference between traditional, non-digital credentials and verifiable credentials are the way they are verified.

Traditional credentials require manual verification, such as a signature or a stamp. Verifiable Credentials are verified completely through cryptographic means using a digital proof mechanism, such as a digital signature or a JSON Web Token, through a digital trust mechanism, such as a blockchain.

In the context of EW-DOS, a digital cryptocurrency wallet such as MetaMask, which holds a user’s public and private keys, is used to facilitate a digital signature. This eliminates the need for any interaction between the issuer and the verifier. The blockchain provides the platform and mechanisms of trust.

Once an authority verifies a claim, a VC can then be used as an official record to assure others of the truth of the statements. These credentials are linked back to the credential subject’s digital identity. In the case of EW-DOS, credentials are linked back to the user's DID document. A DID Document can amass a rich set of Verifiable Credentials that provide a full picture of its origin, attributes and capabilities.

To see a more exhaustive list of possible interactions and use cases for issuers, holders and verifiers, see w3’s list of Verifiable Credential use cases.

Additional Resources on Verifiable Credentials

DIDs and VCs in EW-DOS

One goal of our technology is to give every participant in the energy system an identifier to allow for broad participation in decentralized applications built on the Energy Web Chain. Participants include individuals, organizations, applications and energy assets.

EW-DOS can be considered a self-sovereign ecosystem because there is no central administration or server to manage identity or verify attributes. As long as a user has a public-private key-pair, they can create a DID, which is then stored in the DID registry on the Energy Web Chain.

Once identity is established, VCs are the primary mechanism for acquiring attributes and sharing these attributes with other participants through cryptographic consent. VCs then determine if an asset can participate in a particular role or application based on set criteria.

To see the relationship of DIDs and VCs in the EW-DOS use cases, we recommend that you explore the Energy Web Interactive DID Explorer Dashboard.

An example of DIDs and VCs in an asset lifecycle

To understand how and why an asset can take on a DID and acquire and use VCs using EW-DOS, let’s use the lifecycle of a battery as an example.

  1. When the battery is manufactured, the manufacturer assigns a DID to the battery, and issues claims on the battery’s physical makeup (date of manufacture, the model, the serial number, the battery capacity.)

  2. The battery is sold. The installer of the battery adds new claims on the battery’s purchaser and its new location.

  3. As the battery performs, the new owner adds claims on the battery’s charge and discharge rate.

  4. The battery reaches the end of its lifecycle. The final owner of the battery adds the date that it is retired, and its final charge and discharge rate.

Because we now have verified information on the battery, the battery can use its DID to participate in various energy markets and provide services to the grid based on its confirmed attributes. This all happens without central oversight of the battery, and the battery is not restricted to participating in only one market. It can participate in any market or application that is using the Energy Web Chain.

Managing DIDs and VCs in EW-DOS

The Identity and Access Management stack

EW-DOS’s Identity and Access Management (IAM) technology stack is composed of a decentralized application called Switchboard and several underlying packages listed below that manage the creation, reading, updating and removal of DIDs and VCs on the Energy Web Chain. To read more about Switchboard and its dependencies, go here.

The IAM stack provides means for authentication (proving you are who you are via DID) and authorization (proving you have the attributes to participate in a certain role via Verifiable Credentials.) The combination of a user's DID and VCs provide authentication to access multiple systems using role-based permissioning. You can view the components of the IAM stack below.

Where are DIDs Persisted?

DIDs are anchored on the Energy Web Chain in the DID Library smart contract. The DID library currently implements the ERC1056 standard for creating and updating identities on the blockchain, but will support other DID methods and standards in the future.

Where are VCs Persisted?

****VCs are stored off-chain on IPFS, a decentralized, peer-to-peer file system that uses content hashing for file location. The credential's corresponding DID Document has a service node that holds an array of service endpoints. Each serviceEndpoint points to the location of a Verifiable Credential stored on IPFS. Once retrieved, the VC is decoded and its contents can be read.

You can see a serviceEndpoint present in a DID document's service array below:

{
   "id":"did:ethr:0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75",
   "service":[
      {
         "id":"d88cb569-8390-420b-a685-b0e7a62ebe7c",
         "did":"did:ethr:0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75",
         "iat":1620072464520,
         "iss":"did:ethr:0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75",
         "sub":"did:ethr:0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75",
         "hash":"ffb51dc355c5ffd11b8733b2ea9ab4646343873f5adb334b0b1030f9d59b723b",
         "signer":"did:ethr:0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75",
         "hashAlg":"SHA256",
         "profile":{
            "name":"First Last",
            "address":"Washington, DC",
            "birthdate":539931600000
         },
         "serviceEndpoint":"QmRmwLTjzC4NeinPTHn3zuLazgGeyHrVvoCUR6v2ErAiDT"
      }
   ],
   "authentication":[
      {
         "type":"owner",
         "validity":{
            "_hex":"0x1fffffffffffff"
         },
         "publicKey":"did:ethr:0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75#owner"
      }
   ],
   "created":null,
   "delegates":null,
   "proof":null,
   "publicKey":[
      {
         "id":"did:ethr:0x5B1B89A48C1fB9b6ef7Fb77C453F2aAF4b156d45#key-owner",
         "type":"Secp256k1veriKey",
         "controller":"0x5B1B89A48C1fB9b6ef7Fb77C453F2aAF4b156d45",
         "publicKeyHex":"0x02d0e12da3425d7b01fd2e49b283f939f3a13d71273d749dd8933d3b792bb20078"
      },
      {
         "id":"did:ethr:0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75#key-owner",
         "type":"Secp256k1veriKey",
         "controller":"0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75",
         "publicKeyHex":"0x020ee3388dd3db4e3e4da39f2fdc27113161d33579c4d0350b5672bcb654ceff98"
      }
   ],
   "updated":null,
   "@context":"https://www.w3.org/ns/did/v1",
   "logs":"{\"owner\":\"0x0000000000000000000000000000000000000000\",\"topBlock\":{\"_hex\":\"0xb59258\"},\"authentication\":{},\"publicKey\":{\"did:ethr:0x5B1B89A48C1fB9b6ef7Fb77C453F2aAF4b156d45#key-owner\":{\"id\":\"did:ethr:0x5B1B89A48C1fB9b6ef7Fb77C453F2aAF4b156d45#key-owner\",\"type\":\"Secp256k1veriKey\",\"controller\":\"0x5B1B89A48C1fB9b6ef7Fb77C453F2aAF4b156d45\",\"validity\":{\"_hex\":\"0x2000006087e1f8\"},\"block\":11552030,\"publicKeyHex\":\"0x02d0e12da3425d7b01fd2e49b283f939f3a13d71273d749dd8933d3b792bb20078\"},\"did:ethr:0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75#key-owner\":{\"id\":\"did:ethr:0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75#key-owner\",\"type\":\"Secp256k1veriKey\",\"controller\":\"0x17b65C8C9746F87c82cc6f7C4FC38fCA5f1AeB75\",\"validity\":{\"_hex\":\"0x60b4ed75\"},\"block\":11899480,\"publicKeyHex\":\"0x020ee3388dd3db4e3e4da39f2fdc27113161d33579c4d0350b5672bcb654ceff98\"}},\"service\":{\"d88cb569-8390-420b-a685-b0e7a62ebe7c\":{\"id\":\"d88cb569-8390-420b-a685-b0e7a62ebe7c\",\"serviceEndpoint\":\"QmRmwLTjzC4NeinPTHn3zuLazgGeyHrVvoCUR6v2ErAiDT\",\"hash\":\"ffb51dc355c5ffd11b8733b2ea9ab4646343873f5adb334b0b1030f9d59b723b\",\"hashAlg\":\"SHA256\",\"validity\":{\"_hex\":\"0x2000006090581a\"},\"block\":11631883}},\"attributes\":{}}"
}

EW-DOS Identity and Access Management Stack

EW-DOS Components that implement functionality for DIDs and VCs in EW-DOS.

Component

Role

Switchboard

A decentralized application for defining a role credential governance framework and issuing role credentials. These functions are performed by interfacing with user's Web3 wallet.

IAM Library

Provides high-level functions for all identity and access management

DID Library

Provides an abstraction layer to manage and interact with DIDs and Verifiable Claims on Energy Web Chain

SSI Hub

Facilitates the credentials exchange between credential requesters and issuers. It also caches smart contract data such DID documents in order to improve read-query performance.

Energy Web Chain

Decentralized DID registry

IPFS

Off-chain, decentralized, peer-to-peer storage for Verifiable Credentials

Additional Resources on DIDs and VCs in EW-DOS

PreviousTransactions and Transaction CostsNextSelf-Sovereign Use Case Interaction

Last updated