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

Confusion regarding threshold for DID controllers #839

Open
Vishwas1 opened this issue Feb 9, 2023 · 6 comments
Open

Confusion regarding threshold for DID controllers #839

Vishwas1 opened this issue Feb 9, 2023 · 6 comments
Assignees
Labels
class 2 Changes that do not functionally affect interpretation of the document ready for pr Issue is ready for a PR

Comments

@Vishwas1
Copy link

Vishwas1 commented Feb 9, 2023

Was reading this section of DID core,

https://www.w3.org/TR/did-core/#group-control

In the case of group control, the DID controllers are expected to act together in some fashion, such as when using a cryptographic algorithm that requires multiple digital signatures ("multi-sig") or a threshold number of digital signatures ("m-of-n").

I am confused about, where exactly we will specific that policy m-of-n or m-of-m or whatever in the DID document?

@OR13
Copy link
Contributor

OR13 commented Feb 9, 2023

@Vishwas1 Only certain DID Methods might support this feature, for example, a method based on ethereum multi sig.

@kdenhartog
Copy link
Member

I can understand the confusion here. This would effectively need to be defined under the method which specifies a verification method suite for using a multi sig and then also defining how the DID document will model the data of this, and also how the VDR will verify this data using the DID Document. In this case, all of these are extension features so there really shouldn't have been mention of this in DID Core.

@msporny msporny added the class 2 Changes that do not functionally affect interpretation of the document label Jul 1, 2024
@decentralgabe
Copy link
Contributor

The group discussed and agreed language should be improved on leaving this up to DID Methods / where the policy should be defined.

@decentralgabe decentralgabe added the ready for pr Issue is ready for a PR label Dec 6, 2024
@w3cbot
Copy link

w3cbot commented Dec 6, 2024

This was discussed during the #did meeting on 06 December 2024.

View the transcript

w3c/did-core#839

decentralgabe: This is about how to specify multisig -- need to clarify?

decentralgabe: Doesn't say where logic is defined, keep open and improve language.

<shigeya> +1

manu: Yes, that sounds good.


@peacekeeper
Copy link
Contributor

There is a verification method type which can do this: https://github.com/w3c-ccg/verifiable-conditions

@peacekeeper peacekeeper self-assigned this Dec 19, 2024
@w3cbot
Copy link

w3cbot commented Dec 19, 2024

This was discussed during the #did meeting on 19 December 2024.

View the transcript

w3c/did-core#839

manu: we don't define how you do mutisig in the DID spec.
… We should probably say that multisig is defined by the verification mechanism.

<JoeAndrieu> +1 to Manu's summary

manu: We should add some language pointing to verification methods and cryptosuite, and not say anything more.

markus_sabadello: there is a verification that some people have worked one, "conditional proof" or something like that.
… It is a CCG work item, I will link it to this issue.
… And I can take care of this issue.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
class 2 Changes that do not functionally affect interpretation of the document ready for pr Issue is ready for a PR
Projects
None yet
Development

No branches or pull requests

7 participants