Support for delegated verificationMethods

[ghost]

Problem
DID core Currently does not support delegated authorizations.

This is where a verification Method delegates to a different DID's verification Method.
Example:
The "did:eosio:telos:example#owner" verification is accepted as valid if the event/tx passes validation according to "did:eosio:telos:example2#active"

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.

See issue #693 goes through the multi-sig Support of DID core with an EOSIO use case.

Example EOSIO account permission
This is for the EOSIO account "example", where "example2" is being delegated to. This could also be from a different DID method.

{
    "perm_name": "owner",
    "parent": "",
    "required_auth": {
        "accounts": [{
            "permission": {
                "actor": "example2",
                "permission": "active"
            }
        }]
    }
}

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": "DelegatedAuthority",
            "delegate": "did:eosio:telos:example2#active",
        }]
}

Notes

• New verificationMethod type required to specify "delegate" property

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]

@gimly-jack wrote:

DID core Currently does not support delegated authorizations.

DID Core currently supports two mechanisms for delegating authorizations:

1. Specifying a controller for the DID Document; all verification methods for the controller are then applied to the current DID Document (although, a DID Method can choose to not allow this or restrict this in certain ways).
2. The controller of the DID Document places the delegate's verification method into the DID Document (see example below).

For the second item, you can do this:

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  
  "authentication": [{
    "id": "did:example:delegate123#keys-1",
    "type": "Ed25519VerificationKey2018", 
    "controller": "did:example:delegate123",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }], 
}

However, you should also be aware of and consider the use of Authorization Capabilities to do fine-grained cryptographic delegation:

https://w3c.github.io/did-core/#capability-delegation

That mechanism allows arbitrary and attenuated delegation for a variety of use cases and scenarios and should probably be the solution that you look to first before doing the more "sledgehammer"-based approaches above.

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 at least 3 different types of delegation and 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.

[ghost]

Thanks @msporny. As mentioned, I have an upcoming call next week to dive into this incl. with @peacekeeper. I think it would be good to keep these open till after then, and I will look into the resources you have linked.

[msporny]

I think it would be good to keep these open till after then, and I will look into the resources you have linked.

You have engaged the WG right as we're transitioning to Candidate Recommendation, which means that we need to process this issue. Keeping it open w/o a determination would delay the specification from reaching the next milestone (and we're behind schedule). Had we received your concerns a few weeks ago, we could have spent more time discussing with you. This is just a matter of bad timing (but the good news is that there are solutions to your concerns that do not require any changes to DID Core).

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