Controllers Documents v1.0 2024-06-02 > 2024-09-02

[msporny]

The Verifiable Credentials Working Group is requesting a review of Controller Documents by the end of summer 2024 (ideally, sooner). Controller Documents are a generalization of DID Documents and some content from VC Data Integrity. All this to say, your group has reviewed most of this content before when it reviewed DID Core, and then again when it reviewed Verifiable Credential Data Integrity. The Working Group recently decided that it would rather have this content in a separate specification than embed it in DID Core or VC Data Integrity, and that specification is Controller Documents v1.0.

• name of spec to be reviewed: Controller Documents v1.0

• URL of spec: https://w3c.github.io/controller-document/

• What and when is your next expected transition?

  • September 2024 (Candidate Recommendation)

• What has changed since any previous review?

  • 90%+ of previous content in DID Core and Data Integrity remains the same. Almost every normative statement remains the same (some language needed to be changed since it's being transplanted from VC Data Integrity).

• Does your document have an in-line Privacy Considerations section, ideally one separate from the Security Considerations?

  • Yes, although the Privacy Considerations section is effectively the same as in DID Core and Data Integrity (the parts of those specs that apply).

• Please point to the results of your own self-review

  • https://github.com/w3c/controller-document/issues/22

• Where and how to file issues arising?

  • https://github.com/w3c/controller-document/issues/

• Pointer to any explainer for the spec?

  • DID Core Explainer
  • Data Integrity Explainer
  • Let us know if you would like us to write another explainer for this spec: The spec is basically just "DID Documents, but you can now use other types of URLs in them (like HTTPS-based ones)". The spec exists so we can establish spec text, separate from DID Core and Data Integrity, that we can then normatively reference from other specs in the VCWG that don't have anything to do with DIDs, like generalized public key discovery algorithms.

Other comments:

It is unclear if PING should spend much time on this specification since it's largely composed of text that has been reviewed by PING multiple times over the past several years.

[brentzundel]

Howdy, just checking to see if there are any questions we might be able to answer for the reviewers and if there were an estimate for when we might be able to expect a response.

Most of the content for the document under review was pulled directly from VC JOSE COSE and VC Data Integrity, both of which were previously reviewed and are in Candidate Recommendation. We pulled some common language from both specs into a standalone specification so that it could be presented in a more logically consistent manner, but other than than have only made minimal changes.

[npdoty]

Apologies for a belated reply here. I reviewed the document, briefly discussed it on a PING call, and will provide an update to PING today.

The specification is quite abstract, and I think it would help readers and reviewers to have some particular examples about how Controller Documents are intended to be used. The very abstract nature (any kind of data related to any kind of entity) makes it challenging to reason about things like privacy properties. Or if this is intended just for cryptographic key communication, that would be a helpful narrowing of the scope and make implementation/interoperability and privacy/security protection much more straightforward.

Pairwise identifiers is a good, important privacy practice. We don't often use that exact terminology on the Web, where we might talk about the scope of identifiers or connection to the concept of origins. Would it be useful to talk about origin-specific keys or the origin model here?

https://w3c.github.io/controller-document/#keep-personal-data-private recommends that no personal data be included in a Controller Document, but it's not clear that this is a requirement that will be satisfied. Cryptographic keys used by or about a person are certainly personal data.

Also, not a privacy question, but a question I had in trying to understand the use of these documents: what is the difference between id and controller?