Define the exact contents and structure of DID Resolution Metadata

[pfeairheller]

A defining feature of this DID method is the inclusion of end verifiable KERI artifacts for the current key state and service endpoints. This data will be returned in the DID Resolution Metadata and can be used any any consumer to verify the contents of the DID Document themselves (thus end verifiable).

We need to describe how the CESR artifacts that accompany all KERI messages (key events, rpys, etc) will be encapsulated in the JSON structured DID Resolution Metadata. In addition, for each mapping of a KERI feature to a DID Doc feature, the artifacts from that KERI feature must be included in the definition of the resolution metadata.

[peacekeeper]

Note that there is (1) DID Document Metadata and (2) DID Resolution Metadata.

The difference is that (1) is metadata about the DID and the DID document, whereas (2) is metadata about the resolution process that just happened.

My feeling is that with regard to KERI, things like key events and key state should go into (1), and e.g. which OOBIs or which watchers were used during a specific resolution process should go into (2).

[SmithSamuelM]

Suggestion:

We add a route/resource endpoint in the cloud agent mailbox API for a given AID that any did resolver can query which will add any stuff the controller wants to add to the did doc. So the minimum required are the service endpoints of the witnesses as we do currently but then if a given controller populates the endpoint then other stuff will get pulled from the database attached to the endpoint and put in the did doc.