Decentralized Identifiers

In the United States, a person's identity is tied to his/her social security number. It is a unique number issued to each citizen of the country and is maintained by an independent agency of the government. One major issue is that given a social security number, one cannot prove its ownership alone, without going to the agency that issued it. Social security number is often kept private since anybody who will have access to it can easily misuse it. Decentralized Identifiers or DIDs solve this by incorporating public key cryptography to achieve verifiability. A DID is associated with a public private key pair, where the private key is kept hidden by the owner and the public key is stored in a global and persistent database, typically implemented using blockchains. Normally, DIDs and their corresponding private key are secured in a digital wallet in a mobile phone. Wallets enable you to have a lifetime secured connection to another person, organization or even a device. They also allow you to share digital credentials which are cryptographically verifiable. Decentralized Identifiers let you have a decentralized identity system with no central registration authority required.

 What does a DID look like? The format of the DID is based on a very old syntax called uniform resource name where you have a scheme, namespace and a namespace specific identifier, each of them separated by a colon: did:sov:3k9dg356wdcj5gf2k9bw8kfg7a. The scheme is "did". Then followed by a namespace called DID method. The DID method tells you which specific underlying blockchain technology is used. Last is the identifier, a random string usually created by a hash function defined by the DID method.

What is a DID Document. A DID document is a json formatted document describing the entity of a DID. There are 4 important elements of a DID Document. First is the DID itself, for self reference and self description. Whenever you want to fetch the DID Document from a DID, you can always refer the the DID inside the DID Document. Next is the public keys. This is the central element of a DID. The public keys lets you cryptographically verify the authenticity of a message sent by the owner of the DID. Then the authentication method, where it points to which public key to use to authenticate to certain services or people. Lastly, a list of service endpoints. A DID document can optionally list services that you want the DID to use to. A service can be a personal data hub, where you authenticate using the DID to prove the ownership of the data in the hub.

DID only represent the bottom layer of the identity stack. Most of the time it will be used for sharing verifiable credentials. (Show image). We typically have 3 parties involved in a decentralized identity system. We have an issuer, which issues verifiable credentials. It can be your university issuing a digital degree credential or it can be a record deparment issuing that you really are over 21 years of age. Next is the holder, or the owner of the credential. Holders store the credentials issued by Issuers in their digital wallets. Then we have the Verifier. Verifier verifies the credential shared by the Holder. A Verifier can be an Employer that wishes to verify your academic credential. It can be a Bank where it needs to verify your employment credential when you apply for a loan.

And that's how we can have an interoperable infrastructure that is completely decentralized. No central authority for the exchange of credentials. DID makes that whole think work.

Comments

Post a Comment

Popular posts from this blog

The Sidetree Protocol

Blockchain scalability is a non-trivial problem, but there is now a promising strategy for scaling blockchain-based systems known as ‘Layer 2’ protocols, or L2s, for short (example: Bitcoin’s Lightning Network). L2s achieve scalability through deterministic processing and transaction schemes that take place ‘above’ the blockchain, with zero or minimal consensus requirements beyond small points of interaction with the underlying chain. For decentralized identity to become a reality, it requires a system that operates at massive scale, while still delivering on important features, such as deterministic state resolution and differential persistence. Using blockchains for anchoring and tracking unique, non-transferable, digital entities is a useful primitive, but the current strategies for doing so suffer from severely limited transactional performance constraints. Sidetree Entities is a Layer 2 protocol for anchoring and tracking entities across blockchains. Sidetree Enities, and nod...
Read more

On the IoT Exchange - DID integration

One of the challenges of introducing Decentralized Identifiers (DID) into Internet of Things (IoT) is the proprietary nature of the IoT ecosystem. Most IoT devices use proprietary technology. The ideal way of integrating DIDs is to put the keys and some cryptographic operations directly into the device. The assumption here is (1.) the manufacturer themselves can either generate and embed the keys from a secure or "offline" environment or (2.) manufacturer can embed cryptographic logic into the device and the device would generate the keys themselves, given that the device has enough power to execute the operations. If we are going create a service from DIDs and we do not have any access to the device manufacturing process, we may need to generate and maintain the keys elsewhere, but we need to make sure the pathway from that "elsewhere" to the device is _secure_, and how that secured pathway is implemented is *out* of the scope of this post. That "elsewher...
Read more

Smartkey Overview

Whenever we write applications, we need to keep our _secrets_ in a single central secure place. These secrets can be your password to your database, your api key, or your cryptographic keys used for signing messages. There are two major reasons why we want to do this. The first one is we want these secrets to be fetched by multiple instances of the application from a single place, instead of duplicating or hardcoding them in the application. This secure place may be a keystore stored in a directory in a file server, but making it reachable across different environments, specially when dealing with software development in the cloud, ultimately becomes a challenge. Nowadays, this is implemented as a service, where it expose endpoints easily accessible to applications for fetching the secrets themselves. Aside from key access, these type of services often offer key management solutions such as key rotation and key revocation. These solutions are sometimes referred as key management servi...
Read more