Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable instant DID use/resolution for DID Methods that include a propagation delay #70

Open
csuwildcat opened this issue Oct 14, 2019 · 22 comments
Assignees
Labels

Comments

@csuwildcat
Copy link
Contributor

@csuwildcat csuwildcat commented Oct 14, 2019

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:

Proving control of a DID, i.e., the binding between the DID and the DID Document that describes it, requires a two step process:

1. Resolving the DID to a DID Document according to its DID method specification.
2. Verifying that the id property of the resulting DID Document matches the DID that was resolved.

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?

@OR13

This comment has been minimized.

Copy link

@OR13 OR13 commented Oct 14, 2019

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 did:key or other self certifying methods such as did:ethr, given a Long-Form ID, it should be possible to verify a JSON-LD Signature attributed to it, because the identifier contains key material.

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.

@talltree

This comment has been minimized.

Copy link
Contributor

@talltree talltree commented Oct 15, 2019

@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:

  1. Both DIDs asserted as equivalent would be defined by the same DID method.
  2. Equivalence can be proved algorithmically.

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.

@peacekeeper

This comment has been minimized.

Copy link
Contributor

@peacekeeper peacekeeper commented Oct 15, 2019

So it seems the key question is: If you resolve did:ex:1234, could you get back a DID Document with an id that is different from did:ex:1234? Right now the spec doesn't allow that, and I feel it would be problematic from a URI/RDF perspective.

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 did:ex:<long-form>, you would get:

{
  "@context": "https://w3id.org/did/v1",
  "id": "did:ex:<long-form>",
  "redirect": "did:ex:<short-form>",
  .. services and public keys ..
}

Semantically, there's a slight difference between stating "equivalence" and "redirect". The former would be a bit like an owl:sameAs statement in RDF, whereas the latter would be a bit like an HTTP 303 code. Mastodon has a property as:movedTo for redirecting to a new account.

The above would instruct a client to use did:ex:<short-form> from now on.

Also see w3c-ccg/did-resolution#36.

@csuwildcat

This comment has been minimized.

Copy link
Contributor Author

@csuwildcat csuwildcat commented Oct 15, 2019

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 redirect, given the IDs in Sidetree-based DID Methods, for example, are exact equivalents that represent the exact same ID in the system. I like equivalent or alias, personally.

@csuwildcat

This comment has been minimized.

Copy link
Contributor Author

@csuwildcat csuwildcat commented Oct 15, 2019

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 canonical value that expressed this sort of relationship - would folks here be open to adding a canonical property that, if present, indicates a unidirectional pointer to the canonical form of the ID the resolving party should use going forward?

@peacekeeper

This comment has been minimized.

Copy link
Contributor

@peacekeeper peacekeeper commented Oct 15, 2019

Markus mentioned that XDI had a canonical value that expressed this sort of relationship

Quick correction.. What I said was that XRDS (not XDI) had a <EquivID> and a <CanonicalID> element. The latter was unidirectional, and you could have only one of it. In XDI, very similar constructs exist, they are called $is and $ref.

@csuwildcat

This comment has been minimized.

Copy link
Contributor Author

@csuwildcat csuwildcat commented Oct 16, 2019

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: init, and a DID Resolution metadata field: published. These two items would include the following specification language and directives:

  • init - Value(s) a DID Method and its resolver code may utilize to process DIDs that are in an 'unpublished' state, not yet anchored/propagated in the underlying trust system a Method uses.
  • published - Boolean applied by the DID Method's resolving code indicating whether or not the DID that was resolved has been anchored in the underlying trust system. When this metadata field is returned true from the resolving code, the party performing the resolution MAY choose to discard the init parameter from any held references to the DID in question.
@csuwildcat

This comment has been minimized.

Copy link
Contributor Author

@csuwildcat csuwildcat commented Oct 18, 2019

If there are no objections, I intend to fork the current spec and create a PR for the addition of the init Matrix Parameter to the Generic DID Parameter list. Please respond with any feedback about this direction before the next WG meeting to ensure we fully consider all points of view.

@csuwildcat csuwildcat changed the title Allow for DID Methods that support multiple forms of the same identifier Allow for instant DID use/resolution for DID Methods that include a propagation delay Oct 18, 2019
@csuwildcat csuwildcat changed the title Allow for instant DID use/resolution for DID Methods that include a propagation delay Enable instant DID use/resolution for DID Methods that include a propagation delay Oct 18, 2019
@peacekeeper

This comment has been minimized.

Copy link
Contributor

@peacekeeper peacekeeper commented Oct 18, 2019

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.

@OR13

This comment has been minimized.

Copy link

@OR13 OR13 commented Oct 18, 2019

There was a discussion about a similar approach for did:git at IIW. I like the language for init. I don't fully understand the other side published or how a method resolve interface is able to respond to matrix parameters generally.

@csuwildcat

This comment has been minimized.

Copy link
Contributor Author

@csuwildcat csuwildcat commented Oct 18, 2019

@OR13 the published metadata field is something the DID Method's resolving code would be aware of and include when it resolves a DID. This resolution metadata field would always be populated by methods that seek to employ it, and would be present regardless of whether or not the init Matrix Parameter was included on the DID being resolved. Just think of published as a generic indicator that all Methods can use for signalling the anchored/not anchored state of a DID, irrespective of this particular utilization of that indication.

@thehenrytsai

This comment has been minimized.

Copy link

@thehenrytsai thehenrytsai commented Oct 18, 2019

Can we consider renaming init to initial-values or initial-state as init typically means "initialize" or "initialization" in the programming world?

@csuwildcat

This comment has been minimized.

Copy link
Contributor Author

@csuwildcat csuwildcat commented Oct 18, 2019

@thehenrytsai of the two you mentioned, I like initial-values.

@peacekeeper

This comment has been minimized.

Copy link
Contributor

@peacekeeper peacekeeper commented Oct 18, 2019

I wonder if init could be generalized to specify a DID document that is returned not only until the DID is anchored/propagated, but also if for some other reason the DID cannot be resolved. The parameter could be called fallback or default instead of init. But I guess the behavior I am describing is a bit different than what you have in mind.

@peacekeeper

This comment has been minimized.

Copy link
Contributor

@peacekeeper peacekeeper commented Oct 18, 2019

I don't fully understand the other side published or how a method resolve interface is able to respond to matrix parameters generally.

+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?

@csuwildcat

This comment has been minimized.

Copy link
Contributor Author

@csuwildcat csuwildcat commented Oct 18, 2019

I wonder if init could be generalized to specify a DID document that is returned not only until the DID is anchored/propagated, but also if for some other reason the DID cannot be resolved. The parameter could be called fallback or default instead of init. But I guess the behavior I am describing is a bit different than what you have in mind.

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.

@csuwildcat

This comment has been minimized.

Copy link
Contributor Author

@csuwildcat csuwildcat commented Oct 18, 2019

I don't fully understand the other side published or how a method resolve interface is able to respond to matrix parameters generally.

+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?

Sorry that I mixed this up - what I meant is that published is a field in the resolved metadata, which the DID Method's resolving code would return (because obviously it is the thing aware of whether a DID has been published/anchored).

@OR13

This comment has been minimized.

Copy link

@OR13 OR13 commented Oct 18, 2019

@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 initial-values is a method specific matrix param.

Seems like we could do:

A. Generic matrix param + DID Document Extension
B. Method Specific Matrix Param + Resolver Meta Data

A seems definitely in this working group, I'm not sure about B, but it seems like its potentially less difficult to accomplish.

@peacekeeper

This comment has been minimized.

Copy link
Contributor

@peacekeeper peacekeeper commented Oct 18, 2019

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

@cboscolo

This comment has been minimized.

Copy link

@cboscolo cboscolo commented Oct 18, 2019

+1 I do think this proposal would be a generic matrix parameter rather than method-specific.

@csuwildcat

This comment has been minimized.

Copy link
Contributor Author

@csuwildcat csuwildcat commented Oct 18, 2019

@yancyribbens

This comment has been minimized.

Copy link

@yancyribbens yancyribbens commented Nov 2, 2019

+1 also that this request would be part of the DID resolution protocol. Also, it seems like the default param would be published if not specified. If ledgers and chains that use a more decentralized protocol that requires propagation, then initial-values can be used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.