Specify that controller overrides subject control.

[msporny]

This PR is an attempt to address issue #33 by specifying that the controller overrides subject control, but the subject may be listed in the list of controllers.

---

Preview | Diff

[David-Chadwick]

With the proposed minor edits this resolves the issue

[jandrieu]

The controller property has nothing to do with the VDR. It does not indicate who has "change control". In only indicates that there are other controller documents that MUST be interpreted as if their verification methods and relationships were specified in this document.

[jandrieu]

Unfortunately, this statement reifies the exact confusion others are reading into the spec

Suggested change

	[=controllers=] that have exclusive change control over the document. This set MAY include
	[=controllers=] whose controller documents's verification relationships and methods shall be interpreted as if transcluded in this controller document. That is, all of the verification methods and verification relationships found in the controller documents returned from resolving entries in the controller property shall be treated as if they are present in this controller document.
	This set MAY include

There are several DID methods for which it is NOT possible to definitively specify, in a single URL, who has exclusive change control over the document. did:key, did:web, and did:btcr are just a few of them. You can use a pattern of self-reference to imply that the VDR has control, but then it is NOT the value of the controller property who has control, but the VDR itself.

The details I added here may not be the best way to get across what's happening, but the proposed language of the PR is a fairly dangerous misstatement of the purpose and mechanism of the controller property.

[dlongley]

You can use a pattern of self-reference to imply that the VDR has control, but then it is NOT the value of the controller property who has control, but the VDR itself.

Despite being true, this part feels like a bit of a red-herring to me. The VDR is always the root of control and must therefore consent to anything expressed in a DID document, such as what appears in any property, including the controller property. Whether DID document updates for a particular DID method are performed with the use of verification methods in the DID document itself (or those associated with a controller) or via some other mechanism doesn't change this. Though, I do personally think it is an anti-pattern to specifically prohibit the use of these verification methods to enable updates to a DID document.

Since applications only work at the DID document layer, they must be able to rely on information expressed there for whatever their needs may be -- they must not be required to break the abstraction and understand the details of the VDR, DID method-specific resolver, etc.

[TallTed]

There are several DID methods for which it is NOT possible to definitively specify, in a single URL, who has exclusive change control over the document.

I do not read one or more [=controllers=] that have exclusive change control to say that "a single URL" is used to specify this set of controllers; rather, that controllers can have one or more values, which together comprise the set of entities that control the DID.

this statement reifies the exact confusion others are reading into the spec

I don't think anyone's "reading [confusion] into the spec." Rather, I think that this "confusion" indicates that the spec doesn't say what you're suggesting it does.

The meaning you describe here may have been your intent when it was written, but my understanding has never been that the controller property was meant to lead to DID documents that were to be interpolated into the DID document that contained that controller value.

I have always understood controller to identify one or more entities that were permitted to cause changes to that containing DID document, just as subject identifies one or more entities for which that DID document contains interaction information. Those entities might be identified by DIDs, but the point of using those DIDs in this way was only for such identification.

[wip-abramson]

This is an interesting issue. To me, control over who can changes the DID document has always been DID method specific. While, it makes sense that the controller property identifies entities authorized to mutate the DID document.

In practice, how is this realised today? Which DID methods are requiring some form of authorization proof over an update submitted to a DID. And which resolution processes are verifying that proof against the controller property in the DID document?

Also @TallTed

my understanding has never been that the controller property was meant to lead to DID documents that were to be interpolated into the DID document that contained that controller value.

I believe this section below of the spec is where the spec defines that controller properties should be interpretted in this way.

When a controller property is present in a controller document, its value expresses one or more identifiers. Any verification methods contained in the controller documents for those identifiers SHOULD be accepted as authoritative, such that proofs that satisfy those verification methods are considered equivalent to proofs provided by the subject.

[selfissued]

Perhaps we can discuss the different means of "control" evident in this discussion on the next working group call, @brentzundel ?

[wip-abramson]

@msporny I asked about did:tdw in the Wg call. And you said something like did:tdw signs the updates using keys specified in the change log, specifically this is in an updateKeys property in the change log. I believe you said that did:tdw should be using the controller property.

But how should they be using it? The keys they use to sign updates are not included in any DID document. What does it mean to put a DID in the controller value if this is the case?

[iherman]

The issue was discussed in a meeting on 2024-08-21

• no resolutions were taken

View the transcript

6.2. Specify that controller overrides subject control. (pr controller-document#42)

See github pull request controller-document#42.

Joe Andrieu: The root confusion is the term controller as a property does not identify the controller in the role. I think Manu's attempt to respond reified that confusion.
… There are some URIs where you cannot specify the controller, and we need a way to explain that conundrum.

Will Abramson: It does say in the controller section that a controller is authorized etc. In practice, is that happening? How is that authorization enforced in DID methods today? It's misleading, as I don't know if that is actually happening.

Phillip Long: Doesn't did:tdw update controller docs?

Dave Longley: +1 to Manu, VDR is root of control, it consents to setting controller (or not).

Manu Sporny: It's supposed to be that the VDR checks that. If the VDR does check the value, that's what the property is used for. The expectation is that if the property is used, then it is enforced by the VDR.

Joe Andrieu: I think this conflation is really hard. The controller is, by definition, who creates or controls the entry in the VDR. The controller property doesn't do so. The algorithm that's actually applied, you need to dereference the controller property to bring in data that's not in the document. I think it creates a semantic confusion gap.

Manu Sporny: I think Joe is presuming a certain way of doing the information. I don't think that people are going to the document to merge those entries with those in the DID document. Depending on the VDR, it will enforce the rules that go with the controller document.

Dave Longley: #33 (comment) <-- i wrote comments here on my thoughts.

Manu Sporny: It will check the values in the document, but it won't merge it with the controller document itself.
… The controller field tells you which entities have the right to update the document, and those rules are enforced by the VBR.

Joe Andrieu: The controller property is currently used in a way that does not do what Manu says it does. When we use the property in did:key, did:web, etc., it does not work the way it's expected to work.

Will Abramson: Other DID methods like did:ion are using things in the DID document for their updates, e.g., the keys in the DID document. What should go in the controller property there?

Dave Longley: I think the fact that a number of DID methods use the value in the controller field and honour it as the entities permitted to update the DID document, if the changes to the document align with the attribute, the changes should be honoured. The fact that someone may not be able to do that is not relevant to the VDR. Applications are going to work wth the DID document layer. We should be able to say that if the VDR allows those fields to be expressed and allowed updates to happen, they would honour what's in the DID document,.

Joe Andrieu: I think that would be a breaking change. That doesn't get to the root of what the VDR does. We use a capability invocation that dictates who can update the VDR, so it feels weird that there's another mechanism that can do so.

Manu Sporny: Joe, you said that the controller must be used. I don't think we're saying that.

Joe Andrieu: If it's there, it's a breaking change.

Manu Sporny: If you use the feature, you must use it this way.
… Will asked about did:ion, did:web, did:key, etc.
… did:key doesn't need this property.

Joe Andrieu: breaking for did:web, did:key, did:btcr.

Dave Longley: if controller is present and if the VDR has a mechanism to allow stated controllers to perform updates, it should honor those controllers, however it's ok for VDRs to not have such features.

Manu Sporny: In did:web, the controller is the controller of the website.
… There is a change log that goes along with the DID document as it changes with time, and that is signed by entities.
… Control is important, even though the document is on a website. Any place where there are digital signatures, it is important to specify who is the controller.

Joe Andrieu: but did:key does have this property.

Dave Longley: but if a VDR provides such a feature, it SHOULD allow specified controllers to use that feature.

Joe Andrieu: Manu, the way the spec is using this property is not as you're describing. did:key does specify the controller, and so to use this in the way you describe is a breaking change.

Manu Sporny: hmm, I just checked the did:key spec and it doesn't use controller.

Joe Andrieu: which was my point: specs today do not use the controller property in this way. they use it differently.

Joe Andrieu: https://w3c-ccg.github.io/did-method-key/#example-2-an-example-of-a-did-key-did-document.

Joe Andrieu: it is on the did:key spec.

Gabe Cohen: We'll come back to it next week.

[jandrieu]

On the call this week, Manu argued that the use of RDF subjects means that we must treat the statements in a DID Document as being about the referent of the ID, asserting that this is an HttpRange14 problem.

It is only a HttpRange14 problem if the document model is JSON LD, which, to Manu's argument does interpret all predicates as statements about the external referent instead of about the identifier.

With VCs, that's the appropriate interpretation. The "id" field is specifically there to correlate claims about the same subject.

A narrative way to say this is that "these statements are predicates about the subject referred to by the id".

However, in a DID Document, we are not saying that the subject of the DID document has a verification relationship: precisely because the subject of the DID is not externally salient. Only the "id" is salient.

That is, we can say "these statements are predicates about the identifier".

The conflation of the interpretation is what makes this look like an HttpRange14 problem. And maybe that means JSON-LD isn't the right data model.

If you are absolutely committed to JSON-LD subject must the the referent of the DID, then we can achieve the same result, in a round about way, if we define our predicates appropriately. That is, we can say "This subject is "referred to by an identifier for which you can verify this [verification relationship] using this verification method" ]. That is we can make the RDF statement about a verification relationship usable with regard to the identifier, which in other contexts represents a subject.

The problem is the singular context where JSON-LD assumes all statements about ids are about the thing the id referred to, without the notion that statements about identifiers is important. But what we need is a document that is describing how to interact with the ID, not making assertions about some subject.

In my opinion, you first establish that a given proof is legitimate (correct crypto, correct verification relationship), then you can evaluate the legitimate evidence to establish your own confidence about whether or not the current claims apply to the current user.

If this is so out of sync with the JSON-LD mental model, then maybe the controller document isn't a JSON-LD document. The important thing that JSON-LD gives us, IMO, is decentralized disambiguation. If it brings along baggage that all predicates MUST be about an external referent and not an internal referent, then we shouldn't use the id field, but rather perhaps a "did" field about which we then have RDF statements made.

[dlongley]

@jandrieu,

It is only a HttpRange14 problem if the document model is JSON LD, which, to Manu's argument does interpret all predicates as statements about the external referent instead of about the identifier.

Well, I don't think we're making statements "about an identifier", so that isn't quite right to me. An identifier is mostly just a string of characters. We're not talking about identifiers, unless we want to say it's a URL, how many characters are in it, etc. This is why using language like "interacting with an identifier" is also odd, as one does not "interact" with a string of characters. So, we are making statements about the referent in order to make sense here.

However, I think we're overdoing it when we take this to the level of referring to a "real world thing". I actually don't think there's any problem with talking about an otherwise opaque "subject" just so that we can establish the necessary linkage in the information expressed in the controller document. You're right that what the subject is doesn't matter here, but I don't think that's relevant nor do I think its lack of relevance poses any significant problem for the spec.

All we know from a controller document is that the controller has indicated that the subject, aka "it", aka "something", identified by the identifier value associated with the id property, has some verification relationships and verification methods. Nothing else about "it" matters in the controller document other than the verification relationships and verification methods. All we care about here is that these verification things are all linked to the one thing (subject) with identifier "X". That's what a controller document is for and what using the word "subject" in the spec is to help establish, not more.

I think we want the spec to communicate: "If you want to express some verification methods associated with something (anything!) identified by the identifier 'X', here's how it's done". This enables verifiers to "establish that a given proof is legitimate (correct crypto, correct verification relationship)...", as you said. The rest of your quote is out of scope for the controller document -- where the verifier can then go about their own business in "evaluat[ing] [whatever] legitimate evidence to establish [their] own confidence about [whatever else]".

In short, I think we're making this more complicated than it is. It's ok to say the word "subject" and we don't have to be making any statement about the real world when we do it -- we're just establishing what links to what in the controller document.

[selfissued]

Well put:

I think we want the spec to communicate: "If you want to express some verification methods associated with something (anything!) identified by the identifier 'X', here's how it's done".

[iherman]

The issue was discussed in a meeting on 2024-08-28

• no resolutions were taken

View the transcript

4.3. Specify that controller overrides subject control. (pr controller-document#42)

See github pull request controller-document#42.

Manu Sporny: we did have a discussion related to this in the DID WG.
… I forget what was said, but I think Joe, you said that you saw a way through this.
… that you felt it would be a normative change in the DID WG.
… I don't quite think we still have alignment, other than that the text in the spec is wrong as it stands.
… so, there's multiple interpretations of it.

Joe Andrieu: I think we can get there, we do need a broader conversation. maybe the right thing is for me to identify the places with spec text changes.
… I do think there's some deep inconsistencies in mental models in the spec, we need to clean that up.

Brent Zundel: why does the Controller Doc spec need to talk about subjects at all?

Manu Sporny: we do it today because we have to talk about the thing that's identified with the 'id'.
… and we've been talking about that as the subject (of a DID or controller doc).
… sometimes (and this is debatable), this is the controller (of the controller doc).
… but if we call that 'controller', it becomes confusing when there's a controller field.
… so like we'd have to say "the .id of the document is the controller, unless there is a .controller field, then that overrides".
… the Controller Doc was supposed to be just a resource on the web. it's been specialized over the years to talk about key material, but it didn't start out as that.
… we call a controller doc's .id field 'the subject' because that's what it is, in the graph sense.

Brent Zundel: so to recap to make sure I understood,.
… we're using the term 'subject' because there's an .id property (of controller docs).

Dave Longley: the id identifies the thing ("the subject") that the other information (e.g., like verification methods) is related to.

Manu Sporny: yes sort of?

Joe Andrieu: I agree, Brent, we should not be mentioning subjects at all.
… it's a big source of confusion, we should clean it up.
… the mapping between an identifier and some real world state, that's what VCs do.
… what I think the Controller Doc is doing, and I proposed some language in another issue,.
… is it's using the 'subject' in the RDF sense only, to make statements about the identifier.
… the binding to real world entities, we should nuance out.
… that's the domain of the Confidence Method in the VC world, it's not something Controller Doc can address.

Dave Longley: IMO, this isn't about real world, it's about saying that the other JSON keys are used to relate stuff to the thing identified by that identifier -- regardless of what other things it may refer to.

Manu Sporny: this is the HTTPRange14 discussion.
… we don't want to go down that rabbit hole.
… I get what you're saying, and it is a long running debate.
… on semantics of identifiers.
… but we've been using this thing consistently with graph terminology, nodes and edges etc,.
… if we make the Controller Doc special in some way, we'd have to specify it in a bespoke way.

Dave Longley: {id: "some_url", "thisIsAPropertyOfWhateverTheIdPropertyRefersTo": "foo"} <-- i think that's all "subject" is about here ... it's not about a "real world", just binding the identifier to the properties, etc.

[iherman]

The issue was discussed in a meeting on 2024-09-04

• no resolutions were taken

View the transcript

2.4. Specify that controller overrides subject control. (pr controller-document#42)

See github pull request controller-document#42.

Brent Zundel: controller overrides subject control.
… JoeAndrieu was maybe going to do a quick read and leave some review?

Manu Sporny: we just talked in the DID WG about this, but we didn't come to a conclusion.

Brent Zundel: happy to do a couple minutes now.

Joe Andrieu: yeah, we need to talk about it more.
… I do need to go through it and highlight language in the spec.

Michael Jones: Joe made some good language suggestions.
… I think we're closer on this than it may seem.

Brent Zundel: that's the PRs on the controller document.
… but before we move on, lets bask in the immense amount of work done on that document.
… good job editors.

[iherman]

The issue was discussed in a meeting on 2024-09-11

• no resolutions were taken

View the transcript

4.4. Specify that controller overrides subject control. (pr controller-document#42)

See github pull request controller-document#42.

Brent Zundel: next PR #42, we have discussed this before, where we left off was that JoeAndrieu was going to propose different language, where are we at here?

Joe Andrieu: I haven't done anything on this, will rehydrate and see where we are, but I did not meet your expectation.

See github issue controller-document#75.

Dave Longley: ^there's some useful text there.

Brent Zundel: no worries, thank you for continuing to do the work.

Dave Longley: JoeAndrieu you did propose some alternate text that may or may not be reusable, just a reminder that that text is out there in the above linked issue.

Brent Zundel: we have some wording suggestions in issue 75 which I believe would help either modify PR 42 or result in a new PR, folks please look at issue 75.
… that will guide changing PR 42 or help us determine a resolution.

Manu Sporny: I was expecting to close 42 in favor of whatever PR JoeAndrieu raises, I'm fine to close this now, any objections?

Manu Sporny: I'll leave PR 42 open if we're unsure then.

Joe Andrieu: not sure we should close it but not sure that I want to stand in the way either, the issue has some language we can use, but there is disconnect between manu and I on meaning of controller property, looking forward to talking this out at TPAC.

Brent Zundel: going forward are we leaving PR 42 open for comparison? who is taking the action to move the proposed language into the spec?

Manu Sporny: I will work with JoeAndrieu to do that.

Brent Zundel: whatever we don't solve next week on controller document we will talk about at TPAC.

---

[msporny]

Closing as this PR is unlikely to achieve consensus. The discussion continues in #75.