Full Title or Meme
Jolocom team] Current status of did:keri, and adding it as a work item to the ID WG. Information and contextual documents: https://hackmd.io/@RYgJMHAGSlaLMaQzwYjvsQ/ByAYibtdF Current did:keri method specification: https://identity.foundation/keri/did_methods/ Quick intro to KERI KERI defines a number of events (e.g. inception, rotation, delegated inception, etc.), and also data structures and rules for processing them. Processing events leads to the current state of the identifier. There are different types of identifiers, and different ways how events can get exchanged, e.g. ephemeral mode, exchange with counterparty (direct mode), exchange via witnesses (indirect mode). The controller can select what witnesses they like, witnesses can also be rotated. This adds an abstraction layer, witnesses can be anything (ledger, or personal server, etc.) Current status of did:keri
- Previously there was did:un, some features were not yet supported. Jolocom had an implementation of direct mode, the intention was to use it on mobile wallets.
Then the intention was to switch from did:un to a more robust implementation of did:keri, using some good learnings from the initial experimentation work.
- Some work is split across different environments, so besides a documentation effort there also needs to be some alignment.
The goal is to continue and further expand the work on the DID method specification, to figure out how all the KERI building blocks can be utilized together in a method spec. In the future, the roadmap also includes globally resolvable (anywise) identifiers. Some questions are still open, e.g.: How is a did:keri globally resolvable? How do I know what are the witnesses? How exactly do you contact the witness? How are different key purposes mapped to a key event log? How can additional metadata be associated with a DID?