Kyle Den Hartog <kyle.denhartog@mattr.global> wrote:> Additionally, the concept of adding a separate > controller's verification method into a DID > Document would effectively allow for the new > controller to represent their ability to act on > behalf of the subject.Unfortunately, this is a huge anti pattern that should not be promoted. The semantics are different than what you suggest. It does much more than allow the "new" controller to act on behalf of the subject: it makes the new controller indistinguishable from the other controllers, without distinction of who delegated to whom. E. G., the two could be peers set by the party in control of the DID Document, who may not even be listed as a formal controller. Yes, in a loosey goosey way, it approximates delegation, but it does not allow the accountability that best of class delegating mechanisms ensure. It isn't enough to just enable the specific positive affordance to trigger a cryptographic function (which you can do using the controller property as you suggest), delegation also needs to provide for accountability and restrictions regarding who delegated the ability to do what, to whom. Sadly, this is wrapped up in the semantic conflation of "controller" in the DID spec. It refers to both the role of the party in control of the DID document, as enforced by the VDR, *and* to other DIDs whose DID Document's verification relationships should be considered as if they were in this DID Document. The latter's semantics are closer to inclusion than delegation and absolutely will lead to security problems because so few understand how it actually works. Sent from my Galaxy
Received on Friday, 21 January 2022 06:40:42 UTC