[Feature Request] Controller delegation

[iFergal]

It would be useful to be able to delegate control of a DID to another DID. (full control over the DID doc + keys)

• So allow specification of the top-level controller property.

As a sample, this would allow the simple parent-child use-case where a parent holds control over a child’s DID but the child can still hold control over its authentication etc keys. In case the child loses access to their keys, the parent can rotate them.

This is different from:

• Parent holding the private key associated with the child's MASTER_KEY - delegation should point to a DID to allow a separate rotation of keys on the parent's side.
• This is also different from capabilityDelegation as that is not for DID control.

This might also be useful in some specific IoT scenarios.

[EzequielPostan]

this is also an interesting one, and we had reviewed this in the past.
I remember this first conversation. If I am not mistaken, the conclusion at the time from conversations in DIF (Decentralized Identity Foundation) was that, beyond what the spec allows syntactically, for interoperability reasons, it was recommended to have did.id == did.controller and for each verification method respect did.verificationMethod[i].controller == did.controller. I cannot find a written reference :/, so I welcome to be corrected is this was/is wrong. Furthermore, the spec may have changed since last time I reviewed this topic, so I welcome news on this too.

At a quick glance, I can see this issue and this other one to clarify semantics about the controllers properties. It may be good to see that settle. We can of course, discuss here use cases and thoughts that we could bring to those W3C issues.

On this line, I unfortunately didn't understand this sentence:

Parent holding the private key associated with the child's MASTER_KEY - delegation should point to a DID to allow a separate rotation of keys on the parent's side.

could you elaborate a bit more? I didn't follow the part of "delegation should point to a DID to allow a separate rotation of keys on the parent's side."

Once again, thank you for opening issues and exchanging thoughts!

[iFergal]

Hmm, did.verificationMethod[i].controller == did.controller perhaps but I'm not so sure on did.id == did.controller. did.id is the identifier itself of the DID subject, and did.controller is the controller of the DID document.

DID subject and DID controller aren't the same, but they can be (and often are). I would say each DID (so did.id) has a MASTER_KEY (though the spec seems to allow for multiple, 1-of-n signature, not sure if that's intended), and that MASTER_KEY allows you to control any DID where did.controller = <did.id of controller with MASTER_KEY>.

This would allow you to delegate control of a DID document, and doesn't involve anything to do with the verificationMethods which is most of the discussion in those linked issues.

could you elaborate a bit more? I didn't follow the part of "delegation should point to a DID to allow a separate rotation of keys on the parent's side."

Here I meant that we are using did.controller in a DID document of the child, to point to the parent's DID. A worse alternative is to keep the spec as it is today, and the parent just happens to hold the MASTER_KEY of the child - this is kind of delegation, but not at the DID level but rather the key level. That allows the parent to update their MASTER_KEY irrespective of the child's DID document - so a parent of 6 children could use their 1 MASTER_KEY to control 6 DIDs (+their own) instead of holding 6 or 7 MASTER_KEYs.

You could very simply get n-of-n or 1-of-n multi-sig by allowing an array for did.controller, for example like cheqd do (they are n-of-n multi-sig). This is still in line with the did:core spec.

I need to review the issues you linked (and others that I can find) in more detail when I have the time though, as I might be missing something! :)

[EzequielPostan]

apologies for the delay here too

DID subject and DID controller aren't the same, but they can be (and often are). I would say each DID (so did.id) has a MASTER_KEY (though the spec seems to allow for multiple, 1-of-n signature, not sure if that's intended), and that MASTER_KEY allows you to control any DID where did.controller = <did.id of controller with MASTER_KEY>.

This would allow you to delegate control of a DID document, and doesn't involve anything to do with the verificationMethods which is most of the discussion in those linked issues.

so, if I understood correctly, the logic you are describing is:
The keys allowed to update a DID A, are the MASTER_KEYs of the DID in the A.controller field, correct? (and possibly A MASTER_KEYs too)

And, the difference you refer to is mostly at the point of displaying the delegation at the DID document, compared to just having the control without announcement (using the private key of the MASTER_KEY of the DID A)

A worse alternative is to keep the spec as it is today, and the parent just happens to hold the MASTER_KEY of the child - this is kind of delegation, but not at the DID level but rather the key level. That allows the parent to update their MASTER_KEY irrespective of the child's DID document - so a parent of 6 children could use their 1 MASTER_KEY to control 6 DIDs (+their own) instead of holding 6 or 7 MASTER_KEYs.

I should point that for the 7 DIDs (the parent's and the 6 children'), you could still use a single key by using the same key material in all the DIDs. Nothing forbids a key to be present in multiple DID documents.

Even though W3C mentions this type of behaviors, it is not that common to see in DID method implementations. The rules to control a DID are defined by each method, and the proposed logic may restrict some methods. For example, Sidetree.based DID methods, or KERI they tend to use key commitments, and not keys. And commitments are used only once in the system (not per DID), making a controller-like feature hard to implement (and I think Sidetree doesn't implement it).

Let me know if I understood the difference of using the key vs using controller field, what I am missing is a use case where the difference is needed.
I could also point out some issues:

• At first glance, it damages a bit privacy by adding correlation between DIDs
• More importantly, this "controller"'s semantics would create transitive relations that cannot easily be avoided. If A controls B, and B controls C, then A can add a MASTER_KEY to B's document and update C. In contrast, if A controls a private key of a MASTER_KEY in B's DID document, and B does the same with a MASTER_KEY in C's DID document, then A has no control over C unless B or C do something to allow it explicitly.
• The above type of logic would be even more complex with lists of controllers

A priori, I think the topic needs further refinement before updating the spec.

Do you think we should keep this issue open @iFergal? or should I close this and we can re-open it in the future if the topic gets new points?

As always, thank you for the comments and my apologies for the delay

[EzequielPostan]

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