Closed ghost closed 3 years ago
DID core Currently does not support a threshold based multi-party signature authorisation scheme.
The place to define this is NOT the DID Core specification because:
What you'd need to do is create a new Verification Method cryptosuite -- e.g., https://w3c-ccg.github.io/lds-ed25519-2020/
You can do this by:
Once you've been able to do all of those things, there is an option of putting your specification on the W3C global standards track via the W3C Credentials Community Group.
Does that provide a path forward for you @gimly-jack? If so, can we close this issue as this WG is not going to be able to act on your request at this point in time.
I agree with @msporny that this doesn't belong into DID Core, and that instead we can discuss this in other places such as DIF or CCG, and if needed, define and register extensions that can do this.
Quick note that Proposal 2 is invalid with today's spec language, since the value of controller
under verificationMethod
must be a DID (not a relative URI like #owner
as shown in the proposal).
DID core Currently does not support a threshold based multi-party signature authorisation scheme.
The place to define this is NOT the DID Core specification because:
* We are feature frozen as of July 2020 * This Working Group is not chartered to create new cryptosuites * There is already an extension mechanism defined for this and you should use that
What you'd need to do is create a new Verification Method cryptosuite -- e.g., https://w3c-ccg.github.io/lds-ed25519-2020/
You can do this by:
* Creating a specification and publishing it somewhere -- the W3C Credentials Community Group has a process for doing this -- https://docs.google.com/document/d/1vj811aUbs8GwZUNo-LIFBHafsz4rZTSnRtPv7RQaqNc/edit#heading=h.i2v9iagxg4em * Creating an implementation of your specification * Creating a test suite for your specification that other implementers can test against * Convincing others to implement your specification against the test suite
Once you've been able to do all of those things, there is an option of putting your specification on the W3C global standards track via the W3C Credentials Community Group.
Does that provide a path forward for you @gimly-jack? If so, can we close this issue as this WG is not going to be able to act on your request at this point in time.
Additionally cross registering the verificationMethod published elsewhere to the did-specification-registries would be a good step to let other did implementors who wish to be interoperable with that verification method would be good.
@gimly-jack, the Chairs and Editors discussed this on our weekly call. @peacekeeper will provide feedback through the DIF group you're in on Monday. We will most likely close this issue on the Tuesday call (for the reasons cited above), but welcome you to join the weekly call next Tuesday at 11am ET so we can provide the rationale above to you in person. We have an absolutely packed Agenda, and your attendance is optional, so won't be able to spend a ton of time on your issues, but wanted to extend the offer to you as a professional courtesy. Send me an email at msporny@digitalbazaar.com
for the telecon connection information. As an alternative, if you feel the issues are resolved on the Monday DIF call, you can relay your thoughts via @peacekeeper.
@gimly-jack based on today's DIF call, are you okay with closing this, and working on a new crypto suite / verification method that implements this functionality instead?
Closing per consensus after discussion on yesterday's DIF I&D WG call. Also see https://github.com/w3c/did-core/issues/697.
The issue was discussed in a meeting on 2021-03-02
Problem DID core Currently does not support a threshold based multi-party signature authorisation scheme.
This is where a verification method is excepted if a quorum of signatures from a predefined set are found. Example 1: if signatures for 2 out of 3 specified public keys are required to create a valid the tx/event. Example 2: If a threshold of 3 is met from the signatures of three specified public keys with different weightings as follows:
In this case signatures of key 1 + 2, or key 3, or key 1 + 2 + 3 are required to create a valid tx/event.
Use case example - EOSIO account One use case for this is support for the EOSIO DID spec, where accounts have hierarchical trees of threshold based authoritizes including multi-sig and delegated authority. eoscanadacom is an example account showing this key structure on the existing EOS blockchain, which uses the EOSIO protocol.
Example EOSIO account permission
EOSIO account DID Document - Proposal 1
Notes
EOSIO account DID Document - Proposal 2
Notes
For the EOSIO use case, some information is redundant and could be removed. Though this may not apply to all use cases
More info This issue will be discussed at the ID Working Group meeting on 29 Feb.
For more information, check out these slides which go into this specific EOSIO use case: https://docs.google.com/presentation/d/1vrmdOnN1tiE54e8h7HyegkJUGyrBUITVFNsAVedUwTE