Closed ghost closed 3 years ago
@gimly-jack wrote:
DID core Currently does not support delegated authorizations.
DID Core currently supports two mechanisms for delegating authorizations:
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).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.
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.
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 msporny@digitalbazaar.com
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.
@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?
Closing per consensus after discussion on yesterday's DIF I&D WG call. Also see https://github.com/w3c/did-core/issues/697.
The issue was discussed in a meeting on 2021-03-02
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.
EOSIO account DID Document - Proposal 1
Notes
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