Potential problems with requiring "controller" for "verificationMethod"

[peacekeeper]

Right now, verification methods MUST include a controller property. However, I believe this could be problematic for two reasons:

1. As we know, the DID subject is not necessarily the same as the DID controller (see C.8.2). My understanding has furthermore always been that the controller doesn't necessarily need to have their own DID. Therefore it is unclear what the value of the controller property under a verificationMethod should be in such a case.
2. A DID may have multiple controllers that can control a DID by acting together (see C.9.2). While defining concrete verification methods that enable this is out-of-scope (see e.g. Support for threshold multi-sig verificationMethod #693), it actually feels impossible to ever support this if a single DID is REQUIRED as a controller of a verificationMethod.

Therefore I wonder if controller under verificationMethod should be optional, just like it is optional for the DID document itself.

I don't remember why it was made required in the first place. Maybe @dlongley or @msporny can comment?

[peacekeeper]

Also pinging @talltree

[msporny]

I don't remember why it was made required in the first place. Maybe @dlongley or @msporny can comment?

If a verification method doesn't specify it's controller, there is no way to establish a bi-directional relationship between the controller and the verification method. If you can't establish a bi-directional relationship, you can't tell where to look for the key (to establish the bi-directional relationship). That is, you can't depend on the key identifier because key identifiers are opaque, so you need to have it explicitly defined. If we didn't require the property, we open up a ton of potential attacks that we'd then have to figure out how to deal with.

This is not a bug or an oversight, it's a critical security feature; I suggest we mark this as pending close.

[msporny]

it actually feels impossible to ever support this if a single DID is REQUIRED as a controller of a verificationMethod.

A single DID can have multiple controllers. A DID Document can have verification methods that support threshold signatures, see issue #693. This is supported in the spec today.

[TallTed]

• As we know, the DID subject is not necessarily the same as the DID controller (see C.8.2). My understanding has furthermore always been that the controller doesn't necessarily need to have their own DID. Therefore it is unclear what the value of the controller property under a verificationMethod should be in such a case.

It appears to me that your question hinges on "the controller doesn't necessarily need to have their own DID".

That's correct; they don't need to have a DID.

But as @msporny said, it's necessary to identify the controller, so the controller does need to be identifiable by some URI, and that URI — DID, CID, or otherwise — should be (one of) the value(s) of the controller property.

Is a non-DID identifier for the controller a potential weakness in security or privacy? Sure. Might be we need another sentence or three in those areas.

[peacekeeper]

there is no way to establish a bi-directional relationship between the controller and the verification method

I guess I don't really understand what this means, since the verification method is included in the DID document, which is controlled by the DID controller. It's not intuitive to me that a DID controller must have their own DID.

With this requirement, it's also not clear to me how one would implement Group Control.

it's necessary to identify the controller, so the controller does need to be identifiable by some URI

Right now, every verificationMethod MUST have a controller property and it MUST be a DID. Perhaps change that to 1. allow multiple controllers, and/or 2. allow any URI (not just DID)?

[TallTed]

Right now, every verificationMethod MUST have a controller property and it MUST be a DID.

Ah, I see. I think that may have been an error.

Perhaps change that to 1. allow multiple controllers, and/or 2. allow any URI (not just DID)?

I believe the first is already true (unless the error is larger than it first seems), and the second should be (again, with appropriate security and privacy flags).

(ETA -- I'm not sure whether allowing any URI is required; there may be reason to forbid relative URIs and only accept absolute URIs, here. Relative URIs might just demand different security/privacy warnings.)

[peacekeeper]

Simple use case from C.8.2: A parent creates a DID for their child. The parent holds the private key that was used to create the child's DID. Parent = DID controller. Child = DID subject.

In such a case, in my opinion, there should be no need for the parent to have their own DID, or any other URI, and there is no need to use the controller property on either the DID document or the verification method.

[TallTed]

The parents subsequently divorce with hostility, remarry, step-parent starts adoption procedures, and there's a complicated custody order.

Now there's a need for the child's DID to have a controller (probably identifying multiple parents, but possibly just identifying the judge in the case), and for all parents (birth, custodial, adoptive, etc.) to be identifiable by DID (or other URI).

Without having set a controller at DID creation time, the child's DID and associated DID document are immutable. That's troublesome.

[talltree]

@peacekeeper Based on my understanding of the discussion on the Editor's call today, if the value of this controller property within a verificationMethod is set to the same DID as the DID document in which the verificationMethod appears, then whomever is the controller of that DID document is the controller for that specific verificationMethod.

If that DID document itself contains a top-level controller property, then the DIDs listed there (which may be more than one) are the multiple controllers.

And if there is no top-level controller property in that DID document, then any verification method in the DID document that supports multi-sig of some kind can support multiple controllers.

Do I have that right?

(And if I do, this explanation together with the other conclusions in this thread should be reflected in the final section of the appendix topic on multiple DID controllers.)

[msporny]

Based on my understanding of the discussion on the Editor's call today, if the value of this controller property within a verificationMethod is set to the same DID as the DID document in which the verificationMethod appears

Often, but not always. I wouldn't focus on the edge cases, where someone would choose to put someone else's verification method in their DID Document. It's possible, but it'll just confuse readers to have that explained to them w/o a concrete use case... and the concrete use cases we have for that are a bit shaky -- like multi-sig "break in case of emergency" use cases (that might be better solved using ZCAPs and EDVs).

then whomever is the controller of that DID document is the controller for that specific verificationMethod.

Yes.

If that DID document itself contains a top-level controller property, then the DIDs listed there (which may be more than one) are the multiple controllers.

Yes, and it's up to the DID Method and LD Security specifications to really detail what that means. In some cases, DID Methods will choose to use controller for DID Document updating/control. In other cases, Verification Methods might allow using DID Document controllers for certain types of authn. There are many use cases that we're not highlighting and we should probably not speak to these things as we haven't seen libraries implemented for these more advanced use cases yet (even though they are contemplated).

And if there is no top-level controller property in that DID document, then any verification method in the DID document that supports multi-sig of some kind can support multiple controllers.

Yes.

Do I have that right?

Yes.

(And if I do, this explanation together with the other conclusions in this thread should be reflected in the final section of the appendix topic on multiple DID controllers.)

I'm a bit iffy on doing that... for example, we /could/ have multiple controllers for a single verification method as well... we've chosen not to do that in this go-around because we'd have to have a number of philosophical discussions to reason through what that means for all the verification methods that we know about (and contemplate in the future). I'd rather wait until we have some actual multi-sig verification methods before doing that so we're speaking based off of implementation experience rather than just postulating about what could be. I know the latter is important, but exposing folks to too much might lead to more confusion than anything.

[msporny]

Based on the discussion we had yesterday, where the conclusion was "No, controller is required and removing it opens up new security attacks that we're deeply concerned about.", I'd like to close this issue. Making controller not required would lead to a number of formal objections because it would destroy the security characteristics of verification methods -- and that would put us into a position of "no spec would be better than a spec that creates a false sense of security" -- thus the formal objections.

I'm going to restart the pending close countdown, folks should feel free to object to closing it if they feel like something non-editorial needs to be done with the spec. Editorial changes, like the ones @talltree is suggesting, can always be made during CR.

[jandrieu]

I support closing this without changes. But I think it is important to note that the "controller" property does NOT make a DID the controller of that verification method. The actual controller is whoever can change the DID Document per the DID method. When we set the controller property of a verification method to the DID of that DID Document, we are NOT saying that the subject of the DID is the controller, we are simply saying there are other DID Documents where you might look up valid verification methods. [NOTE: this sentence use to say "...there are NO other DID Documents..." I meant the opposite. The controller value means you should look up those DID Documents for additional verification methods.]

When @msporny wrote DID Document controllers he conflated the value of the "controller" property at the top level of the document with the actual controllers who are able to change the DID.

TLDR: the value of the "controller" property does not specify who the Controller of a DID Document is.

I have always felt this conflation of terms is enough of a problem to use a different property name, but have never gotten buy in from the core JSON-LD advocates, for whom "controller" has functional semantics.

Just note: this misunderstanding WILL continue as DIDs roll out to wider use and deployment. Be prepared for it.

[agropper]

Apologies for not following this issue until now. I'm curious for the Notarization use-case, where, for example, a controller can make arbitrary changes but they need to be witnessed and audited by an independent entity. Adrian

…

On Fri, Feb 26, 2021 at 1:17 PM Joe Andrieu ***@***.***> wrote: I support closing this without changes. But I think it is important to note that the "controller" property does NOT make a DID the controller of that verification method. The *actual* controller is whoever can change the DID Document per the DID method. When we set the controller property of a verification method to the DID of that DID Document, we are NOT saying that the subject of the DID is the controller, we are simply saying there are NO other DID Documents where you might look up valid verification methods. When @msporny <https://github.com/msporny> wrote DID Document controllers he conflated the value of the "controller" property at the top level of the document with the actual controllers who are able to change the DID. TLDR: the value of the "controller" property does not specify who the Controller of a DID Document is. I have always felt this conflation of terms is enough of a problem to use a different property name, but have never gotten buy in from the core JSON-LD advocates, for whom "controller" has functional semantics. Just note: this misunderstanding WILL continue as DIDs roll out to wider use and deployment. Be prepared for it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#697 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YOAWGSWQFJR3CQWDVLTA7QRVANCNFSM4YC3CJ2Q> .

[peacekeeper]

TLDR: the value of the "controller" property does not specify who the Controller of a DID Document is.

@jandrieu thanks. Furthermore, as I understand it now based on some conversations from last week, the subject identified by the "controller" property is not necessarily the holder of the private key(s) corresponding to the verification method.

I have always felt this conflation of terms is enough of a problem to use a different property name

I think I agree, this is probably what confused me too. It requires pretty deep understanding of JSON-LD.

I'd like to close this issue

@msporny based on the conversations above, I am fine with closing. One of the DIF Working Groups will still discuss this as well as #693, #694, #695 today (see agenda). If no additional concerns come up during that meeting, then I also propose closing these issues.

[peacekeeper]

We discussed this on the DIF call today, and we agreed we can close this.

@gimly-jack I think you agreed to that as well.

[ghost]

Yes, please close the 3 issues.

[peacekeeper]

Closing per consensus after discussion on yesterday's DIF I&D WG call.

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