Adjust framing to correctly describe relationship between the identifier and the controller

[jandrieu]

A controller document is a set of data that specifies one or more relationships between a controller and a set of data, such as a set of public cryptographic keys.

This framing suggests that controller documents relate a Controller, as in a specific entity, to a set of data.

I'd argue that this is a mistaken statement of what a controller document expresses.

Controller documents express the verification methods useful for verifying particular interactions with a given identifier. This is done by defining verification relationships which link the identifier to particular verification methods.

It is important to note that the actual Controller, i.e., the entity that actually controls the controller document, is NOT described by the controller document. That would be better expressed in a VC with the that identifier as a subject.

What is described in the controller document is how you verify particular interactions, not the entity involved. That is a question of identity assurance, which might be achievable once a controller document establishes certain verification methods as suitable to give a verifier confidence that the current action (attestation, authentication, delegation, invocation, or en/decription) was performed by a legitimate agent of the controller of the controller document.

[msporny]

@jandrieu Can you provide a concrete replacement definition that the group could discuss?

[jandrieu]

How about

Controller documents express how to verify interactions with a given identifier. Each document lists verification methods for that can be used to secure and verify various cryptographic proofs.

When a proof is communicated, it

• includes the id of the controller document,
• the verification method used, and
• the verification relationship used for the proof.

To evaluate a proof, verifiers retrieve the details necessary from the associated controller document, verify the verification relationship, and apply the algorithm specified for by the verification method to verify the proof.

In this manner, controller documents enable the verification of actions taken on behalf of an identifier, such as

• authenticating as login
• attestations as digital credentials
• delegation of capabilities
• invocation of capabilities
• encryption and decryption using agreed-upon keys

[selfissued]

I don't love "verify interactions with a given identifier". To unspecific. Can you take another stab at this phrase, Joe?

Other than that, this seems like a step in the right direction. Thanks.

[jandrieu]

I don't love "verify interactions with a given identifier". To unspecific. Can you take another stab at this phrase, Joe?

Yeah. It's a tough language challenge. FWIW, I think "verify" is the right verb, given "verification relationships" and "verification method".

That leaves the thing being verified and the source of the thing verified. I think I was trying to avoid naming the entity creating the source, but putting it in explicitly maybe clears up the nuance.

verify interactions with a given identifier

[original, but awkward]

verify actions taken by a given identifier

[the identifiers don't take actions, though]

verify proofs demonstrating actions taken by the identifier

[the identifiers don't take actions, though]

verify proofs created by the controller of an identifier.

[this is the most concrete, but also it loses the semantics of what is meant by the proof]

verify actions taken by the controller of an identifier

[This finally connects real world things (actions) with a real world entity (controller).]

Thoughts?

[dlongley]

I think I like this one the most: "verify proofs created by the controller of an identifier." It doesn't introduce an (arguably) new concept "actions" and focuses on the verification methods, proofs, and controller of the identifier.

EDIT: to make it flow into the bulleted list:

"In this manner, controller documents enable the verification of proofs created by the controller of an identifier, such as proofs for the purpose of"

[selfissued]

Once again, I like @dlongley's wording suggestion. Although this one is really good too:

verify actions taken by the controller of an identifier

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

---

[jandrieu]

I'd like to propose we have some momentum towards consensus for

"In this manner, controller documents enable the verification of proofs created by the controller of an identifier, such as proofs for the purpose of"

@dlongley and @selfissued both endorsed this version, as do I.

Unless someone wants to suggest a different alternative, let's mark this as Ready for PR.

[msporny]

In order to make progress at W3C TPAC, I am suggesting that this issue is "editorial" (and it's "ready for PR") and can be resolved during the Candidate Recommendation phase. The VCWG will discuss this issue at W3C TPAC to see if the "during CR" determination is correct.

[iherman]

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

• no resolutions were taken

View the transcript

3.1. What is the role of the subject when the controller property is present? (issue controller-document#33)

See github issue controller-document#33.

Manu Sporny: switching to controller document, the first issue, JoeAndrieu, is waiting on you for PR text, this is issue 33 and also issue 75.

See github issue controller-document#75.

Joe Andrieu: I have 90% of a PR for one of them, which is the language around that a controller document lets you verify proofs. That was a straightforward change, the other is on my queue and I will have something by next week, that has language defining the controller property, which is a CR issue.

Manu Sporny: moving through the other issues, there were a number of these that we briefly discussed during W3C TPAC, we marked them as discussed or editorial, we have not had any pushback on the editorial nature of most of them, so we are going to address those during the CR phase.

[iherman]

The issue was discussed in a meeting on 2024-10-23

• no resolutions were taken

View the transcript

6.1. Adjust framing to correctly describe relationship between the identifier and the controller (issue controller-document#75)

See github issue controller-document#75.

Brent Zundel: I believe that this is at least partially addressed by the PR that Joe raised, what's the delta?

Joe Andrieu: I think it's dependent on figuring out what that new intro language is and deal with that issue Filip is bringing up.
… If we get that intro correct that will provide guidance for how to update this. I think that's where we're at. I think the other one that spawned off of issue 33 -- and we already have the PR for 33, it doesn't address DavidC's issue on subject vs. controller.
… If we figure out the intro and then we can talk about subject not being controller and we can update the doc.

Manu Sporny: I'm wondering if this is editorial and we can do this during CR. At TPAC we removed the "during CR" label.
… I don't know what the language will be -- whether editorial or normative -- I'd like to figure that out. I would like to presume that other introductory PR will go in and what concrete thing will close this issue.

Joe Andrieu: I can put a PR together if 33 looks good, I think conceptually we as a group really haven't responded to DavidC's question and whatever PR I make to update this language should read on that. I can get to spec text.

Manu Sporny: Yes, please, please raise a PR for 75.

Joe Andrieu: Yes, I can.

Ivan Herman: Is it the same issue as what we discussed elsewhere -- on what happens if there is no controller property, is there any entity that plays a similar role -- is it the same story?

Joe Andrieu: Yes, it's the same thing.

Ivan Herman: Unfortunately for me, it's not an editorial question.

Manu Sporny: In which case we have to deal with this then.

Joe Andrieu: +1 to VDR decides who is the controller.

Manu Sporny: I will suggest that the controller of the document is defined by the VDR, which Dave Longley suggested as well -- and maybe we just say that.
… So the relationship is defined by the VDR and we can't say anything generalized or generic -- and we can maybe give some suggestions or expectations.

Joe Andrieu: If we do that, I think that addresses both yours and DavidC's issue.

David Chadwick: Let's see the text, and we need to resolve it and I'll review it. You speak of the VDR as a separate entity from the controller document.
… I see the controller document as part of the VDR and it's the standardized part that someone can retrieve.
… Am I right or wrong in that assumption?

Joe Andrieu: I would say I think you're wrong. In the context of the bitcoin methods, the DID document doesn't exist in the blockchain, it's derived from transactions on the chain. The information needed to manage the document is in the chain.

Manu Sporny: I think you're right conceptually but we have to talk more to details on how VDRs work.
… I think we can talk about specifying that there isn't one true way to do it.

Joe Andrieu: I just wanted to get something in the ether -- I think then, I don't believe we have VDRs in the controller document. I've been using the language "where the document is stored". Or do we need to introduce VDRs formally?

Brent Zundel: It's sufficient to talk about where it's stored.

Manu Sporny: +1 to not growing scope.

Brent Zundel: Watch for VCWG meeting cancellations, IIW.
… Thanks folks!

---

[msporny]

PR #116 has been raised to address this issue. This issue will be closed once PR #116 has been merged.

[msporny]

PR #116 has been merged, closing.