The purpose of this document is to aid implementers of W3C Decentralized Identifiers (DIDs) in selecting the most suitable identifier for their specific use cases. It does so by identifying and defining key traits of identifiers that have proven to be significant. Additionally, it provides a JSON schema for DID method authors, allowing them to present the characteristics of their DID methods in a structured and machine-readable format. This structured information can then be utilized by third-party systems, such as DID resolvers. This work builds on existing literature and specifications, which are detailed in the References section.
- Get approval for work item by DIF ID WG.
- Set up recurring call to advance the work item.
- Review existing works.
- Review, extend and formalize traits.
- Define JSON Schema for describing the DID Traits of a DID method.
| Trait | Description |
|---|---|
| Deactivatable | DID Documents deactivated / deleted |
| Enumerable | All DIDs of this method can be enumerated, i.e. a public registry like a DLT exists that references all existing DIDs |
| Globally resolvable | DIDs can be resolved globally, i.e. the current DID document can be resolved globally from every point as opposed to a DID that just exists in a local context |
| History available | Previous versions of DID document are available and can be looked up |
| Immutable History | Changes to DID Documents are persisted in an immutable data structure, e.g. a DLT |
| Human-readable | DID can be read and remembered by humans, e.g. did:web:example.com:me |
| Key Pre-Rotation | Cryptographic keys can be pre-rotated to combat key loss and attacks by quantum computers |
| Modifiable | DID Documents can be modified |
| Self-Certification | The initial DID Document is securely derived from the DID itself, e.g. did:key |
| Self-Creation | DID Document is generative / derived from the DID without having to access any external system, e.g. any did:key DID can be derived from the initial public key |
| Explicit Fees | Creation, modification or deletion of identifiers trigger transaction fees, e.g. blockchain-based DID methods often require transaction fees |
| Hosting | What kind of hosting is require? None, centralized, decentralized. |
- Add KERI's credential registry as a trait that enables key rotation while retaining verifiability of credentials.
- Add ID recovery mechanism as trait.
- Add multi signature support as trait, see https://github.com/w3c-ccg/verifiable-conditions.
- Review DID Enumeration work item.
- Find Hashgraph's DID comparison.
- Reach out to Google / Apple working groups and integrate their analyzes of DIDs.
- Reach out to W3C DID WG concerning their overhaul of DID Specification Registries to align on how this work item could support their work.
INFO: this table is not a deliverable of this work item. It's merely an example of how a comparison table could look like.
| Method \ Trait | Deactivatable | Enumerable | Globally resolvable | History available | Immutable History | Human-readable | Key Pre-Rotation | Modifiable | Self-Certification | Self-Creation | Explicit fees |
|---|---|---|---|---|---|---|---|---|---|---|---|
| did:tdw | x |
x |
x |
x |
x |
x |
x |
||||
| did:web | x |
x |
x |
x |
|||||||
| did:key | x |
x |
x |
||||||||
| did:jwk | x |
x |
x |
||||||||
| did:peer | x |
x |
x |
x |
|||||||
| did:dht | x |
x |
x |
x |
? |
? |
x |
? |
? |
||
| did:ion | x |
x |
x |
x |
x |
x |
? |
x |
|||
| did:webs |
| Symbol | Meaning |
|---|---|
x |
Trait applies to identifier |
? |
Unclear whether trait applies to the identifier, further information is needed |
- DID Method Rubric: A core inspiration for this work. The focus is wider, e.g.
covering privacy, resource consumption and adoption, and less focused on concrete tangible feature differences.
- Methods for Decentralized Identities: Evaluation and Insights: Application of the DID Method Rubric to selected DID methods. See page 15 for the resulting comparison matrix.
- A Taxonomy of Decentralized Identifier Methods for Practitioners: Another core inspiration. The paper puts forward a comparison matrix with lots of sub-traits per category. Important newer traits are missing.
- SpruceID Ugradeable Decentralized Identity - DID Method Traits: Proposal from 2022 to produce a list of DID Method Traits. The list wasn't create, however a number of traits are proposed in the blog post.
- OWF
- DID Enumeration
- ToIP DID Utility Comparison
Coming from the did:webs/KERI community based on this list I think we can say KERI based DID docs check:
*: did:webs is globally resolveable
did:keri by design is not
**: did:webs contains human readable URL path similar to did:web with a binding to a KERI AID that can be verified via various KERI based mechanisms based upon your security context.
did:keri (or what work on it was halfway completed) isn't human readable but other bindings to human readable identifiers can be established within the KEL or TEL (versions of KERI's keystate/ACDC{Name of KERI VC structures} state hashchain for each controller) providing a long-lived binding between arbitrary identifiers from any namespace and that AID. Mostly useful for public identifiers with long-lived AIDs. This work is theoretical though outside of a prototype my own company (vleida.net) has done internally on a "KERI DNS" prototype as far as I know.
***: did:webs is just a binding between an AID and URL. Insofar as that URL is just an arbitrary string and the AID is really what matters in the KERI verification space we can say that the did doc is self-creating.
did:keri is self-creating based upon an AID. Insofar as the hash chain has to be verified for this doc to have any meaning (unlike many of the other methods) maybe the identifier itself isn't self-creating.
However, this trait is one of the fuzziest to me in terms of how its described and which did methods are currently checked off for that trait so maybe these bindings aren't enough.
Hope this helps.