Did-core: Add sections on DID Resolution

[peacekeeper]

Since refactoring the spec structure (https://github.com/w3c/did-core/pull/186), we now have new sections 3.4 DID Resolvers and DID Resolution and 10. Resolution.

The DID WG Charter says that the WG will _Establish a deterministic mapping between DID method identifiers and the resolution process used to resolve that DID method_.

At the DID WG F2F meeting we had a session on DID Resolution and discussed that the DID Core spec should contain the "contract" between DIDs and DID documents (inputs and outputs of DID Resolution).

To fill in the new sections in the DID Core specification, we may be able to re-use content from the Credentials Community Group which has been working on a separate DID Resolution specification.

[jricher]

+1 this section needs to define a contract between the different components of the DID system

[peacekeeper]

Thanks @jricher I agree. As discussed on today's WG call, I'd be happy to make an initial proposal with you as reviewer/collaborator. Anyone else who is interested in this, feel free to add thoughts and/or specific ideas and content.

[jricher]

This has consequences for the data structures in #203

[peacekeeper]

On today's DID WG call I presented some slides that compare the current DID Core structure with the DID Resolution structure, and some ideas what would be in scope for which spec: https://docs.google.com/presentation/d/1Ccnbh_A53yzTyIIrw6ol_EakAliuo3MfxIFlGsaoKos/

[philarcher]

I've said this elsewhere but I think it makes exactly no sense to not formally standardise DID resolution. As long as the resolution spec remains a CCG report - whatever its content - it cannot be a normative reference for DID core (a normative standard cannot be defined in terms of a non-normative reference). The current discussion around matrix parameters/query parameters talks a lot about service endpoints. You can't talk about DID URLs (or whatever we end up calling them) without referring to service endpoints. And you can't talk about service endpoints without talking about resolvers.

Therefore, I am becoming ever more convinced that the resolution spec should be moved to Rec Track and that most of the discussion about service endpoints should be part of that spec, not the core.

[peacekeeper]

The PRs that are currently addressing this issue are: https://github.com/w3c/did-core/pull/295, https://github.com/w3c/did-core/pull/296, https://github.com/w3c/did-core/pull/297, https://github.com/w3c/did-core/pull/298, https://github.com/w3c/did-core/pull/299, https://github.com/w3c/did-core/pull/300

Each one incrementally builds on the one before it. I think the next step should be addressing comments in https://github.com/w3c/did-core/pull/296, merge that, and proceed with the other ones that build on top.

[peacekeeper]

The latest PR that is addressing the DID Resolution contract is: https://github.com/w3c/did-core/pull/331

It defines two functions, resolve (which returns a DID document as an abstract data model) and resolveStream (which returns a DID document as a byte stream in a conformant representation).

Once we merge this, the only open topics should be: 1. Do we also want to define a dereference function, and 2. What's the metadata structure (PRs for this exist already, see the previous comment).

[OR13]

+1 to closing this, and tackling de-referencing in isolation.

[peacekeeper]

Sections on DID Resolution have been added (e.g. in https://github.com/w3c/did-core/pull/331). Unless there are any objections, I propose to close this issue and create a new one to discuss adding a section on DID URL Dereferencing.

[peacekeeper]

As discussed, I created this new issue to track DID URL Dereferencing: https://github.com/w3c/did-core/issues/364

[brentzundel]

new issue created for continued conversation, closing this issue.