Suggestions on things that can be added, removed from the DIDDoc section

[swcurran]

Suggestions on the DIDDoc section:

• There should be a section that points to how to process the KEL to get to the Key State from which the DIDDoc is derived. Presumably, that is another spec, with implementations?
• Does there need to be a similar section on the "TEL" that talks about processing the TEL to get to ?? and then how parts of that data model are pulled out to populate the DIDDoc?
• The section "AID Value" has much that is repeated from the core section -- notably how the AID is used in the DID identifier string. That should be removed.
• We need a way to say how "AlsoKnowAs" values are injected into the KEL/TEL, included in the end states of those, and then put into the DIDDoc. The ones we care about are when a did:webs is redirected to a new URL by its controller, so that existing references to the "old" DID are not useless.
• I think the "did:keri" example should be removed, unless someone is also defining a did:keri method.
• The fact that keys are converted from KERI format to DIDDoc format should be mechanical, perhaps with a list of transform types. E.g., there should be a generic -- conversion approach, and then Ed25519 and Secp256k1 examples.
• Should a Key Agreement key example be included?
• The "verification relationship" should be expressed from a DID concepts perspective vs. a KERI one. I think it is pretty typical in DIDDocs to add those items to the DIDDoc.
• I would suggest that there should not be KERI service endpoints in the DIDDoc. Anyone that wants to use the additional features of KERI can get the endpoints from the KEL/TEL. I would push against adding the list of the roles for KERI into the spec, or any reference to BADA-RUN. That is all in the KERI spec.
• We need to add how a DIDComm Messaging or some other non-KERI endpoint get into the KEL/TEL and DIDDoc.

[dhh1128]

There should be a section that points to how to process the KEL to get to the Key State from which the DIDDoc is derived. Presumably, that is another spec, with implementations?

Yes, that's in the KERI whitepaper. I suggest we simply hyperlink.

Does there need to be a similar section on the "TEL" that talks about processing the TEL to get to ?? and then how parts of that data model are pulled out to populate the DIDDoc?

Yes, another hyperlink.

The section "AID Value" has much that is repeated from the core section -- notably how the AID is used in the DID identifier string. That should be removed.

+1

We need a way to say how "AlsoKnowAs" values are injected into the KEL/TEL, included in the end states of those, and then put into the DIDDoc. The ones we care about are when a did:webs is redirected to a new URL by its controller, so that existing references to the "old" DID are not useless.

+1

I think the "did:keri" example should be removed, unless someone is also defining a did:keri method.

+1

The fact that keys are converted from KERI format to DIDDoc format should be mechanical, perhaps with a list of transform types. E.g., there should be a generic -- conversion approach, and then Ed25519 and Secp256k1 examples.

I'm not sure we should convert. CESR encoding avoids all the cumbersome, verbose, and clunky, semi-bespoke encodings used in other approaches. We would be more interoperable to do what Stephen says, but we would also be signing up to maintain and upgrade the spec as the world keeps releasing new encoding tweaks. Interesting tradeoff. No strong vote. I'm just sayin'...

Should a Key Agreement key example be included?

Yes.

The "verification relationship" should be expressed from a DID concepts perspective vs. a KERI one. I think it is pretty typical in DIDDocs to add those items to the DIDDoc.

Yes. However, I think that KERI's mental model of the thing that DID theory calls "verification relationships" divides the conceptual space differently. For example, it has a verification relationship that is about key rotation only, and IIUC it conflates authentication and general signing. So I think it's unavoidable that we acknowledge the difference to some extent.

I would suggest that there should not be KERI service endpoints in the DIDDoc. Anyone that wants to use the additional features of KERI can get the endpoints from the KEL/TEL. I would push against adding the list of the roles for KERI into the spec, or any reference to BADA-RUN. That is all in the KERI spec.

Yep.

We need to add how a DIDComm Messaging or some other non-KERI endpoint get into the KEL/TEL and DIDDoc.

+1

[dhh1128]

I'm willing to contribute PRs for some of these, once we clarify whether there's consensus on them.

[2byrds]

I have accounted for these suggestions in my current PR work (includes other suggestions from Stephen from another PR)
Or I have created new issues.
Created granular issues to address these:
#52
#51
#53
#54
#48