Update ABNF to use matrix parameters #187
Conversation
Signed-off-by: Markus Sabadello <[email protected]>
Signed-off-by: Markus Sabadello <[email protected]>
Signed-off-by: Markus Sabadello <[email protected]>
|
Here's an experimental parser generated from the proposed new ABNF: Source code: |
index.html
Outdated
| Berners-Lee and his collaborators. | ||
| The ABNF above does not specify any parameter names (the <code>param-name</code> | ||
| rule). The following table defines a set of generic DID parameter names for | ||
| parameters that MUST operate uniformly across all DID methods. (Method-specific |
There was a problem hiding this comment.
If DID methods can't or won't implement some of the proposed parameters because of a preference for greater decentralization by limiting the heavy lifting done by resolvers, then there should be the option to not implement. Prefer wording that says if a DID method implements a parameter, that DID method parameter MUST operate uniformly.
There was a problem hiding this comment.
+1 this reads like all parameters are required by all DID methods. Should be an IF-MUST. Suggest to change
The following table defines a set of generic DID parameter names for
parameters that MUST operate uniformly across all DID methods.
to
The following table defines a set of generic DID parameter names. DID
methods MAY implement any or all of the parameters, and those
implemented MUST operate uniformly across all DID methods.
There was a problem hiding this comment.
Since all DID methods must be able to resolve a DID to a DID Document, and the first four parameters (service, service-type, key, key-type) operate directly on the DID Document, I don't see how a DID method would NOT support them? Those parameters are completely generic.
I could however see that a particular implementation of a DID resolver may not support these parameters. E.g. a DID resolver may be able to resolve a DID to its DID Document, but it doesn't have the ability to select services or keys from the DID Document. I agree that probably we want to allow this too.
Does this make sense? Perhaps we mean the same thing anyway?
There was a problem hiding this comment.
Since all DID methods must be able to resolve a DID to a DID Document, and the first four parameters (service, service-type, key, key-type) operate directly on the DID Document
I agree. These params don't seem in jeopardy of not being supported by the resolver since these operate on the document returned and is of no consequence to the resolver.
I could however see that a particular implementation of a DID resolver may not support these parameters. E.g. a DID resolver may be able to resolve a DID to its DID Document, but it doesn't have the ability to select services or keys from the DID Document.
I agree, this shouldn't be of concern to the DID resolver
The parameters which you didn't mention, for example version-time would need to operate on a group of DIDs, and therefore be a function of the resolver. I'm I not understanding how parameters like version-time would work?
For parameters such as version-time, could these be IF the resolver implements they MUST operate in the same way?
There was a problem hiding this comment.
I agree, this shouldn't be of concern to the DID resolver
Depends on what we mean by "DID resolver". Is it just the component that returns the DID Document for a given DID, or does it perform the full dereferencing process for a DID URL. We haven't defined this very well yet. This will go into the separate DID Resolution spec.
I'm I not understanding how parameters like
version-timewould work?
It would return the DID Document for a given DID at a certain point in time (e.g. the one from 2 weeks ago, rather than the current DID Document). This will also be defined in more detail in the DID Resolution spec.
For parameters such as
version-time, could these be IF the resolver implements they MUST operate in the same way?
Yes that's the idea.
There was a problem hiding this comment.
Depends on what we mean by "DID resolver". Is it just the component that returns the DID Document for a given DID, or does it perform the full dereferencing process for a DID URL. We haven't defined this very well yet. This will go into the separate DID Resolution spec.
Great point. I've been thinking of the DID resolver as the mechanism that dereferences the DID URL. What happens client side should be a separate concern outside of the DID resolver perhaps? I do agree that this should be defined better.
Yes that's the idea.
Great, can we edit this PR so it reads that way?
There was a problem hiding this comment.
If DID methods can't or won't implement some of the proposed parameters because of a preference for greater decentralization by limiting the heavy lifting done by resolvers, then there should be the option to not implement.
There should also be a away to perform a query against a DID method and DID resolver combination to determine which parameters are supported on a DID method by DID method basis.
There was a problem hiding this comment.
@rhiaro and @yancyribbens: Do you think 9ec0477 is a step in the right direction to clarify this?
There was a problem hiding this comment.
There should also be a away to perform a query against a DID method and DID resolver combination to determine which parameters are supported on a DID method by DID method basis.
@mwherman2000 As we have discussed in w3c/did-resolution#25, I agree this is a useful feature that can be supported by DID methods and DID resolvers, however I don't think this is in scope of the DID URL syntax. The proposed grammar always requires a method-specific-id as part of the DID URL, therefore there is no way to "perform a query against a DID method" itself using a DID URL.
There was a problem hiding this comment.
Actually @mwherman2000, I'd like to correct myself. #189 (comment) just reminded me that in fact the method-specific-id can be blank, so with this currently proposed grammar, there could actually be an identifier for the method itself. Happy to explore that further...
| <code>content-type</code> | ||
| </td> | ||
| <td> | ||
| Specifies a type of content object (other than a DID Document) to be returned |
There was a problem hiding this comment.
Maybe I missed something - what other kinds of content objects are in scope (and not implementation-specific) to be returned from the DID registry, other than a DID Document?
There was a problem hiding this comment.
At RWoT#8 (I wasn't there), the idea of "content references" came up, which means that a DID URL could refer to some object in the registry other than a DID Document. For example, in the Sovrin/Indy universe, there is a use case to refer to schemas and credential definitions. At RWoT#8 the idea was to introduce additional syntax to accomplish this, but now we thought we can also just use matrix parameters to identify such additional objects. I'm not convinced that the concrete parameters that are currently here (content-type, content-id) are ideal. For example, perhaps path or query or fragment could be used instead of content-id or something like that. I would propose however that we don't let questions about individual matrix parameters stand in the way of merging the PR - we can always fine-tune the exact parameters later.
There was a problem hiding this comment.
what other kinds of content objects are in scope..
+1. Referencing other objects seems out of scope unless there is a specific use case.
For example, in the Sovrin/Indy universe..
@peacekeeper This sounds like an implementation specific use case.. Any use cases that's specific to more than one implementation?
There was a problem hiding this comment.
I agree the schema / credential definition example is specific to only the "sov" DID method, but the concept itself (having a mechanism to reference arbitrary content in the target system) could be generic. @ken-ebert and @talltree brought up this requirement of "content references".
|
Based on feedback this week, I am creating new PRs that separate 1. Introduction of the matrix parameter concept itself, and 2. Concrete proposed matrix parameters. This way, we can better organize the discussion and accept/change/reject the PRs separately. Please continue here on the new PR: #189 |
This updates the ABNF and introduces matrix parameters, based on discussions on the mailing list as well as the DID Spec and DID Resolution Spec Weekly Meetings.
Fixes #85. Fixes #90. Fixes #170. Fixes #177.
Replaces #106.
Related to #185.
UPDATE: This PR has been closed and replaced by #189
Preview | Diff