Controller Documents vs DID Documents

[OR13]

The Working Group is currently attempting to determine the best path forward to ensure alignment between data integrity controller documents, vc-jose-cose controller documents, and did documents. The working group is still discussing how to align these definitions.

A few of the options that are currently being explored include:

1. Define controller documents in the Verifiable Credentials Data Model v2.0 specification and refer to that definition from vc-data-integrity and vc-jose-cose.
2. Define controller documents in a new TR track work item published by the VCWG and then narrow/profile that definition in vc-data-integrity and vc-jose-cose.
3. Duplicate controller document text in vc-data-integrity and vc-jose-cose.
4. Refer to DID Core for the definition of controller documents (not an option because URLs are not DIDs)

[selfissued]

I'll add that there was a preference on the call to move the key discovery / controller documents descriptions to a new specification cited by both of the securing specifications. The securing specifications could each then profile it to align it with the needs of their constituents.

[OR13]

FWIW, I think the safest and fastest solution to this is to copy the controller document section into a separate document, then refer to that document from the securing specification, and only include examples in the core data model that do not rely on understanding controller documents... or if the examples do rely on understanding controller documents, the core data model will need to link to controller documents.

This protects the core data model from potential objections if controller documents are bundled although a reference could still be a problem and we should try to avoid that reference IMO, since as was said on the call, controller documents are about securing mechanisms not verifiable credentials.

It also protects the core data model from potential objections that are directed at a specific securing mechanism (data integrity or sd-jwt)

It makes it so securing mechanisms can share definitions instead of redefine things, which removes duplication, and improves interoperability.

If we can't put controller documents in a separate document, they will need to go in the core data model, if they are intended to be shared by all implementations of the core data model.

That will put the core data model at risk, and we should therefore work to ensure that controversy happens in the data integrity or sd-jwt profiles, and not the core data model.

[OR13]

Cross linking tracking this issue filed in DID Core.

https://github.com/w3c/did-core/issues/845

[OR13]

https://github.com/w3c/vc-controller-document now exists

[selfissued]

As discussed on the 20-Dec-23 working group call, we will address this post-CR.

[TallTed]

20-Dec-23 -> 20-Dec-2023

[decentralgabe]

Closing as a duplicate of https://github.com/w3c/vc-jose-cose/issues/140