Support for threshold multi-sig verificationMethod

[ghost]

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:

key 1 weight = 1,
key 2 weight = 2,
key 3 weight = 3,

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

{
    "perm_name": "owner",
    "parent": "",
    "required_auth": {
        "threshold": 3,
        "keys": [{
            "key": "7idX86zQ6M3mrzkGQ9MGHf4btSECmcTj4i8Le59ga7CpSpZYy5",
            "weight": 1
        }, {
            "key": "7G5AXPP4RNG5DiZACneMZVenYEQ2GmVwcYUis8YrFHorQic5h8",
            "weight": 2
        }, {
            "key": "7NFuBesBKK5XHHLtzFxm7S57Eq11gUtndrsvq3Mt3XZNMTHfqc",
            "weight": 2
        }]
    }
}

EOSIO account DID Document - Proposal 1

{
    "@context": "https://www.w3.org/ns/did/v1",
    "id": "did:eosio:telos:example",
    "controller": "did:eosio:telos:example",
    "verificationMethod": [{
            "id": "#owner-0",
            "controller": "did:eosio:telos:example",
            "type": "WeightedEd25519…",
            "publicKeyBase58": "7idX86zQ6M3mrzkGQ9MGHf4btSECmcTj4i8Le59ga7CpSpZYy5",
            "weight": 1
        }, {
            "id": "#owner-1",
            "controller": "did:eosio:telos:example",
            "type": "WeightedEd25519…",
            "publicKeyBase58": "7G5AXPP4RNG5DiZACneMZVenYEQ2GmVwcYUis8YrFHorQic5h8",
            "weight": 2
        }, {
            "id": "#owner-2",
            "controller": "did:eosio:telos:example",
            "type": "WeightedEd25519…",
            "publicKeyBase58": "7NFuBesBKK5XHHLtzFxm7S57Eq11gUtndrsvq3Mt3XZNMTHfqc",
            "weight": 2
        }
    ]
}

Notes

• New verificationMethod type required to specify "weight" property
• !!!Threshold for acceptance is not recognizeable

EOSIO account DID Document - Proposal 2

{
    "@context": "https://www.w3.org/ns/did/v1",
    "id": "did:eosio:telos:example",
    "controller": "did:eosio:telos:example",
    "verificationMethod": [{
        "id": "#owner",
        "controller": "did:eosio:telos:example",
        "type": "ThresholdVerificationMethod",
        "threshold": 3,
        "verificationMethod": [{
                "id": "#owner-0",
                "controller": "#owner",
                "type": "WeightedEd25519...",
                "publicKeyBase58": "7idX86zQ6M3mrzkGQ9MGHf4btSECmcTj4i8Le59ga7CpSpZYy5",
                "weight": 1
        }, {
                "id": "#owner-1",
                "controller": "#owner",
                "type": "WeightedEd25519...",
                "publicKeyBase58": "7NFuBesBKK5XHHLtzFxm7S57Eq11gUtndrsvq3Mt3XZNMTHfqc",
                "weight": 2
        }, {
                "id": "#owner-2",
                "controller": "#owner",
                "type": "WeightedEd25519...",
                "publicKeyBase58": "7NFuBesBKK5XHHLtzFxm7S57Eq11gUtndrsvq3Mt3XZNMTHfqc",
                "weight": 3
        }]
}

Notes

• New verificationMethod type required to specify "weight" property
• All thershold multi-sig information required to verify txs/events exists
• !!!New verificationMethod schema (potential DID core change)

For the EOSIO use case, some information is redundant and could be removed. Though this may not apply to all use cases

{
    "@context": "https://www.w3.org/ns/did/v1",
    "id": "did:eosio:telos:example",
    "controller": "did:eosio:telos:example",
    "verificationMethod": [{
        "id": "#owner",
        "controller": "did:eosio:telos:example:123",
        "type": "ThresholdVerificationMethod",
        "threshold": 3,
        "keys": [{
                "type": "WeightedEd25519...",
                "publicKeyBase58": "7idX86zQ6M3mrzkGQ9MGHf4btSECmcTj4i8Le59ga7CpSpZYy5",
                "weight": 1
        }, {
                "type": "WeightedEd25519...",
                "publicKeyBase58": "7NFuBesBKK5XHHLtzFxm7S57Eq11gUtndrsvq3Mt3XZNMTHfqc",
                "weight": 2
        }, {
                "type": "WeightedEd25519...",
                "publicKeyBase58": "7NFuBesBKK5XHHLtzFxm7S57Eq11gUtndrsvq3Mt3XZNMTHfqc",
                "weight": 3
        }]
}

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

[msporny]

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.

[peacekeeper]

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.

[peacekeeper]

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

[kdenhartog]

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.

[msporny]

@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 [email protected] 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.

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

[peacekeeper]

Closing per consensus after discussion on yesterday's DIF I&D WG call. Also see #697.

[iherman]

The issue was discussed in a meeting on 2021-03-02

• no resolutions were taken

View the transcript

4.1. Resolve Issues 693,694, 695, and 697

See github issue #693, #694, #695, #697.

Manu Sporny: four issues that we need to talk about briefly today
… we had invited the issue creator, Jack Tanner, to the call. Jack are you here?
… What we are trying to do is close these while making sure the group considered them.
… Several feel that these are well represented in the spec already.

Markus Sabadello: we had a call within the DIF yesterday
… in one of the working groups working on this
… we came to the conclusion that Jack's use case could be addressed by adding a new cryptosuite or verification method
… we don't believe we need any changes to the current spec
… These first three should be fine.
… #697 was more about the controller property on verification methods
… Conclusion is that while it might be hard to understand that property, there isn't a need to change the specification.
… Speaking on behalf of Jack, I'll write a summary and close the issues

Manu Sporny: Thanks, Markus. Please comment & close.
… if we close those, then that's all we need to handle before we go to CR.

Markus Sabadello: Just closed issues 693, 694, 695, 697.