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.

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

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

Closed
msporny opened this issue Jun 3, 2024 · 4 comments
Closed

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

msporny opened this issue Jun 3, 2024 · 4 comments
Assignees
Labels
LC Working Draft approaching Candidate Recommendation REVIEW REQUESTED

Comments

@msporny
Copy link

msporny commented Jun 3, 2024

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

  • Where and how to file issues arising?

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

@msporny msporny added LC Working Draft approaching Candidate Recommendation pending This issue needs to get a reviewer assigned to it REVIEW REQUESTED labels Jun 3, 2024
@npdoty npdoty self-assigned this Jun 17, 2024
@npdoty npdoty removed the pending This issue needs to get a reviewer assigned to it label Jul 29, 2024
@brentzundel
Copy link

brentzundel commented Aug 5, 2024

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
Copy link
Member

npdoty commented Sep 5, 2024

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?

@plehegar
Copy link
Contributor

@npdoty
Copy link
Member

npdoty commented Sep 16, 2024

We will track follow-up on this issue in the Controller Document repo: w3c/controller-document#93

@npdoty npdoty closed this as completed Sep 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LC Working Draft approaching Candidate Recommendation REVIEW REQUESTED
Projects
None yet
Development

No branches or pull requests

4 participants