Decentralized Identifiers: Putting You in Charge of Your Identity

Most of the discussion about identity in the media and on the internet recently has been quite negative, focusing on violations of your privacy and the misuse of personal information tied to your identity. On more than one occasion, we have seen an identity management database compromised, which allows the identity details for millions of users to be obtained by darknet participants or state-sponsored cyberhackers. As authentication—the process of establishing the identity of a person, device or service behind an access request—is a critical step in granting access to an internet service, identity management cannot be avoided.  Unlike the pre-internet days, where you physically walked into your local bank with your savings deposit account book, today nobody knows whether your access request over the internet is coming from you or a sensor device on a traffic light in downtown Manhattan.

OpenID identity management

Online identity today typically involves siloed databases restricted to a single online service provider who may or may not maintain proper security practices. As a user, you must establish separate credentials, (i.e., username and password) with every internet service you sign up with and commit those credentials to memory. Recently, the spread of services that support the OpenID Connect protocol has somewhat simplified identity management. In this scenario, a web service includes links to a collection of OpenID providers—for example a web service where you have an email account—on its login page. This is usually in addition to the option of authenticating with an identity management system provided by the web service itself. If you click through to an OpenID identity provider, rather than authenticating directly with the web service, you use your username/password credentials siloed with that OpenID provider to authenticate, so you must only remember passwords for the OpenID providers where you have an account.

Some OpenID providers allow web services to obtain more information than just attesting to the user’s identity—for example, a list of the user’s email contacts. The OpenID provider brings up a prompt window in the browser requesting the user to authorize the release of the information. However, if the user declines to authorize the release, then the service provider has the option of declining the authentication. OpenID identity management has not removed the fundamental problem, namely that your identity information is still siloed among service providers, who may maintain other information about you beyond what is required to authenticate your identity. While you have somewhat more control over how that information is doled out, the service provider accepting the OpenID authentication still has the option of asking for inappropriate information instead of just a simple yes/no identity attestation.

Asymmetric key authentication  

Asymmetric (public/private) keys provide a much better way to establish identity. They are the foundation of secure webpages based on the HTTPS protocol. However, in addition to a public/private key pair, you need a certificate—a digital document proving your identity—and a public key infrastructure (PKI) to attest to the validity of your certificate. A PKI consists of a hierarchically linked set of trusted certificate authorities (CAs), each of which countersigns a certificate containing the public key for the CA at the level below it, attesting to the identity of that CA. The last document in the chain is your public key certificate. It contains your public key and some attestations about your identity in which the CA that issues your certificate countersigns. The CAs constitute a chain of trust, allowing recipients of the certificate to have confidence in your claimed identity. Together with your certificate, your ability to participate in a public key authentication exchange, in effect, proves your identity.

PKI has been used for years by websites via the HTTPS protocol and is the trust foundation on which e-commerce was able to take root and flourish. Websites running HTTPS purchase a certificate from a CA and present it when challenged by a browser wanting to connect to the site. PKI is not foolproof, however, as there have been cases of black hat hackers obtaining legitimate certificates and misusing them. But by and large, PKI has served the purpose for which it was introduced, namely allowing the user of a browser to have confidence that they can trust the connection their browser has with a website. In fact, many browsers have within the last year started to issue security warnings about sites that only use the HTTP protocol and do not use HTTPS.

Managing public key certificates

While adoption has been positive for authenticating web sites using PKI, almost no websites use PKI for identifying individuals due to the complexity and resources required to administer a PKI. Setting up and administering a PKI is a challenging job even for an experienced security administrator, let alone individual users who don’t have access to the resources of an enterprise IT organization. Different operating systems and browsers handle certificates in different ways. Certificates occasionally expire, and unless they are renewed before they expire, havoc can ensue—for example, see what happened when a Firefox release went out with an . Certificates can also be invalidated before expiration—for example, when the individual loses their private key or the private key is compromised. If an invalidating event occurs for a certificate assigned to an individual, the individual must notify the issuing CA to have the certificate invalidated, and must purchase a new one.  The CA then puts the invalidated certificate onto a certificate revocation list (CRL).

Browsers using HTTPS today check the CRL to ensure a website’s certificate is still valid, a time-consuming operation because typically the entire CRL must be downloaded or otherwise consulted. Since a PKI-based identity system would need to certify the identity of exponentially more individual user certificates than for websites, checking a CRL for an individual user would be even more time-consuming. In addition, public key certificates can only contain a few high-level details about identity and therefore don’t solve the problem of giving you control over selectively releasing fine-grained information about yourself.

Decentralized identifiers

An interoperable identity management system for the web needs to go beyond the basic authentication service for logging into websites and extend to the notification and approval process for various aspects of an individual’s profile. Ideally identity management would provide a way for you to be notified via a mobile app when an entity (company or person) wanted specific information or an attested proof of your personal details, such as your home address, email contacts, or even something as sensitive as your credit or medical history. The identity of the inquiring party would be authoritatively established to provide you with confidence in the validity of the query. Then you could selectively authorize whether or not the inquiring party could obtain that information.

This kind of service corresponds in the non-digital world to showing your driver’s license to prove your age when you enter a bar, your passport to prove your national identity when you pass through the U.S. Immigration and Naturalization Service at the airport after returning from a foreign trip, or your medical insurance card to prove your right to obtain medical service when you go to the doctor. An identity service with strong enough security guarantees may ultimately replace these offline sources of identity proof, radically simplifying the ability of individuals to provide provable claims about themselves. In other words, you would be in control of your digital identity.

Decentralized Identifiers (DIDs), also sometimes called self-sovereign identifiers, provide one solution to the problem. Based on the decentralized web of trust implemented using blockchain technology, DIDs are a new URL scheme that lets you register a DID document. The DID document contains a public key for authentication and links to other services pointing to locations that contain personal information about you. For example, one link could point to your mobile phone for your home address and telephone number, another could point to a university identity hub for an encrypted record describing your university degree and course of study, while another could point to a credential maintained by your state of residence attesting to your age. These documents are called verifiable credentials because, just like a driver’s license or a university diploma in the offline world, verifiable credentials allow you to make verifiable claims about your identity to trusted parties. As shown in Figure 1, when you want to know something about another person, such as whether a teacher you are interested in has a credential to teach a yoga course, then you can use your DID to look up the credential, but you first must get the teacher’s permission to decrypt it. Once that person receives a mobile notification, then he/she will have the option of accepting or declining the request. In this way, each person is in control of what information is released.

Figure 1: Using DIDs to look up the verifiable credentials of a yoga teacher

The Decentralized Identity Foundation (DIF) has been working to develop the underlying core technologies for establishing DIDs and ensuring interoperability between participants in the DID ecosystem. Their work includes technical specifications, reference implementations and coordination among companies to align along common interests and advance the deployment and use of DIDs. Equinix joined DIF in 2017, to make self-sovereign identity the path of the future for allowing individuals to control their digital identity online, which is consistent with our overall goal of maintaining an open, neutral internet.

Recently we’ve deployed a prototype for interoperability testing of Microsoft’s SideTree/ION protocol, which supports the did:ion DID method, along with a Universal Resolver that will resolve any DID method. On Monday, Microsoft announced an open source prerelease of ION (Identity Overlay Network) in Azure, running on the Bitcoin testnet. Microsoft plans to continue developing the protocol with a goal of releasing it on the Bitcoin mainnet sometime this summer.

The Equinix SmartKey™ key management service provides the complement to DIDs, as a safe place where you can store your authentication private key. In the coming months, I’ll be posting additional details about the architecture of DID networks and different DID schemes. I’ll also provide updates on our progress toward deploying DIDs, applications of DIDs, and how we’re working together with DIF to help move decentralized identity management forward so that you have control over who gets to see what information about you on the internet.

Learn more about Equinix SmartKey.

 

 

Print Friendly


Related Content