It’s a Good Time to Understand Decentralized IDs

Strong, verified, secure identities and authentication of those identities are essential for digital security. We even give the process of getting, storing, using, and deleting IDs its own major classification name in computer security – identity management or IdM.

We all know the strengths and weaknesses of password-based digital IDs and we all have many dozens to hundreds of login names and passwords we use on various sites and services. Most of us also have multiple different types of digital identities secured by various forms of multifactor authentication. IDs are also secured by digital certificates, device IDs, and really any other method of authentication that someone can think of.

Digital IDs are used for more than just securing how users log in. Digital IDs are used to allow computers, devices, applications, services, trust relationships, networks, and many other digital things to authenticate themselves to each other and other sites and services. If you’re going to be a good cybersecurity defender, you need to understand the IdM lifecycle process, from the creation of an ID (officially known as provisioning) to its deletion (officially known as deprovisioning).

Anyone can claim to be anyone. In systems where it matters who is who, in at least as far as keeping people separated and prevented from using each other’s IDs and claiming to be the owner of a particular ID, these IDs need to be unique within the relevant namespace (e.g., DNS, Active Directory, etc.), verified as belonging to a particular user who “owns” and uses it, and subject to proof of ownership (authentication) when used to log in to a particular site or service. Thus there can be only one roger@banneretcs.com or rogerg@knowbe4.com Internet email address, and they need to be password or multifactor authentication protected so other people can’t use them to do unauthorized things.

How IDs are created, verified, and authenticated is the subject of IdM. It would take thousands and thousands of pages to cover all the different types of IDs, and how they are verified and authenticated. It would probably greatly help the world if there was a common standard or at least a common taxonomy around IDs.

To that end, the World Wide Web Consortium (W3C), which is the group that is creating many of the Internet’s defacto standards these days, released a W3C recommendation document called Verifiable Credentials Data Model (https://www.w3.org/TR/vc-data-model/). ?W3C recommendation documents are essentially the new or proposed new Internet standards (from W3C). They are similar to Request for Comments (RFCs). RFCs (https://en.wikipedia.org/wiki/Request_for_Comments) are the Internet standards emanating from the Internet Engineering Task Force (IETF), which for most of the Internet’s early existence was the one body that could be considered in charge of Internet standards. W3C seems to have taken on a greater role in Internet standards these days, at least as they apply to web-based sites and services. The W3C is also very interested in formalizing how IDs are represented in code (e.g., JavaScript, JSON, etc.) so that the whole IdM life cycle process can be automated and made as smoothly as possible between different sites and services.

The IdM life cycle can be represented many different ways, using many different terms, and different processes. Here is the IdM lifecycle process as presented in the W3C’s Verifiable Credentials Data Model document, section 5.1.

This is perhaps as simple as it gets. You have an issuer (who controls and maintains the ID). You have the holder/user of the ID (e.g., users, computers, etc.). You have verifiers which are sites and services which verify or authenticate the ID, and you have a trusted registry, which is where the ID’s information is stored so that it can be verified if needed.

Here’s another representation of the same IdM lifecycle, using different names and processes (from my book, Hacking Multifactor Authentication (https://www.amazon.com/Hacking-Multifactor-Authentication-Roger-Grimes/dp/1119650798)):

There are even far more complicated IdM models, but they all basically have entities that issue and control the IDs, people and things that use them, and sites and services where they are used to gain access to who need to verify them. ?Each of the components is integral to the process of digital identities. All reliers must trust each of the components and trust that each part is doing their job well, securely, and without significant errors or fraud.

Identity Control

One of the core concepts to understand is centralized versus decentralized IDs.

Centralized IDs

Most IDs that most of us use are known as centralized IDs, meaning that someone, something, or some organization other than ourselves “owns”, controls, and manages, the ID’s lifecycle. For example, you join a website and as part of that process, you must create a new login ID and password. You may feel that it’s “your” login ID, but the site or service you created it on completely controls it.

If the ID is something you can use across multiple, otherwise unrelated sites and services, it is known as a federated ID. For example, you can often use your Gmail, Facebook, Twitter, Apple ID, etc., login to access many different participating sites. Sites and services accepting federated IDs have been coded to accept and use the federated IDs, and when the user logins using one, the site or service involves the ultimate controlling federated IdM service in the authentication process to their local site or service.

Sadly, many people learn centralized IDs are not really theirs the hard way when the controlling authority suddenly and unilaterally decides to disable the ID so the user can no longer use it. Or a hacker steals it. My email inbox is constantly full of people asking me how they can recover their stolen ID so they can again access their social media accounts, messages, and pictures. Unfortunately, in many cases, the “legitimate” owners of the account (really just the legitimate users of the account) are never able to regain control and any content they had in that account is now no longer accessible to them. It can be quite frustrating to lose everything associated with a beloved or needed account because of some other person or organization’s actions or decision, and the user, who felt like they were the “owner” of that account, can no longer access or use it. For these types of control issues, plus reasons of self-determination and privacy, many people prefer to use decentralized IDs, whenever possible or at least when they desire and can use them.

Decentralized Identifiers

Decentralized IDs or Decentralized Identifiers (DIDs) are “owned”, managed, stored, and controlled by the user. To cut to the point, self-control can be both good and bad and should be of great concern to cybersecurity practitioners.

DIDs have been around in various forms for decades. There has been a multitude of previous DID attempts which tried to become worldwide open standards. The most recent one that had widespread support as OpenID (https://en.wikipedia.org/wiki/OpenID), where decentralized, federated IDs, could be selected by users and used at participating websites. Microsoft had its own federated implementation known as InfoCards or CardSpace (https://en.wikipedia.org/wiki/Windows_CardSpace), but it never gained wide support, even among Microsoft Windows users. It was discontinued in 2011.

Many users have mistrust and privacy concerns of any federated identity issued and controlled by a commercial company, as such, have been looking for a DID open standard that is supported by much of the world. To that end, under the WC3’s Verifiable Credentials Data Model recommendation, another group has created the Decentralized Identifiers (DIDs) (https://www.w3.org/TR/2022/REC-did-core-20220719/) recommendation. And I love it. If you want to up your game in becoming a IdM expert it cannot hurt to review both of these long, related documents. Great stuff in each. Each is well-written.

It explains what DIDs are, how they can be used and gives a framework to developers for creating and using open standard DIDs. It’s well thought-out.

Each DID can be programmatically referenced (remember W3C is mostly about programming) by a single string of characters that point (using a valid URI) to an underlying DID document, which contains the necessary information as determined by the DID holder or their appointed controller.

For example:

???????????????did:example:https://www.example.com/dids/1234rogerg

Anyone looking for that specific document will find a file contain the related DID information, which also always contains a string with did: in it (for consistency). That DID document can contain lots of information, including the user’s real name, a pseudo-anonymous identifier, a public key, or other associated information about the DID. Here’s an example DID document from the W3C DID document:

{

?"@context": [

???"https://www.w3.org/ns/did/v1",

???"https://w3id.org/security/suites/ed25519-2020/v1"

?]

?"id": "did:example:123456789abcdefghi",

?"authentication": [{

???// used to authenticate as did:...fghi

???"id": "did:example:123456789abcdefghi#keys-1",

???"type": "Ed25519VerificationKey2020",

???"controller": "did:example:123456789abcdefghi",

???"publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"

?}]

}

In this case, the DID document is including the public key of the DID, but many other types of information can be contained in the document, depending on the needs of the user or controller.

Here’s the basic IdM pathway summary for DIDs taken from the same W3C document:

It’s very important to note that the DID may actually not be decentralized, and I suspect this is often going to be the case (and this is not a bad thing). The controller is the entity that controls, operates, or otherwise manages the DID (ID and DID document) for the subject/user (or whatever else the “user” is, be it a device, software, service, etc.). The controller can be a person, device, software, or any other entity that can manage DIDs. And subjects can have as many DIDs as they like, defined and configured how they like, and controlled by themselves or whoever they like. The DID standard is really quite flexible.

I think it’s quite realistic for many subjects to turn over the handling of their DIDs to third-party controllers who can far better maintain and protect them over their lifecycles. My biggest fear around DIDs is that most of them are maintained by individual users on their individual devices, most of whom do not maintain their own cybersecurity nearly as well as the average ID controller today. If most DID users maintain their own DIDs, it’s my best guess is most of them will end up under the control of malicious actors. By placing the DIDs in the hands of a more secure, better protected, and trusted controller, most users would likely end up with better protected DIDs and suffer less compromise. Of course, I’m neglecting that trusted controllers get compromised all the time…and when they do the adversaries walk away with every held ID they have. But in general, entities dedicated to being secure controllers are likely to have better security than the average DID user has on their own devices. But it’s a risk decision every DID user needs to make, and it can be different per DID. The user can maintain some of their own DIDs and let other controllers manage others.

It is also possible for DID users or controllers to revoke compromised DIDs. But in order for the revocation process to work, verifiers will need to check a trusted verifiable data registry to see if the DID has been revoked or not. I think whether or not a particular DID uses a data registry that allows revocation, we are going to eventually see billions of compromised DIDs used in the world that are not revoked for various reasons. These reasons can include:

·????????User isn’t aware it was compromised

·????????User didn’t use or configure a DID that used a verifiable data registry or a registry that allows revocation

·????????Verifiable registry is no longer functioning

·????????Site or service relying on DID does not check revocation

?Regardless of the reason, we will definitely see all sorts of rogue DIDs out there. It’s coming.

Section 9 of the W3C’s DID document (https://www.w3.org/TR/2022/REC-did-core-20220719/#security-considerations) is nice section about DID security considerations. The team that created the DID document/standard did a decent job of threat modeling (they miss a few things), and it’s a good section for anyone to read.

Expect more DIDs in your future. In fact, Microsoft announced (https://techcommunity.microsoft.com/t5/identity-standards-blog/ion-we-have-liftoff/ba-p/1441555) their first version of a Microsoft DID, called Ion, in March 2021. For good or bad…and I think mostly bad…Microsoft decide to use the bitcoin “mainnet” blockchain as their recording mechanism. Microsoft is full of brilliant people, but why they choose an already overworked blockchain for their database is beyond me. Bitcoin blockchain is huge already and getting huger all the time and that’s before Microsoft potentially put billions of Ion DID transactions on it. It’s already too large and too slow. But it’s what Microsoft did and I’m sure they did it fairly eloquently, with parts that tie it directly to the Microsoft ecosystem.

Either way, if you’re in cybersecurity and want to be one of the best cybersecurity practitioners, you need to always educate yourself on the latest trends and newest technologies. You can’t hurt your future chances of employment and salary earning by reading both of these related W3C documents on identities:

·????????Verifiable Credentials Data Model (https://www.w3.org/TR/vc-data-model/)

·????????Decentralized Identifiers (DIDs) (https://www.w3.org/TR/2022/REC-did-core-20220719/)

You’ll be smarter in IdM and be better prepared for the future, as DIDs are likely to be a huge part of the future.