README.md

Identifier Traits

Source

The goal of this document is to help implementers of W3C Decentralized Identifiers and other identitfiers compare and pick the right identifier for their use case. We identify traits of identifiers that have emerged to be relevant and apply them to a selection of DID methods and other identifiers. This work builds upon existing works listed in the References section. If a relevant DID method or identifiers is missing or a trait is misattributed, please contribute your observations.

Contents

1. Traits
2. Traits by DID Method
   1. Legend
3. Open Tasks
4. References

Traits

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

Traits by Identifier

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
KERI

Legend

Symbol	Meaning
x	Trait applies to identifier
?	Unclear whether trait applies to the identifier, further information is needed

Open Tasks

• 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.
• Maybe: turn table into a machine-readable format to support various use cases, e.g. to require new DID methods to assess their traits.

References

• 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.

Coming from the did:webs/KERI community based on this list I think we can say KERI based DID docs check:

• [Deactivatable]
• [Enumerable]
• [Globally resolvable]*
• [History available]
• [Immutable History]
• [Human-readable]**
• [Key Pre-Rotation]
• [Modifiable]
• [Self-Certification]
• [Self-Creation]***
• [Explicit fees]

*: 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.

Thank you, we'll start updating the document soon :-)