Decentralized Identity Management, Blockchain – Why Bother

This blog represents details on Decentralized Identity Management and why you should care? Given that IBM, Hyperledger has joined Blockchain Identity Consortium makes it much more important to quickly go over the concepts related with decentralized identity management. Check out a related Hyperledger project, Project Indy, on supporting independent identity on distributed ledgers.

Traditional Centralized or Federated Identity Management System

Conventional identity management systems have always been based on centralized authorities such as corporate directory services , certificate authorities (CA) , or domain name registries. Each of these centralized identity management systems acted as a “root of trust”.

In order to have the identity management work across different systems, there is something called as federated identity management. According to Wikipedia post of Federated Identity, a federated identity in IT is the means of linking a person’s electronic identity and attributes, stored across multiple distinct identity management system.

What is Decentralized Identity Management System?

Following are some of the key points to understand decentralized identity management in better manner:

• In decentralized identity management system, there are no centralized authorities anymore. The “root of trust” lies with Distributed Ledger. The copies of ledger are maintained by multiple participants, and thus, distributed ledger. Note that Blockchain is one of the classic example of Distributed Ledger Technology.
• Entities no more identify themselves with traditional centralized authorities such as CAs, domain name registries etc. They rather identify themselves with the distributed ledger.
• Each entity is assigned as Decentralized Identifiers (DIDs).
• DIDs can be used to point what is called as DID Document.
• DID Document may consists of one or more service endpoint that can be used to interact with the entity. This comes in a JSON format. Every DID document must have an associated DID. This is how a DID document would look like:

  {
    "@context": "https;//w3id.org/did/v1",
    "id": "did:example:123456789abcdefghi",
    "authorizationCapability": [{
      // this entity is a delegate and may update any field in this
      // DID Document using any authentication mechanism understood
      // by the ledger
      "permission": "UpdateDidDocument",
      "entity": "did:example:zxyvwtrkpn987654321"
    }],
    "credentialRepositoryService": "https://vc.example.com/abcdef",
    "authenticationCredential": [{
      // this biometric can be used to authenticate as DID ...fghi
      "id": "did:example:123456789abcdefghi/biometric/1",
      "type": "PseudonymousBiometricTemplate2017",
      "owner": "did:example:123456789abcdefghi",
      "biometricService": "https://example.com/authenticate"
      "biometricTemplateShard": "Mjk4MzQyO...5Mzg0MDI5Mwo="
    }]
  }
  

• Following are some of the key terminologies in relation with DID:
  • DID path
  • DID fragment
  • DID normalization
  • DID persistence

For details, read the W3C Community Group Draft Report on Decentralized Identifiers. Check out a related W3C Community Group draft on verifiable claims.