An introduction to Decentralized Identity

- 13 min read - Text Only

I attended a presentation at Crypto and Privacy village about Decentralized Identity, its goals, and current weaknesses. We cover verifiable credentials, where information is signed by an issuer, held by a person or thing with identity, and given to verifiers which can trust that verifier. Governments are interested in decentralized identities. I feel that without deep government support, decentralized identities will not succeed. Lastly, we cover mitigations, such as a smart agent. It is like a smart wallet, but more general. We have a long way to go before this technology is ready for the everyday person.

This talk summary is part of my DEF CON 31 series. The talks this year have sufficient depth to be shared independently and are separated for easier consumption.


There's this DID thing that's been growing over the last 6 years. Blusky in particular exposed many more to DID. Those wishing for a vanity domain handle will find out what a DID is as they claim their personal handle.

Xe at xeiaso.net with a vanity url on blusky

shinji-cup
I have a Bluesky account now that Jack Dorsey left (archived.) Not that I'm very active... You can find me on @cendyne.dev.

Xe's DID URI is found with a DNS text record.

dig +short TXT _atproto.xeiaso.net
"did=did:plc:e5nncb3dr5thdkjir5cfaqfe"

This DID URI may then be resolved with a particular directory at https://plc.directory/did:plc:e5nncb3dr5thdkjir5cfaqfe.

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/secp256k1-2019/v1"
  ],
  "id": "did:plc:e5nncb3dr5thdkjir5cfaqfe",
  "alsoKnownAs": [
    "at://xeiaso.net"
  ],
  "verificationMethod": [
    {
      "id": "#atproto",
      "type": "EcdsaSecp256k1VerificationKey2019",
      "controller": "did:plc:e5nncb3dr5thdkjir5cfaqfe",
      "publicKeyMultibase": "zQYEBzXeuTM9UR3rfvNag6L3RNAs5pQZyYPsomTsgQhsxLdEgCrPTLgFna8yqCnxPpNT7DBk6Ym3dgPKNu86vt9GR"
    }
  ],
  "service": [
    {
      "id": "#atproto_pds",
      "type": "AtprotoPersonalDataServer",
      "serviceEndpoint": "https://bsky.social"
    }
  ]
}

The directory responds with a document which includes a public key. That public key may then be used to verify assertions later by the private key holder, in this case: Xe.

thats-me
You can see mine on the directory as well. Here's instructions on how to set your domain as your handle on Bluesky.
you-are-the-entire-circus
That said, it references a public key which I do not have the private key for. I think anyone going through the guide above and the main website will never get the private key. Maybe there are hints in the did:plc Method Specification.

My knowledge coming in

Before DEF CON, I watched a presentation from the W3C working group and Self-Sovereign Identity meetup. It made me sleepy and I barely got anything out of it. I hoped this presentation would give me a foundation for understanding what a DID is and what it is intended for — it did.

Gabe Cohen and Brent Zundel introduce Decentralized Identities (DID) and cover known weaknesses and ways to improve. Brent is involved with verifiable credentials and DID's at the W3C and several privacy-focused standards efforts at the IETF. Brent hosts an ask me anything with the decentralized identity foundation, you can learn more of his contributions in that video. Gabe works on web5 (whatever that is) at TBD, which is building decentralized technology for self-sovereign-identity.

The presentation

Title slide for Attacking Decentralized Identity by Gabe Cohen and Brent Zundel

The presenter introduces Decentralized Identifiers (DIDs) as Uniform Resource Identifiers (URIs) which associate a DID document with a subject. This document permits verifiable interactions with that subject.

W3C verifiable Credentials (VCs) A verifiable credential is a w3c standard mechanism of expressing claims about an individual on the web in a way that is cryptographically secure, privacy respecting, and machine verifiable.
Claims can include the same claims in traditional credentials such as passports or licenses.

This document is not embedded or always adjacent to the DID. Rather, the DID provides a path way to resolve the document for further interactions.

Much of the interest behind DIDs has been either governments — such as the U.S. Department of Homeland Security — or crypto-currency projects. Both sources of interest matched with what I learned next.

A major goal of DIDs are to minimize the need to share private information and to collect verifiable information from issuers together. My occasional deep dives into OpenID Connect and reading the ongoing work to standardize selective disclosure with JWTs at the IETF echoed loudly at that moment. Well, it turns out, Brent is involved with what I have already read.

Actors in decentralized identity systems. Issuer. The issuing entity of a verifiable credential (VC). Holder. The entity controlling the VC. Verifier. The entity to which a VC is presented to prove a claim or set of claims.

An ecosystem of decentralized interactions. Depicted is a person and an identity with objects like credit cards, nationality, passport, employment, licenses, deiploma, etc. connected to the holder.

Other goals mentioned were: DIDs are independent and can be self-sovereign forms of identity; DID owners can control their IDs and access all data their DID is tied to; DIDs are interoperable, transparent, and verifiable; the rights of the DID owner are respected; and finally that DIDs provide a way to verify once and be trusted globally — where today personal information has to be verified at every point of data entry.

Attack number 4. did:jwk is self resolving but has no updates or compromise signal method. did:web depends on domains and supports updates, relies on TLS certs and other infra for the web. There's no historical resolution. did:ion runs on top of complex distributed architecture.

There are several mechanisms that a DID and its verifiable methods are delivered. Some DIDs are self identifying, that is: the cryptographic public key is the DID. However, as DIDs are long-lived, there is no mechanism for a DID to assert that the private key has been compromised and assertions going forward are untrustworthy.

Huh, don't PGP key-whatevers have a poison pill or something?
peek
point-right
They do, it is called a (warning HTTP only) PGP Key Revocation Certificate (archived.)

The presenter then shares how some services may ask for too much data, such as the full details on a drivers license, when the business purpose is a mere age check. And that these services may censor and exclude individuals for choosing not to share their complete details.

snake-shrug
I really felt like "the water is wet" with this one. It already happens.

Another interesting bit: the People's Republic of China made their own DID method, where — of course — China's government controls the key material and not the owner of the DID. China is the owner of all the data, not the individual.

At the end was some sort of dreaming. A thing called "smart agents," which are like "smart wallets" but focused more on personal information and the sharing and maintenance of that information, rather than holding speculative-monetary cryptographic key material.

Mitigation number 1: smart agents. Like a smart wallet. Privacy first stance. Trust starts somewhere, there has to be some centralized registries. What agents are trusted? Where is personal data stored centrally?

At the very end: "Not your DID, not your data."

Final thoughts

Overall, I feel a lot more caught up on the high level theory of this technology. I can't say that it excites me yet. The whole verifiable personal information parts need government support and it feels too packed with libertarian energy. I am concerned about the level of competency people have to develop to use technology like this and its accessibility, and the populations of people that will be left behind if they do not or cannot.

bite-computer
By "libertarian energy", I mean that its construction is exclusionary to entire populations of people; while supporters of such constructions blame individuals that are excluded for not being smart or capable or responsible enough.

I have a hard time taking anything past "web2" as a label seriously.

That is not to discredit the work going into Decentralized Identities. A lot more work has to go into it. For now, the branding and advertisement of "web5" being accessible and democratic and so on is not aligned with reality.

Xe's Addendum

I managed to talk with Brent without realizing it after his talk and when he asked what I thought about it, I complained that it felt like thinly veiled cryptocurrency stuff and lamented the association with blockchain stuff. He sighed and admitted who he was, making me feel kinda terrible but talked with him about it. The dude is passionate and committed to making this tech work, but I just don't really know how this will pan out in the long term.
coffee

I mentioned that it's a bad look that most of the identity verification methods in the spec are cryptocurrency projects and he replied that it's still very early in the process and that realistically people are going to align to one to three successful methods. In order for there to be a successful method we're gonna have to experiment with things to see what sticks, thus it's actually fairly healthy to have all of those options out there.

If this is handled right, it could be something great for everyone because honestly the approach of "just trust Google lol" only works well until and unless Google's algorithms decide that you get to suffer. If that happens to most people (likely including me), they're just screwed. I don't really know what the best way to handle this is. I wish there was really a better option, but I suspect that the "traditional" system of physical and digital identity documentation being separate will be here to stay for a long time.

More on Xe Iaso's experience may be read at I had a great time at DEF CON 31.