# ID-WG 22.11.21

Some contextual documents:
- Brief presentation on [`did:un`](https://jolocom.io/de/blog/as-seen-at-iiw31-keri/). A related (prior) effort at Jolocom.
- KERI [white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf).
- [KERI Improvement Documents](https://github.com/decentralized-identity/keri/tree/master/kids).

The main goal of this effort is to resume work on the current [did:keri](https://identity.foundation/keri/did_methods/) DID method specification. The intention is to expand the specification and provide further, more detailed guidance, on how relevant KERI concepts (event types, KEL, etc.) can be used as a basis for a DID method.

We would like to maintaine the following features / advantages from KERI:
- The developed DID method should enable both identifiers which are only resolvable as part of a specific interaction, as well as globally resolvable identifiers.
- End users should be able to easily create (as well as update) a new KERI based DID (locally), and only disclose it (including the associated events) as part of their interactions with a specific service (maps to KERI direct mode).
- An identifier associated with an organisation (e.g. an issuer) might need to be universally resolvable by any network participant. KERI enables this via the usage of controller-designated [witnesses](https://github.com/decentralized-identity/keri/blob/master/kids/kid0009.md).
- In case globally resolvable identifiers are employed, the underlying availability mechanism (selected witness implementation) should be configurble.

One initial area of work which can help uncover and prioritize further areas of improvement could be expanding on, and further aligning the following sections of the DID Method document with the KERI specification:

- create
- Elaboration on the supported identifier types (e.g. Basic, Self-Addressing), as well as the associated propierties / restrictions / use cases. (including example events / identifiers / Did Documents).
- Further elaboration on how incepting identifiers with multiple associated keys (used for different purposes / of different types) might look like. We should include example events.
- Guidance on potential ways of associating additional metadata (e.g. Service descriptions) with the newly created DID.
- read
- Mechanisms for retrieving a KEL
- Direct mode
- Further documentation could be helpful on how a KEL can be communicated directly to a counterparty (e.g. as a query argument in a DID URL).
- Indirect mode - i.e. interaction with witnesses
- Additional documentation / guidance is required on discovering associated communication endpoints.
- Provide further guidance and examples for mapping keys included in a KEL to a correct the resulting `VerificationMaterial` entry in a DID Document.
- update
- Define and describe how individual keys associated with a DID (sourced from a KEL) can be updated / managed independently (of each other).
- Comment on how the updated identifier state / events can be distributed / made available
- In case of pairwise interactions / identifiers.
- In combination with witnesses.
- deactivate
- Given that deactivation / abandonment is modelled as a rotation to an empty set of controlling keys, this section would mostly builds on the previous one.

Expected Outputs:
- DID Method specification.
- Reference resolver implementation.