Support for combination of threshold multi-sig and delegated verificationMethod

[ghost]

Backgroud
See issue #693 goes through the multi-sig support of DID core with an EOSIO use case.
See issue #694 goes through the delegated authority of DID core with an EOSIO use case.

Problem
DID core Currently does not support combinations of

• threshold based multi-party signature authorisation scheme
• delegated authorizations

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 EOS public blockchain, which uses the EOSIO protocol.

Example EOSIO account permission

{
    "perm_name": "owner",
    "parent": "",
    "required_auth": {
        "threshold": 2,
        "keys": [{
            "key": "7idX86zQ6M3mrzkGQ9MGHf4btSECmcTj4i8Le59ga7CpSpZYy5",
            "weight": 1
        }, {
            "key": "7G5AXPP4RNG5DiZACneMZVenYEQ2GmVwcYUis8YrFHorQic5h8",
            "weight": 2
        }],
        "accounts": [{
            "permission": {
                "actor": "example2",
                "permission": "active"
            },
            "weight": 1
        }]
    }
}

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",
        "controller": "did:eosio:telos:example",
        "type": "ThresholdVerificationMethod",
        "threshold": 2,
        "verificationMethod": [{
                "id": "#owner-0",
                "controller": "#owner",
                "type": "WeightedEd25519...",
                "publicKeyBase58": "7idX86zQ6M3mrzkGQ9MGHf4btSECmcTj4i8Le59ga7CpSpZYy5",
                "weight": 1
        }, {
                "id": "#owner-1",
                "controller": "#owner",
                "type": "WeightedEd25519...",
                "publicKeyBase58": "7G5AXPP4RNG5DiZACneMZVenYEQ2GmVwcYUis8YrFHorQic5h8",
                "weight": 2
        }],
        "delegationMethod": [{
                "id": "#owner-0",
                "controller": "#owner",
                "type": "WeightedDelegatedAuthority.",
                "delegate": "did:eosio:telos:example2#active",
                "weight": 2
        }]
    }]
}

For a tx/event using the above DID verificationMethod to be valid it would need to do one of the following:

• have a valid signature matching key "#owner-1"
• have a valid signature matching key "#owner-0" and additionally satisfy The verification method found at "did:eosio:telos:example2#active"

Notes

• !!!New verificationMethod schema (potential DID core change)

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 combinations of: threshold based multi-party signature authorisation scheme, delegated authorizations

As outlined in #693 (comment) and #694 (comment), the Working Group has been feature frozen since July 2020 and won't be adding new features to the specification at this point in time. The good news for you, though, is that the spec already supports extension points for new Verification Methods supporting multisig, and at least 3 different types of delegation and/or the particular type of delegation you want can be done external to the DID Core specification as an extension. For these reasons, I'm marking this issue as pending close -- please feel free to disagree with any of the above and provide rationale for why you'd like to keep this issue open.

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