Should the DID method spec include how to get a DID Doc from the DIDDoc Metadata?

[swcurran]

I notice that there is not an example of an actual DIDDoc produced from a Key Event State with the definition of how it would be produced. Should that be documented? The purpose of a DID Method is to resolve a DID to a DIDDoc, so I think the process for producing the DIDDoc should be documented in the DID Method spec. beyond "It may include verification method and won't include service".

My assumption is that a KERI DID Resolver is that a piece of software would get a DID, (somehow) find the KEL for the DID, process the KEL to get to a Key State and then produce a DIDDoc based on the content of the Key State. AFAIK, all the steps up to that last one is documented elsewhere, and that step should be documented in the DID Method document.

A (mostly related question): Is there a way to insert an endpoint into the KEL, surface it in a Key State and then insert it into a DIDDoc derived from that Key State? That would seem to be a good use of a KERI identifier -- a stable ID, with provenance, a public key and way to contact the controller of the key.

Perhaps a separate issue. I would think the "version_id" and/or "version_time" DID resolution parameters should be supported in the DID Method. As I understand it, the KEL would be processed up the requested version Key State, and the DIDDoc produced from that state.

[SmithSamuelM]

See the discussion here on the WebOfTrust repo which is where actvity for the did:keri is being conducted.
WebOfTrust/did-keri#3