Closed msporny closed 3 months ago
The new text includes this:
<p class="note" title="Property names used in map of different types">
The property names `id`, `type`, and `controller` can be present in map of
different types with possible differences in constraints.
</p>
Unless I completely misunderstand, I believe this note contains essential information that should be part of the core text and elaborated upon. This note means that different other specification can use the controller document "structure" in their own, security related specification. I.e., a Verifiable Credential, a Verifiable Presentation, or a DID document are all examples of controller documents (and this is how this specification relates to the VCDM or DID).
If this is all true, it should be made much more clear and explicit somewhere in the document, and shown also with examples.
From an ontology/vocabulary point of view, the clean way would be to define a class for ControllerDocument
on which some properties are defined, and then a ~VerifiableCredential
, a VerifiablePresentation
~ ProofGraph
or a DIDDocument
is defined as a subclass. (It may be too late to do that.)
(Edited 12 hours later, realizing that a VC or a VP is probably not a Controller Document. My mistake.)
Also related to https://github.com/w3c/controller-document/pull/32#issuecomment-2169118081: the terminology on controller document is, sort of, circular:
controller An entity that has the capability to make changes to a controller document. controller document 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.
Nowhere is the term "controller document" properly defined; the definition above fits any kind of resource under the Sun ("such as" means that any property can be present...). The Data model section, which includes the aforementioned note, is also void of real information.
We should come up with a more specific definition in the terminology section to make the term more "restrictive", i.e., to really separate Controller Documents from other resources.
(I must admit that I do not understand how this term "Controller" fits here. But it may be too late to come up with a better name. All the more important to provide a better descriptive text.)
The issue was discussed in a meeting on 2024-06-19
The issue was discussed in a meeting on 2024-06-26
Normative, multiple reviews, changes requested and made, no objections, merging.
This PR is an attempt to address issue #31 by defining the properties that are required and optional in controller documents. This text is ported from the DID Core specification (it was deleted, by mistake, when the original document was ported over).
Preview | Diff