Move normative definition of Verification Methods and Controller Documents to Data Integrity

[msporny]

DID Core currently defines Verification Methods and Controller Documents, which was a stop-gap measure until we were able to start the Data Integrity work at W3C. Now that that work exists, and the normative definitions are over there, we should point the DID Core definitions for Verification Methods and Controller Documents to Data Integrity (in the next version of the specification). To be clear, this would be an Editorial change requiring no normative updates to implementations.

[iherman]

The issue was discussed in a meeting on 2023-07-26

• no resolutions were taken

View the transcript

#### 2.3. Define Controller Documents in the Core Data Model (issue vc-data-model#1205) _See github issue [vc-data-model#1205](https://github.com/w3c/vc-jose-cose/issues/140)._ > *Dave Longley:* JSON can't be understood without a spec and we have one of those, it's fine how it is. **Manu Sporny:** We had a discussion about 1205 in yesterday's special topic call. I think this is pre-CR. **Ivan Herman:** this is a larger issue on the overlap between DID and VC terms, also affects the security spec. We discussed it yesterday. These must be handled pre-CR. _See github issue [did-core#845](https://github.com/w3c/did-core/issues/845)._ **Manu Sporny:** I wouldn't mark it pending-close yet. **Sebastian Crane:** I'm happy to speak about this later, but in yesterday's meeting, Dave Longley said that controller documents have been a part of data integrity for a decade... work in W3C has not been going on for that long.

[peacekeeper]

I'm not so sure if this is a good idea. What about features like service endpoints or alsoKnownAs? I think those should remain in DID Core, since they don't really have much to do with Data Integrity. And then wouldn't we end up with a situation where some parts of DID documents (aka "controller documents") are defined in one spec, and other parts in another spec?

[msporny]

I'm not so sure if this is a good idea. What about features like service endpoints or alsoKnownAs? I think those should remain in DID Core, since they don't really have much to do with Data Integrity.

Yes, agreed. My initial comment wasn't clear... the /base definition/ could come from Data Integrity, but we could easily layer stuff like service endpoints on top in the DID Core spec. There is an argument for alsoKnownAs going either in Data Integrity or in DID Core. Either would probably be fine, there.

And then wouldn't we end up with a situation where some parts of DID documents (aka "controller documents") are defined in one spec, and other parts in another spec?

Yes, but that dynamic has always been the case -- a number of DID Method specifications extend controller documents and add features to their DID Method-specific DID Documents (aka "controller documents") that other DID Documents don't have.

[OR13]

The main feature that "controller documents" have over "did documents" is they work with regular URLs, and application/json media types.... IMO this should be fixed with a small specification that can be cited from all the specs that need a generic definition of a controller document, including vc-data-model, did-core, data-integrity and vc-jose-cose.

[selfissued]

As we discussed on the WG call, this should be in a document in the VC working group that is independent of the securing specifications. This is being tracked by https://github.com/w3c/vc-jose-cose/issues/140.

This is not an issue that the DID WG can address. This issue should be closed on that basis.

[OR13]

VCWG is not likely to get to CR by filing issues in DID Core, we need address this in the active WG that is blocked by it.

[iherman]

Isn't this superseded by #854?

[msporny]

Isn't this superseded by #854?

Yes, closing.