Should the current DID (`id` of DID Doc) always be a controller?

[brianorwhatever]

Is this valid?

{"id": "did:tdw:123", "controller": "did:tdw:abc"}

[swcurran]

Is that not the "external controller" discussion? It is certainly a valid DIDDoc (per the DID Core spec), and since it is valid, it is why I would like to support include "reasonable" support for it. Per the requirements of the did:tdw, we need to find a key capable of being used to sign the DIDDoc.

To reiterate (and flog a sad horse...): 😄

• Per @andrewwhitehead 's recommendation, it would not be a resolvable tdw DIDDoc -- the DIDDoc would be required to include an authentication or verificationMethod key type copied from did:tdw:abc.
• My view is that since the controller is a did:tdw it is "reasonable" that the resolver recursively resolve the external controller to determine the authentication or verificationMethod key type from did:tdw:abc itself.

[brianorwhatever]

The question I'm pondering here is:

If I want to add an external controller should I also be required to include myself as a controller.

I've started to think of it a bit differently than before... the mental model I'm working with now is: here is a list of keys that are authorized to update this document some of them are from external controllers but only these specific keys are authorized. Instead of: Here is a list of controllers that can update this document, any of their keys of the right type can update.

The former makes sense to me as I want to tightly control what keys can update this thing not let you bring any key you please.

So that's what made me think of this question. I should probably be able to revoke other controllers keys so I should always include myself as a controller

[andrewwhitehead]

My intuition is also that the subject should always be one of the controllers, although it's hard to think of an example of what might go wrong otherwise.

[brianorwhatever]

Yeah, ultimately the webserver has control over what is being inserted into the history so it feels weird they would have that control but not control over updating the doc

[swcurran]

My concern is that by putting a constraint on it, we’re going against the DID Spec. If we go with a company DID that is controlled by the owner of the company, only the owner (who has/controls their own DID) can update the company DID. I think it can be a mechanism to do delegated authority — I’ll let you use a DID/keys for a set of purposes, but I’ll control any changes made.

I definitely think that the verifiableConditions scenario will take us into the use of external DIDs. While the DID itself might be the controller, the key references in the verifiableConditions will likely be external. The Board of Directors scenario is an obvious one.

It is all edge cases - the vast majority would have the DID as its own controller (I would think). But it would nice to avoid constraining the core spec without a really good reason.

And an implementation having a constraint is different in IMHO than the spec. having the constraint.

[brianorwhatever]

Yeah, I am ok with not having this constraint. I also wonder if it could be used to deactivate a DID. If I set the controller to a provably uncontrollable DID I've effectively "tombstoned" the document since nobody can make any updates. We could say "to deactivate set the controller to did:tdw:1".

Obviously, the log entry could just be removed and the previous state could be forked but that's another edge case altogether..

[swcurran]

I wonder if the DID Core Spec differentiates between the absence of a controller (implying the DID is its controller) or ”controller” : “”, which is (IMHO) a nicer way of doing what you propose.

[andrewwhitehead]

I believe the absence of a controller property means it defaults to the DID subject. A blank string wouldn't be valid, it must be a DID.

[andrewwhitehead]

Also we can use a deactivated: true parameter to tombstone (reversibly), or potentially remove all authentication keys.

[brianorwhatever]

Closing with the answer: "No, the current id does not need to be a controller."