Skip to content

Instantly share code, notes, and snippets.

@jceb
Last active September 2, 2024 11:56
Show Gist options
  • Save jceb/8e37e4900e815eb14b207ad7e8d02a6c to your computer and use it in GitHub Desktop.
Save jceb/8e37e4900e815eb14b207ad7e8d02a6c to your computer and use it in GitHub Desktop.

DID Traits

Source

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.

Next Steps

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

Contents

  1. Traits
  2. Traits by Identifier
    1. Legend
  3. Task Backlog
  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
Hosting What kind of hosting is require? None, centralized, decentralized.

Task Backlog

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

Traits by Identifier

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

Legend

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

References

@daidoji
Copy link

daidoji commented Jun 25, 2024

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.

@jceb
Copy link
Author

jceb commented Jul 1, 2024

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

@bumblefudge
Copy link

this is so great!

@fabianekc
Copy link

great initiative and happy to contribute!

some suggestions for possible further traits:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment