Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix definition of controller and add verification method binding section #126

Closed
wants to merge 3 commits into from
Closed

Fix definition of controller and add verification method binding section #126

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d8aadf8
Update definition of controller.
msporny Nov 17, 2024
1c14115
Add section on verification Method Binding.
msporny Nov 17, 2024
8db5a64
Improve definition of controller.
msporny Nov 17, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 17 additions & 4 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -555,11 +555,11 @@ <h3>Terminology</h3>
<!-- [[[#cryptographic-suites]]] for further detail. -->
</dd>

<dt><dfn class="export" data-lt="controller(s)|Controllers">controller</dfn></dt>
<dt><dfn class="export">controller</dfn></dt>
<dd>
An entity that is [=authorized=] to perform an action with a specific resource,
such as update a [=controller document=] or use a cryptographic key to generate
a digital signature.
An entity that is [=authorized=] to perform an action associated with a specific
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
An entity that is [=authorized=] to perform an action associated with a specific
An entity that is [=authorized=] to perform any action on the associated

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An entity may be authorized to perform SOME actions but not necessarily ANY actions. This suggestion should not be incorporated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed. the action is, in fact, limited by the context. For example, the verification method controller can't update the verification method as listed in the CID, but can create proofs that satisfy the method. "Any" action is too broad.

resource such as updating a [=controller document=] or generating a digital
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
resource such as updating a [=controller document=] or generating a digital
resource such as updating the associated [=controller document=] or updating the associated verification method

Copy link
Member

@TallTed TallTed Nov 18, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I agree with @David-Chadwick's suggestion, but if it is accepted, it should include the markup and full-stop below --

Suggested change
resource such as updating a [=controller document=] or generating a digital
resource such as updating the associated [=controller document=] or updating
the associated [=verification method=].

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This edit continues the error of the previous suggestion. Verification Method controllers CANNOT update the associated verification method. Only CID document controllers can update the method.

signature that can be verified using a [=verification method=].
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
signature that can be verified using a [=verification method=].

</dd>

<dt><dfn class="export">controller document</dfn></dt>
Expand Down Expand Up @@ -2909,6 +2909,19 @@ <h2>Key and Signature Expiration</h2>
</p>
</section>

<section>
<h3>Verification Method Binding</h3>

<p>
Implementers ensure that a [=verification method=] is bound to a particular
[=controller=] by going from the expression of the [=verification method=] to
the [=controller document=], and then ensuring that the [=controller document=]
also contains a reference to the [=verification method=]. This process is
described in the algorithm for <a href="#retrieve-verification-method">
retrieving a verification method</a>.
Comment on lines +2915 to +2921
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for having copied the section from the DI spec.

However... I still have a problem. This section refers to the algorithmic section for the details on how to find the controller document. That section says:

Let controllerDocumentUrl be the result of parsing vmIdentifier according to the rules of the URL scheme and extracting the primary resource identifier (without the fragment identifier).

The only way I can interpret this sentence is that the URL of a VM is a URL with a fragment, and the controller document's URL is retrieved by removing the fragment.

Is this restriction intentional? If so, the specification of the verification method in §2.2. must make this restriction clear for the id property. Also, if it is indeed intentional, this will not hold up if ever we want to use this specification with Linked Data where URL-s are considered to be opaque, and such structure would be frowned upon; this part of the spec should be rewritten.

If it is not intentional, then... I am not sure. Would we have to say that the exact approach taken to get from the VM to a CD is implementation dependent? Application dependent? I.e., should we have to say that, in a VC setting, the VM MUST be part of the same JSON-LD document as its CD, hence the usage of a fragment ID, otherwise this is up to the implementation?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just syncing up with the similar discussion in another thread:

Note that the additional property I propose (linking the VM to the CD) is absolutely optional and does not contradict with what you say; you also talk in conditional. The only reason I think the property would be useful is because I presume it would simplify a number of business rules. But, again, if we decide it is too late for that, be it.

Yeah, I do believe it's too late for that but it could perhaps be further debated/bikeshedded/sorted and tested in a future minor release. But it's not too late for us to add some non-normative text somewhere as needed.

(see #119 (comment)).

</p>
</section>

<section>
<h2>Verification Method Rotation</h2>

Expand Down