Add initial-values matrix parameter to Generic DID Parameters

[csuwildcat]

This PR is intended to start the next phase of discussion around the needs highlighted in issue #70, regarding the ability to resolve DIDs for Methods that require a period of time before their inclusion/state has been propagated in an underling trust system (blockchain, ledger, etc.).

---

Preview | Diff

[peacekeeper]

Just a note that we're using lowercase terms now for everything..

[peacekeeper]

Wasn't the original suggestion that the value of this parameter would be a complete initial DID document? Are you now proposing that the value could be more flexible, e.g. anything that helps the DID to be resolved when otherwise that would not (yet) be possible? I think both are interesting ideas to explore!

[csuwildcat]

Though some methods (Sidetree-based ones) would use the parameter to pass the initial DID Document state, I figured there's no reason to constrict it to that exact value, given other methods could use different values/formats of values for their needs.

…

On Tue, Oct 22, 2019, 12:32 AM Markus Sabadello ***@***.***> wrote: Wasn't the original suggestion that the value of this parameter would be a complete initial DID document? Are you now proposing that the value could be more flexible, e.g. anything that helps the DID to be resolved when otherwise that would not (yet) be possible? I think both are interesting ideas to explore! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#84>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABAFSVGZNV5OCJDQEKB6LTQP2UBFANCNFSM4JDJVDCQ> .

[csuwildcat]

I have connected my GitHub and W3C accounts, so the IPR flag on this should be good to go now.

[peacekeeper]

Hey @csuwildcat you asked on today's 2019-11-05 DID WG call what's the next step for this. I think this is a good feature, but we haven't gotten much other feedback from the WG yet. If you don't mind I'd like to wait a bit longer, perhaps until we've had an opportunity to discuss matrix parameters during one of the upcoming WG calls..

[OR13]

Add examples from sidetree:

did:sidetree:<unique-portion>;initial-values=<encoded-original-did-document>

https://github.com/decentralized-identity/sidetree/blob/ae54238411245a55edeeda992e3dbcc6af1ffbc4/docs/protocol.md#unpublished-did-resolution

Per comments from WG Call

[msporny]

The parameter feels like it's too generic, which will lead to interop issues. Can we make this more specific, with a more specific encoding?

[msporny]

I don't understand why this is plural, does it support some sort of array semantics in the value property? If not, change to "initial-value".

[msporny]

What this paragraph says, and what was explained during the WG call today feel like two very different things. We shouldn't create generic parameters where DID Methods can put whatever they want to into the value... that will lead to bad interoperability. If this is going to be a base64 encoded value of the initial DID Document, then the property should be did-document. If it is a hash of the initial document, use a hashlink. If it is a link to the initial document, it should be document-link. The property should be more specific, with a specific encoding such that all methods implement it in the same way, if they choose to implement it.

[selfissued]

I believe that we should not merge this until we've determined whether there is actually consensus to resurrect the matrix parameter syntax at all. Less is more.

[csuwildcat]

I am entirely fine without this PR, or matrix parameters, so long as the group provides me a mechanism to do what we need to do. Not doing so is unacceptable - we MUST have a means to do this, full stop. Provide me a way, or pull in a PR like this, those are your choices, folks.

[peacekeeper]

I believe that we should not merge this until we've determined whether there is actually consensus to resurrect the matrix parameter syntax at all.

@selfissued In the CCG there was quite strong support e.g. for the service or the version-id and version-time parameters, and there are some clear use cases for additional parameters in the community (such as this one introduced by @csuwildcat). But since the topic is new for the WG, I agree it is valid to consider whether are not we want them at all. Do you perhaps want to raise a separate issue to discuss matrix parameters in general, so we can discuss this separately from any specific one?

[OR13]

I think we should figure out how to actually use query params and then use them... I'm not clear on what is legal regarding path, query and fragments....

did:example:123?service=foo&path=/bar/baz#!/path/a/b?query=1&foo=2

Return of the hashbang?

[cboscolo]

I'd like to bring this conversation back to the initial-value matrix parameter.

Can we agree that given for a DID did:foo:abc;initial-value=xyz123 the DID subject is did:foo:abc and that the matrix parameter initial-value=xyz123 is used to help the DID method determine the DID Document to be returned during the window when the DID is being committed to a backing store?

But, ;initial-value=xyz123 is not intended to part of the unique DID did:foo:abc nor intended to introduce a secondary equivalence DID? (Even tho, looking up did:foo:abc;initial-value=xyz123 and did:foo:abc will return the same DID Document once it is written to chain and not having been updated.)

[peacekeeper]

I'm not clear on what is legal regarding path, query and fragments....

The DID Core spec should not define or restrict in any way how DID developers can use path or query, in the same way how the base URI spec or e.g. the HTTP spec don't define specific paths or queries. Regarding the fragment, in the DID WG we cannot define how it works, since the MIME type of the resource, not the URI scheme, defines how the fragment works. The DID Resolution spec currently says that the path and query components may or may not be dereferencable in an application- or method-specific way, i.e. it leaves their use pretty much undefined and wide open.

Therefore, matrix parameters, not query parameters, are where we should define functionality that we think should be inherent to DID resolution itself, such as service selection, versioned DID documents, and in this case an initial value to be used for DID resolution.

did:example:123?service=foo&path=/bar/baz#!/path/a/b?query=1&foo=2

Uhh if people think matrix parameters are "complex", then what would you call this example? :)

[peacekeeper]

But, ;initial-value=xyz123 is not intended to part of the unique DID did:foo:abc nor intended to introduce a secondary equivalence DID?

@cboscolo +1 to everything you said in your comment!

If you add a matrix parameter to a DID, then the resulting DID URL could but doesn't have to identify the same resource, in a similar way as e.g. https://website.com/ and https://website.com/index.html are different URLs but may return the same resource.

[TallTed]

This may seem like a pedantic quibble, but I think it's necessary. Sloppy terminology use will slow our progress substantially, as arguments will arise about things that both/all sides already agree upon. I'm going to repeat some things here that most currently active participants already know, but later readers may not.

different URLs but may return the same resource

No. Different URIs (including URLs) may return the same representation of a resource. They never return the resource at all.

One representation might be returned for multiple resources for various reasons. And multiple URIs might refer to the same resource ("co-reference"), resulting again in an identical representation being returned.

Different URLs (being Locators) that co-reference the same resource are similar to filesystem links (without getting into the difference between symbolic and hard links).

Different URNs (being Names) that co-reference the same resource are similar to nicknames for a person ("Fred Third", "Frederick Jones III", "Freddy Three").

Different URIs (being Identifiers) that co-reference the same resource are similar to multiple names or locators for the same house ("third house on the left", "40 Main Street", "the Smith house", a hypothetical WKTliteral).

[OR13]

I suggest we use a method specific matrix param for this, and close this PR / Issue.

[OR13]

@csuwildcat we chose to use a method specific identifier for this, and did:peer / did:key might do the same as noted on:

• Make initial-values a Method-specific Matrix param, and change to initial-state decentralized-identity/sidetree#412
• Should we represent service block info as a DID with initial-state matrix params? decentralized-identity/didcomm-messaging#33
• Augmentation with DID Parameters w3c-ccg/did-method-key#5

The more PRs are open but not mergeable, the harder it is to focus reviews on things that might actually be mergeable. Are you opposed to closing this?

[csuwildcat]

Given we will be able to use either method specific matrix params or URL params for this, I'm going to close this out to avoid relying on the whims of DID Core spec participants. There's a good chance people will wake up to the broad usefulness/necessity of this (in fact, many have since we opened this) across methods that rely on truly decentralized systems, but I'm happy for folks to take as long as necessary to arrive at a place of understanding. When that time comes, maybe we move it from method specific redundancy to a general param, with historical notes about why that occurred.

[csuwildcat]

Closing this issue, as it isn't required that we have a Generic parameter (even if it may be a good idea). Instead, we can use parameters in Method-specific ways, and let the Generic question be assessed at a future date by opening a new Issue, if it warrants doing so.