Add "key" DID URL matrix parameter.

[peacekeeper]

Re-creating PR from CCG repo: w3c-ccg/did-spec#192. Please consider earlier discussions there.

---

Preview | Diff

[peacekeeper]

This adds one concrete DID URL matrix parameter.

Description: Identifies a key from the DID Document by key id.

Example: did:example:1234;key=mykey

[dlongley]

-1 to merging as I don't understand the purpose and it seems like it's just adding another way of doing something that can already be done. A key can already be referenced by its own ID, which is itself a URL.

[msporny]

Example: did:example:1234;key=mykey

Agree with @dlongley ... why do we need two ways to refer to a key... for example, the following would work just fine today without the need for this matrix parameter name:

did:example:1234#mykey

[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.

[OR13]

I'd rather see a general support for JSONPath: https://jsonpath.com/ , not a case by case way of selecting data that exists inside a did document, and to the points made of the call, I question if matrix-params are the right way to refer to data internal to the did doc.

did:example:123;jsonPath=$.publicKey[:1].id

[dmitrizagidulin]

-1 to a key-specific matrix parameter. This can be covered by a general-purpose 'id' matrix param.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

PR issue #59
Manu Sporny: #59
Manu Sporny: did:example:1234;key=mykey
Manu Sporny: Let’s pick PR 59, relatively easy. suggestion for a “key” matrix parameter
Markus Sabadello: I agree, let’s look at concrete parameters
… key has been suggested as a way to select a particular key (similar as they way the service endpoint could be identified with a service matrix parameter
Daniel Buchner: Tell me how to pass intermediate state values that can be dropped after anchoring
Orie Steele: -1 seems like a use for JsonPath… https://goessner.net/articles/JsonPath/
Markus Sabadello: example: use did:ex:1234#keys-1 instead of did:ex:1234;key=keys1
Dave Longley: If you want to refer to something that has an id in the document, we already have a way to do that.
… not in my view what matrix parameters are for.
… generally for things outside of the DID doc
… something in the past, or on a different server (redirect)
… I haven’t seen a use case that requires a matrix param just to refer to a key.
Christopher Allen: -1 agree with dlongley.
Justin Richer: +1 … fragments are for internal processing, matrix params are for processing things on their way to the document
Daniel Buchner: I agree. the issue I suggest I don’t think is solved.
… we have to have a way to do it.
Manu Sporny: +1 to Justin_R’s language.
Orie Steele: to clarify: -1 to adding key matrix param, I’d rather see selection in a document built on an existing syntax
Manu Sporny: +1 to what Orie just said.
Daniel Buchner: if there’s any other way to do it. I have a intermediary state where some value must be passed that people can use in lieu of having an actual anchor
Markus Sabadello: daniel is talking about #84
Christopher Allen: That sounds like something else though
Markus Sabadello: just one more time. key matrix parameter. One small different form using the fragment. the matrix parameter would be independent of the mime type of the did doc
… if we use did urls with fragments, those would depend on the media type of the did doc, whereas the matrix parameter would allow you to refer to a key independent of the media type of the did doc.
… that said, I support closing this PR
Daniel Buchner: manu, Chris: if a DID is not anchored in Bitcoin for 10 minutes, how do I pass a resolvable ID to the RP in the meantime?
It is not an acceptable answer to say “just wait 10-20 minutes”, when clearly we can just allow passage of some values
Drummond Reed: Markus is correct that a “key=” matrix parameter would be a primary resource from a SemWeb standpoint.
Manu Sporny: daniel, add a different matrix parameter… like matrix-unresolved=true or something… we’re talking about a specific PR… key one.
Daniel Buchner: it is not about a boolean
it is about actually passing the values REQUIRED to resolve the DID
Daniel Buchner: In ION’s case, the initial-value is the base64 encoded state of the initial DID document
Same in Element
same in all the methods that use an actual decentralized system
no
not some flag
Justin Richer: This is a prime example of why we need to be having the DID resolution and dereferencing conversation here
Orie Steele: +1 to justin’s point.
Justin Richer: matrix parameters are passed to the resolver, which is a black box as far as this group is concerned.
Manu Sporny: daniel, this is issue #70?
Justin Richer: resolution has different mime types, etc. we should bring resolution into this group.
Drummond Reed: +1 to matrix parameters being passed into the resolution process. That’s also different from fragments.
+1 to bringing resolution into the scope of the WG
Christopher Allen: what is your proposal again?
Dmitri Zagidulin: plus one ot did resolution.
… question, why are we giving keys special treatment?
Daniel Buchner: Chris: #70
Dmitri Zagidulin: why not a general id parameter
Daniel Burnett: what are the next steps?
Jonathan Holt: +1 to id seems reasonable compromise
Michael Jones: Bringing DID resolution into the WG would require rechartering, as it’s a significant increase in scope
Justin Richer: @selfissued no it is not, there is a phrase in the charter about resolution mechanisms
Establish a deterministic mapping between DID method identifiers and the resolution process used to resolve that DID method.
Markus Sabadello: a generic “id” matrix parameter has been casually talked about, e.g.: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/draft-documents/did-resolution-v2.md
Manu Sporny: I think we need folks to weigh in on the PRs. Now that you have the background, tell us why the PRs should or should not be merged.
Daniel Buchner: Can folks do a call on the initial-values matrix param?
Markus Sabadello: That is the goal of today’s discussion, to introduce matrix parameters so we can get feedback on the PRs
Daniel Buchner: I see a lot of misunderstanding of what at least our proposed param actually is for/does

[peacekeeper]

Based on feedback, I'm ready to close this PR after a few days. I agree with the majority that the case for this parameter isn't strong enough.

Just wanted to re-state one comment I made during today's call: did:ex:1234#key-1 would be dependent on the media type of the DID document, and dereferencing the fragment (a "secondary resource") may happen in a different architectural component than resolving the DID (similar to how an HTTP fragment is dereferenced by a browser, not by a web server), whereas did:ex:1234;key=key-1 would be independent of the media type of the DID document.

Perhaps I will open a separate PR for a more generic id matrix parameter, since that has been proposed a few times, and then we can discuss if that has support or not.

[msporny]

Based on feedback, I'm ready to close this PR after a few days. I agree with the majority that the case for this parameter isn't strong enough.

+1

Just wanted to re-state one comment I made during today's call: did:ex:1234#key-1 would be dependent on the media type of the DID document, and dereferencing the fragment (a "secondary resource") may happen in a different architectural component than resolving the DID (similar to how an HTTP fragment is dereferenced by a browser, not by a web server), whereas did:ex:1234;key=key-1 would be independent of the media type of the DID document.

We may want to explore which media types we're concerned about where resolution of the fragment id isn't well defined. I expect there are zero that we care about today and that may hold true in the future. There W3C TAG did some work in this area years ago:

https://www.w3.org/TR/fragid-best-practices/#structures

Perhaps I will open a separate PR for a more generic id matrix parameter, since that has been proposed a few times, and then we can discuss if that has support or not.

In an attempt to not waste your time, I think I'd be a -1 for an id matrix parameter, because of the above. We have a mechanism already, we should see if that mechanism fails for any known implementation today. This is always something we can add in the future if there is a concrete use case, but I hesitate to add it today because we might be increasing spec complexity with a feature no one needs.

[msporny]

I'd rather see a general support for JSONPath: https://jsonpath.com/ , not a case by case way of selecting data that exists inside a did document, and to the points made of the call, I question if matrix-params are the right way to refer to data internal to the did doc.

JSON Path could be problematic as it assumes that the data structure is tree-based and not graph based. I'm fine if some DID Methods want to support such a thing, but again... question why we need it since we already have a way of identifying something in a DID Document via fragid today.