An introduction to Decentralized Identity Fri Aug 25 2023 An introduction to decentralized identities, known risks and weaknesses, and future mitigations. A presentation by Gabe Cohen and Brent Zundel. -------------------------------------------------------------------------------- An introduction to Decentralized Identity ========================================= Published Aug 25, 2023 - 13 min read /------------- Table of contents -------------\ | Table of contents | | * An introduction to Decentralized Identity | | * My knowledge coming in | | * The presentation | | * Final thoughts | | * Xe's Addendum | \---------------------------------------------/ 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. [I1: Xe at xeiaso.net with a vanity url on blusky] /[cendyne: bullshit2]----------------------------------------------------------\ | No, I am not on Blusky [L1] at this time. I am not interested in | | contributing to a service with a literal racism dial. I am not suggesting | | that those who do have an account also endorse Blusky's moderation approach. | \------------------------------------------------------------------------------/ 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 [L2]. { "@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": "zQYEBzXeuTM9UR3rfvNag6L3RNAs5pQZyYPsomTsgQhsxLdEgCrPTLgFna8yqCnxPpNT7DBk6Ym3dgP KNu86vt9GR" } ], "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. My knowledge coming in ---------------------- Before DEF CON, I watched a presentation from the W3C working group [L3] and Self-Sovereign Identity meetup [L4]. 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 [L5] and Brent Zundel [L6] 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 [L7] with the decentralized identity foundation, you can learn more of his contributions in that video. Gabe works on web5 (whatever that is) at TBD [L8], which is building decentralized technology for self-sovereign-identity [L9]. The presentation ---------------- [I2: 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. [I3: 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 [L10] with JWTs at the IETF echoed loudly at that moment. Well, it turns out, Brent is involved with what I have already read. [I4: 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.] [I5: 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. [I6: 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. /---------------------------------------------------------------[cordite: peek]\ | Huh, don't PGP key-whatevers have a poison pill or something? | \------------------------------------------------------------------------------/ /[jacobi: point-right]---------------------------------------------------------\ | They do, it is called a (warning HTTP only) PGP Key Revocation Certificate | | [L11] (archived [L12].) | \------------------------------------------------------------------------------/ 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. /[cendyne: 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. [I7: 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. /[cendyne: 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. /------------------------------------------------------------------------------\ | Snoop Dogg @SnoopDogg@twitter.com | |------------------------------------------------------------------------------| | Working on Web6. | | [L13] 6/10/2022 | \------------------------------------------------------------------------------/ /------------------------------------------------------------------------------\ | Snoop Dogg @SnoopDogg@twitter.com | |------------------------------------------------------------------------------| | U can smell it. | | [L14] 6/10/2022 | \------------------------------------------------------------------------------/ 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. /-------------------------------[cadey: 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 [L15]. -------------------------------------------------------------------------------- JSON Web Token (JWT): JSON Web Tokens (see RFC7519 [L16]) are used to sign a standard set of claims and additional claims or metadata. JWTs are often used as bearer tokens and may be signed with an asymmetric algorithm like RSA, ECDSA, or EdDSA. They may also be tagged with a symmetric algorithm such as HMAC with SHA-256 or another suitable digest function. Within the standard set of claims is: * exp: "expiration" - when a token expires in Unix seconds, and should not be accepted after this date and time. * iat: "issued at time" - when a token is issued in Unix seconds. * nbf: "not before time" - when a token should begin being accepted in Unix seconds. * iss: "issuer" - which entity issued this token. * aud: "audience" - which entity this token is intended for. * jti: "JWT ID" - a unique identifier by the issuer, no other tokens are issued with the same identifier within this token's issued and expiration time-span. This is often used for revocation or replay prevention. A JWT is a JWS where the JWS payload is a JSON object of the claims. Internet Engineering Task Force (IETF): The IETF is a standards organization for the internet composed of volunteers. IETF working groups collaborate to produce RFCs that standardize internet technologies. Hash based Message Authentication Code (HMAC): An HMAC is a MAC which uses hashes or message digests to authenticate a message. It is resistant to length extension attacks, which the underlying hash function may be susceptible to. You will find that common instatiations of HMAC are also PRFs. [L1]: https://en.wikipedia.org/wiki/Bluesky_Social [L2]: https://plc.directory/did:plc:e5nncb3dr5thdkjir5cfaqfe [L3]: https://www.youtube.com/watch?v=t8lMCmjPKq4 [L4]: https://www.youtube.com/watch?v=SHuRRaOBMz4 [L5]: https://decentralgabe.xyz/ [L6]: https://www.linkedin.com/in/bzundel/ [L7]: https://www.youtube.com/watch?v=RRfBlYT9mgs [L8]: https://www.tbd.website/about [L9]: https://en.wikipedia.org/wiki/Self-sovereign_identity [L10]: https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt -05.html [L11]: http://www.spywarewarrior.com/uiuc/ss/revoke/pgp-revoke.htm [L12]: https://archive.is/RL0dO [L13]: https://twitter.com/SnoopDogg/status/1535386263041155106 [L14]: https://twitter.com/SnoopDogg/status/1535388285568024577 [L15]: https://xeiaso.net/blog/dc31 [L16]: https://tools.ietf.org/html/rfc7519 [I1]: https://c.cdyn.dev/yo8qp1XS [I2]: https://c.cdyn.dev/-TcpD155 [I3]: https://c.cdyn.dev/psVcoP5I [I4]: https://c.cdyn.dev/x9MTC9fA [I5]: https://c.cdyn.dev/_7bQ1Oxs [I6]: https://c.cdyn.dev/Yhe01wQ_ [I7]: https://c.cdyn.dev/fxQGSwfs