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

[Feature Request] Threshold multi-sig controller #42

Closed
iFergal opened this issue Mar 14, 2023 · 4 comments
Closed

[Feature Request] Threshold multi-sig controller #42

iFergal opened this issue Mar 14, 2023 · 4 comments
Assignees

Comments

@iFergal
Copy link

iFergal commented Mar 14, 2023

As an extension of #41, m-of-n multi-sig would be useful for control over a DID.

This also is referring to control over a DID document (so perhaps controller array and some threshold to meet).

Use-case examples:

Weighted votes would be even better - though this can become more cumbersome to express in a DID document (if it needs to).

@EzequielPostan
Copy link
Contributor

this are interesting features, as you point out, the more complex the logic, the harder the implementation.
Depending on use case, and the precise level of expressiveness needed, there would be different ways to implement it. It will be good to get more use cases and refine their needs

@iFergal
Copy link
Author

iFergal commented Mar 16, 2023

Yeah, I feel like something like this could have endless use cases, particularly in a business or legal context, or something in the IoT space. I'll try to think up some concrete ones.

As mentioned in #41 (comment) we can at least achieve n-of-n multi-sig with an array for did.controller.

One possible solution to make this (non-weighted) threshold multi-sig is a new top level property such as did.controllerThreshold (with some enforcement that the integer makes sense, given the length of did.controller).

The more refined weighted threshold multi-sig is as I said, more cumbersome to express, at least at the top-level of the DID document. Something I need to think about - maybe that is adding too much complexity.

@EzequielPostan
Copy link
Contributor

apologies here too for the delay

I think I should refer to the comment I left in #41 too

I think we should clarify that issue before this one.
Let me know @iFergal if I could close this issue or if I should keep it open. If inactive, I would prefer to keep it closed and reopen it once we have more input to add/discuss

Thank you again for the comments!

@EzequielPostan
Copy link
Contributor

I am closing the issue to keep a clean view of active ones
Feel free to re-open if needed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants