Service Endpoint Discovery

[SmithSamuelM]

@swcurren https://github.com/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.

Good comment. The essential content of a KERI DID Doc is the service endpoint(s) from which to download the Key Event Log for the identifier. So we should add that to the method spec as you suggest. From a KERI security perspective the DID DOC itself is an out-of-band discovery mechanism for service endpoints from which to download verifiable key state via the KEL.

On your related question: We have defined an OOBI protocol (Out-Of-Band-Introduction) for KERI that allows the controller of a KERI AID (the cryptographic prefix or method specific ID portion of a did:keri) to publish a URL for a service end point with the KERI AID in any number of ways. The recipeint of the OOBI then looks up the endpoint and queries it for verifiable proof of key-state via the resulting KEL. If the query result is not verified then the OOBI is discarded. Essentially a did doc for KERI is a delivery mechanism for KERI OOBIs. But OOBI discovery is not limited to DID Docs but may use any other discovery method including web search, .well-known URLs, QR Codes, etc.

A draft of the OOBI spec may be found here:

OOBI https://hackmd.io/MxTAIBQTRkWU4-w140tNuA

In the OOBI doc there is a reference to BADA (Best Available Data Acceptance) policy. We have since expanded that concept to what we are calling BADA-RUN (there was an IIW session that covered this). Not explained in the OOBI document but in the BADA-RUN is the idea of security level data types for data with regards to acceptance policy. The three primary types are:

• Key State in a KEL (explicitly included in KERI establishment events i.e. keys and backing infrastructure such as witness identifiers)
• Anchored Data (explicit digest of data anchored in a KEL)
• Signed TimeStamped Data stored in database (not anchored but relative preeminence determined by key state and then timestamp)

The last two mechanisms may be used to associate verifiable service endpoints with a KEL that may be surfaced in a DID DOC.

Although still under development there is a discussion on BADA-RUN here

https://hackmd.io/Qsrfj7Y-TIGl5ESvrxWGxw

[swcurran]

While those KERI-specific endpoints are useful if you are interested in the KERI identifier, if you are interested in the contents of the DIDDoc and other service endpoints, they are insufficient. For example, if I am resolving DIDs to establish a DIDComm connection, the DIDs of my collaborators may be hosted in a number of places (KERI, Bitcoin, Ethereum, DID:Web, DID:GitHub etc.) based on the choices made by my connections -- other DID controllers. At that level, I just want to resolve the DID and find the DIDComm Service endpoint -- regardless of the DID Method. I count on my DID resolver to handle the DID methods that I'm willing to accept -- one of which may be the did:keri method. My resolver deals with the messy details, and I don't care about the KEL, Key State or anything else related to KERI, and likewise for any of the other DID methods that my resolver handles.

I think to make the DID Method consumable by others, the DID Method document should include a section on how a KERI DID behaves like any other DID method -- e.g. how I as a DID Controller can put arbitrary things (perhaps within reason) into my DIDDoc, so that consumers of that DID Doc can retrieve and use it. As noted, a resolver MUST follow the rules for verifying the integrity of the KERI Identifier, but in this case, that's handled separately from the business purpose of resolving the DIDDoc contents.

[SmithSamuelM]

@swcurran

While those KERI-specific endpoints are useful if you are interested in the KERI identifier, if you are interested in the contents of the DIDDoc and other service endpoints, they are insufficient.

Yes I agree. The BADA-RUN policy is not merely about service endpoints that may be used to download KELs but any data including service endpoints for other purposes. This puts the security policy of all data associated with a given AID on the same footing. So a did:keri user could very well put did:comm endpoints in the did doc and could choose to have those verifiable as signed type 3 data via the did doc. The did method resolver and or wallet would do the heavy lifting to verify those endpoints as valid data signed by the controller of the identifier. This is not explained in the did:keri method yet. So appreciate the feedback.

[SmithSamuelM]

If you have an example of what you would like to see in a did doc for those other purposes as in JSON, that would be most welcome.

[swcurran]

I think looking at the Universal Resolver examples are useful. While some have only entries that are based on what comes from the DID Method (e.g., DID:BTCR...) others allow the adding of more data to the DIDDoc. There are a lot of examples. The "did:sov" example shows some extended data -- service endpoints. In the new did:indy method, we are proposing to allow the controller to add arbitrary JSON (subject to some constraints, but not much) to the DID data that gets added to the DIDDoc. So there is a very direct connection -- e.g. "Add data here, in this format, and it will be added to the DIDDoc using these rules."

[pfeairheller]

I think it is important to clarify the statement "My resolver deals with the messy details" and the implications to where you are placing your trust. All data in KERI is end-verifiable which means that you should not place your trust in any other party to verify an identifier and data signed by an identifier, ie. the steps needed to resolve a did:keri DID into a DIDDoc.

When looked at through the lens of zero-trust, a did:keri did resolver becomes an extension of a KERI wallet and is responsible for "end verifying" the KEL and key state and then the anchors or signatures on associated data. Architecturally this means that a software component that is performing these functions must be deployed as part of the system that is using it to resolve KERI DIDs. Otherwise you allowing a component out of your control to perform the KERI verification steps thus placing trust in it.

In my mind, there is an important architectural distinction that needs to be made if we want to create a KERI did resolver that provides the resolution API of a did resolver. Because DIDDocs are not signed by the did resolver, they suffer from potential attacks if we allow for a "remote binding" resolver (https://w3c-ccg.github.io/did-resolution/#dfn-remote-binding). Only a "local binding" resolver (https://w3c-ccg.github.io/did-resolution/#dfn-local-binding) should be allowed knowing that the local resolver is performing the correct end verification of the KERI key state and signatures locally. Otherwise, as Sam suggests, a remote binding resolver would only return KERI OOBIs as part of a DIDDoc and expect the consumer of that DIDDoc to be running a KERI capable wallet that would do all the messy parts after the DID resolution.

[swcurran]

Absolutely @pfeairheller. I did not mean that a remote DID KERI resolver should be used. Rather, from an architectural point, I'm not going to mix my ToIP Layer 1 code (DID resolvers) from ToIP Layer 2/3 code -- I'm going to keep them separate. So regardless of where my DID Resolver is (built in, internal service, etc.), I'm going to want it to do the Layer 1 work and return to me a DIDDoc. Further, I'm going to want to put things into my DIDDoc that are resolved by others. As such, I think the DID Method spec needs to outline how I can use KERI to put things I need into my DIDDoc, with the same functionality I can with other DID Methods.