Enable instant DID use/resolution for DID Methods that include a propagation delay #70
Comments
|
The section on equivalence, appears to describe similar functionality. If it were not for the language mentioned above, defining equivalence within a DID Method would be up to the method implementer it would seem. The Long-Form ID has similarities to To summarize again, it might be desirable for some DID Methods to support multiple DIDs that resolve to the same DID Document, where that document always contains a Short-Form ID. |
|
@OR13 You are exactly right, that is the reason we included Equivalence in the Future Work session. @csuwildcat's use case is indeed a good example of when equivalence assertions are needed, however it is actually one of the easier ones since:
The reason we put Equivalence in the Future Work section is that it can be considerably harder to prove equivalence across DIDs from different methods where there is no direct algorithmic proof. I personally favor tackling at least intra-method equivalence in the DID spec. I could also support defining at least one straightforward method of achieving inter-method equivalence. But I would not make it a top priority. |
|
So it seems the key question is: If you resolve Instead, my feeling was that the DID Document would include an equivalence statement, or redirect statement, that points to the new DID.. E.g. if you resolve Semantically, there's a slight difference between stating "equivalence" and "redirect". The former would be a bit like an The above would instruct a client to use Also see w3c/did-resolution#36. |
msporny
added
the
discuss
|
Given the veracity of a DID Document is determined by the process/proofing done within the DID Method itself, why is there a need to pose this as a redirect? Redirect sounds more like a pointer to something distinctly different, not the exact same ID. Can we at least call this something besides |
|
Markus and I talked a bit, and he made a good point: this ask is dealing with a unidirectional relationship between variations of the same ID. Markus mentioned that XDI had a |
Quick correction.. What I said was that XRDS (not XDI) had a |
|
After talking with several folks, there may be a better way to address the needs of methods that have a period of delay between generation of a DID and the finalization of the DID on whatever ledger/chain, etc., their network uses: The proposal is to create a new Generic DID Parameter:
|
|
If there are no objections, I intend to fork the current spec and create a PR for the addition of the |
csuwildcat
changed the title
csuwildcat
changed the title
|
This probably requires some review from the wider WG, but in general I think this could be a useful feature that makes sense across multiple DID methods. So let's start a PR to try and get some more feedback. |
|
There was a discussion about a similar approach for |
|
@OR13 the |
|
Can we consider renaming |
|
@thehenrytsai of the two you mentioned, I like |
|
I wonder if |
+1 I don't understand that either. It's confusing the say a matrix parameter is "returned". Perhaps what you really want here is resolver metadata, or a DID document extension? |
I don't think you can use this in a 'fallback' sense, because the initial values present in the parameter may describe a state that is only secure and valid during the unpublished/propagated phase. This means that making it a fallback would be insecure for any DID that had changes made to it since, because it would wrongly indicate that the resolving party could rely on the initial values, which may, for example, include keys that have since been removed. |
Sorry that I mixed this up - what I meant is that |
|
@peacekeeper whats the relationship between the did resolution spec: https://w3c-ccg.github.io/did-resolution/ And this working group again? It seems like the addition of a generic matrix parameter would be very much in scope for this group, but a method specific one, wouldn't need any changes. I'm very much in favor of standardizing the process of providing initial data to a resolver, and I think it would be nice if it were generic, but if method specific resolvers are making the decision of when to use the resolution meta data to forward related info, it feels like maybe the Seems like we could do: A. Generic matrix param + DID Document Extension A seems definitely in this working group, I'm not sure about B, but it seems like its potentially less difficult to accomplish. |
|
@OR13 right now the DID spec (identifier syntax and DID document data model and format) is being developed by the DID WG, whereas the DID Resolution spec (resolving and dereferencing) is a work item of the CCG. This is under active discussion right now, since we often find that topics in both groups are closely related. Matrix parameters are one such topic, and there are others as well. I do think this proposal would be a generic matrix parameter rather than method-specific. Generic doesn't mean that all methods have to support it. It just means that it should have the same semantics across those methods that DO support it. |
|
|
Yes, I agree with you Markus, this is a generic parameter, because it would
have the same general meaning/intent across all methods that use it, and
there are many methods that have the same need - this is, imo, what defines
a generic parameter.
…On Fri, Oct 18, 2019, 2:00 PM Markus Sabadello ***@***.***> wrote:
@OR13 <https://github.com/OR13> right now the DID spec (identifier syntax
and DID document data model and format) is being developed by the DID WG,
whereas the DID Resolution spec (resolving and dereferencing) is a work
item of the CCG. This is under active discussion right now, since we often
find that topic in both groups are closely related. Matrix parameters are
one such topic, and there are others as well.
I do think this proposal would be a generic matrix parameter rather than
method-specific. Generic doesn't mean that all methods have to support it.
It just means that it should have the same semantics across those methods
that DO support it.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#70>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABAFSV3C7J55HRR3AK2OIDQPIPXVANCNFSM4JATH4UQ>
.
|
|
+1 also that this request would be part of the DID resolution protocol. Also, it seems like the default param would be |
|
Initial values in sidetree spec: |
|
wouldn't this lead to a race condition and/or eclipse attack if I trick the validating party into thinking that there are init values when it isn't a new DID doc? |
|
To use Sidetree methods as an example, their DID identifier strings are made up of the following:
If you were to change any of those identifier values, you would be dealing with a different DID, thus when you tack on the initial state values via a matrix param, as follows:
^ This way you have cryptographic certainty that the person who controls the keys/values bound to to that particular DID identifier string is the controller. If someone were to tack on a different |
Yeah, this is a tough one, because we know multiple methods do need it, and I would bet dollars to doughnuts more future methods that have nothing to do with how Sidetree works will face the same general constraints imposed by underlying ledger systems, for which this is a generic solution that allows instant use of their DIDs regardless of what your specific DID Method's |
|
Even without the time delay concern, this is useful for leaving the did off ledger until an update is necessary. In other words, this makes creating a DID free initially. This is why I believe most methods will want to use it. |
|
fwiw, this concept is also useful for btcr. We just haven't dug into this yet. |
I agree with this. Some generic parameters work with all DID methods (e.g. the Besides |
Only if you're assuming that everybody who wants to resolve the did will know the initial state information which may not be the case. |
I am not sure what you mean - initial-values IS the initial state information, which you would be handing anyone you would like to resolve the DID. For this reason, I don't see anything inaccurate about what Kyle wrote. |
|
If you assume that people can only know about or want to resolve a DID if the DID controller handed them the DID (with the initial state information) then yes the statement is accurate. For Sidetree, this assumption makes sense because how else is anyone supposed to guess a DID, however this may not be the case for all DID methods. Some don't cryptographically tie the unique suffix with the initial state information. Hence my point: Using initial-values makes creating a DID free initially, only if the people who would want to resolve the DID know directly or indirectly the initial state information from the DID controller. |
Yes, this is what this mechanism is for.
Yes, other Methods may not be able to provide this useful feature, due to limitations inherent to them.
Yes, GitHub is a centralized database, so it can be updated very quickly, and delete your account, screw up your data, or do any number of negative things very quickly as well. With a mechanism like this, Sidetree and other methods that are capable of this generic concept are able to provide secure, immediate resolvability of newly created DIDs (and potentially even 'anchored + 1' states) in a robustly decentralized way, all without the downsides of a centralized Method, like Github DIDs.
Yes, methods like |
|
Regarding your last two points, I do remain concerned about the point made earlier:
IMO Initial-values is a useful feature than solves an important business problem when there is a propagation delay concern, but should not be an excuse to do away with ledgers until an update is necessary for mainly two reasons:
That being said, I'm in favor of That does however brings the question: Do we need a standard way to verify that the did corresponds to the |
|
Given the discussing occurring in #159 I'd suggest we put this discussion on hold until a decision is made there. |
|
@csuwildcat and I came up with an approach that may enable his use case without requiring an extra labeled parameter. I'd like to float that idea here to see how others feel about it. The specific idea is to separate the method-specific identifier into components for which only the first element is considered the unique identifier for the entity. The latter components are optional and their meaning method specific. For convenience sake, I'm assuming a colon is a suitable separator. This would require an adjustment to the ABNF, but that an implementation detail we can figure out later. For example, Would refer to the entity identified by did:ex:abc, with the initial state of 123 (assuming the method treats the additional component as an initial state). Any credentials issued to the entity would be free to use the "short form" of did:ex:abc, since that uniquely defines the identifier. I believe this relaxation of the meaning of a method-specific id would give DID method creators a flexible, optional means for including the initial state of a DID Document in the DID URL itself, without the need for labeled parameters, matrix or otherwise. Another way to think about this pattern is that the DID URL basically says In the case of side-tree that id part is deterministically derived from that data so if the registry-based lookup returns no result, the data part can be verified against the id and treated as the DID Document itself. This makes the DID-URL sort of a In short, each DID method would be free to specify an initial subset of the method-specific identifier as an entity ID, usable for all references to that entity, while using the balance of the method-specific identifier for additional information, such as initial state. Or the DID method could simply define this extra part is not used. My initial recommend is that only that the id part have consistent semantics across methods. The meaning of the data part, IMO, could be method specific, and as such always optional. Although, standardizing its use for "initial state" may prove useful. @peacekeeper @msporny @talltree Does this relaxation of the method-specific identifier violate any deeply held notions of what a DID means? |
|
@jandrieu I still think the A+ is to see if we can get some sort of param agreement that we can utilize for this. Also, I thought about it and it's going to be hard to make assumptions about DID colon-separated segments, because there's a broad range of uses. For example: we just agreed to add did:method:test:ID_SUFFIX as the way to note the difference between test/prod network IDs in a family of methods folks are developing, which means any other path assumptions may be fraught for this or similar segment uses by other groups. Params are my first choice, with anything else being less-than. I'm happy to wait on this and just proceed with the param discussion. |
This is essentially the approach taken by the Hashlink spec (content_id:content_meta), except that in this case, you're prepending a global identifier and placing the content identifier after it (global_id:content_id:content_meta). Raises the question why you couldn't just use a hashlink here, as hashlinks enable you to encode the data in the content_meta if you so desired. In any case, feels like a workable solution for those that want initial_params with the caveats that @csuwildcat mentions above. |
|
This approach does seem problematic for DID methods already using |
|
@dlongley Right. That's an issue. And if we allow the method to independently set which part of the method-specific id, then we don't have interoperability. If that's not a reasonable solution, then, to @csuwildcat's dismay, I'll have to say I still don't find a compelling reason to put the meta-data in the URL itself. If the DID-URL recipient has a short time preference for resolution, then there is guaranteed to be a matching short-time-preference communication channel through which they received that URL. The initial state can easily be published through the same channel. For example, by wrapping it in a JSON payload: Just like VCs didn't depend on the eventual realization of DIDs, nor did they require specific crypto suites, there's no need, IMO, to put an initial state in the URL when the use cases that need such a feature can achieve it through the same communication channel already in place. In short, we are conflating meta-data that is useful but communicable through other means with the data required to use a DID at all. This feels like an optimization parameter one might send to a resolver rather than a requirement for the DID to work at all. To wit: if the DID is going to be presented in a long-time-preference medium (blog post, business card, billboard, video credits, etc.), then there is no advantage to initial state. The initial state is useful when and only when there is a relatively short period of time between DID registration and DID resolution. That short time period implies that there is a communication channel, which could easily afford @csuwildcat his needed initial state without the burden of parameters (matrix or otherwise). |
|
I disagree with @jandrieu's last statement of apparent certainty about this use case, the needs that motivate it, or the issues with sending strings required for resolution via random, non-standard communications channels/payloads. I only needed to say that so folks would not walk away thinking Joe's comments accurately reflect the technical needs and implications of this use case, or the view of most folks involved in these developments. That out of the way, I don't feel this Issue should be the place where we continue to discuss this need; I would suggest instead that we all focus on settling the issue of including a parameter mechanism (which the bulk of the community seems to be in favor of), given it would solve this Issue without any further discussion of this particular usage. |
|
There are features which some of us need, which are fulfilled via DID Parameters. Regardless of the mechanism for delivering these parameters, some of them will be used at resolution time. DIDComm, Sidetree, DIDPeer, and this proposal for did:key all take this approach: Since the specifics of DID Method Implementation are outside of this WG, we cannot create statements in the core spec, about what a Method can and cannot do with a did parameter... we know that they will be available to the method at the time of resolution, and we know we are not in control of defining the specific process of resolution in for example: How a method handles what comes after the method... is the methods business... and people are already relying on this behavior today: https://github.com/decentralized-identity/ethr-did-resolver/blob/develop/doc/did-method-spec.md I think this issue has become about things that are none actionable, and is blocked... entirely... by the matrix parameter discussion, and agreement that method implementers are free to define how a method is implemented. I suggest we close this issue, have the discussion regarding DID parameters, and acknowledge that any handling of DID Params that is method specific, is outside of the control of this WG, and cannot be blocked by this wg, so long as the format of the parameters complies with the did core spec. |
|
As the one who opened this issue, I don't see any further need to discuss it at this level, given the eventual mechanism it would rely on is far more general. Furthermore, as Orie notes, this is not something the WG or its members should dictate to Method implementers, so once we have a solution for the variant of parameters DIDs can use to pass resolution-related values of any kind, it will naturally satisfy this need. |
|
Reopening, as the direction/mechanics of parameters cannot fulfill the need. |
|
This issue is related to #431 and will be resolved once that issue is resolved. This issue needs a special topic call. This is a high priority issue before CR as it could affect normative sections of the specification. |
msporny
added
needs special call
|
This will be resolved once PR #431 is merged in. |
In Sidetree-based DID Methods, there are two forms of ID strings for the same identifier:
Long-Form ID: Base64_Initial_DID_Doc
Short-Form ID: SHA256_Hash_Of_Base64_Initial_DID_Doc
The use case for this is that in more robustly decentralized systems, commitment is delayed by consensus, which can take 30 seconds, or even minutes. That said, there is still a desire to immediately use an ID, which is what the Long-Form ID above allows. By passing the Long-Form ID to an RP or Issuer, the system can resolve the ID to its latest state (assuming it is registered and can be found by its Short-Form equivalent), or, if it has not yet been registered/broadcast, it can resolve via return of the initial DID Document that comprises the ID string.
Presently the DID spec seems to prohibit Methods from supporting multiple ID string forms of the same DID with the language found in the Binding of Identity section:
We would like to support the notion of both forms being equivalents, given the Long-Form hashes to the Short-Form, making them provably synonymous. Was the DID spec written with this in mind, or is this something new to consider?
The text was updated successfully, but these errors were encountered: