The case for a separate VID 1.0 specification

[talltree]

I know this proposal has been discussed (and dismissed) in earlier TSPTF meetings. However, at IIW 38 last week, Eric Scouten and I hosted a session called “A Bridge to the Future: Connecting X.509 with DID/VIDs”. It was quite successful (and resulted in a bunch of new feedback and ideas for our X.509 VID Task Force).

After the session, several attendees came up to ask me the question that we get all the time: what is the difference between DIDs and VIDs?

I expect we’ll get that question 1000 more times because of the simple fact that DIDs are a 2-year old W3C standard and VIDs are a brand new term currently used by only a few ToIP specifications.

However in the followup conversations I had with those attendees, it became clear that there are several more good reasons we may not have considered for why to break out VIDs into a separate ToIP spec. To wit:

1. If VIDs are going to be compared with DIDs (which they absolutely will be), developers and architects expect there to be a ToIP VID 1.0 specification just like there is the W3C DID 1.0 specification. That way they can compare them apples-to-apples to understand the differences.
2. If VIDs are going to be used by other specifications (exhibit number 1: the ToIP Trust Registry Protocol spec), those specs are going to want to reference a VID specification, not a specification that includes a VID “mini-spec”.
3. A dedicated VID spec can go into more detail about the requirements for VIDs and how they differ from DIDs—detail that would not be appropriate in the TSP spec.
4. Perhaps most importantly, we have already decided that we need to specify a registry function for VID types just like the W3C DID spec specifies a registry function for DID methods. This registry function is particularly important because it will be how VIDs are assigned VID type codes in the CESR code tables.

That registry function would be a natural part of a VID 1.0 spec, but IMHO it would be exceedingly awkward to try to include in the TSP spec. It feels like the strongest case for defining VIDs and the VID registry requirements in a standalone spec.

That VID 1.0 spec could be produced by this TF as part of our work in completing the TSP spec (which would normatively reference the VID 1.0 spec), or we could charter a separate TF to do it.

Thoughts?

[darrellodonnell]

This would be helpful for the Trust Registry Protocol Specification (v2) as well. We've been flip-flopping about whether to use DID or VID. DID has a spec to point to. VID doesn't, and pointing at a section of another spec isn't nearly as normative IMO.

[talltree]

This question was resolved in the 2024-04-24 TSPTF meeting when @wenjing shared this observation: a VID is not a specific type of identifier. Rather it is a class of identifiers that meet the functional requirements in section 2 of the TSP specification.

Some (but not all) DIDs meet those requirements. KERI AIDs meet those requirements. In the future, other cryptographically verifiable identifier types might meet those requirements. All of those can be VIDs.

Therefore comparing VIDs to DIDs is “comparing fruit to apples”. We created the concept of VIDs because we needed a single term for the class of identifiers that support the authenticity, confidentiality, and metadata privacy features of the TSP. Those requirements are all we need to specify in section 2 of the TSP spec.

So we can put this proposal to bed and focus on providing examples in the spec of the “instances” of the VID class (i.e., specific DID methods, AIDs, etc.) that actually meet the TSP requirements.

We did agree, however, that we will need to decide about how to manage a registry of VID type codes to use in CESR code tables. We agreed to defer that decision until we have more implementation experience.