Add Deliverables section on Registries

[msporny]

Given that the Verifiable Credentials Data Model and Data Integrity specifications contain various extension points, this PR adds a Deliverables section on Registries that the group knows it will have to create (at a minimum).

---

Preview | Diff

[jandrieu]

For what it's worth, as I outlined in https://github.com/w3c/vc-wg-charter/issues/62, I don't think the W3C is the right place to be running registries, especially as github repos. There is more to running a registry than simply maintaining a published document.

IMO, we should avoid architectures that depend on registries.

[jyasskin]

@jandrieu The W3C's ability to create registries at all is new, created in last year's Process: https://www.w3.org/2021/Process-20211102/#registries, which is definitely after the DID Method registry you're complaining about. While there will definitely be some growing pains, if you want extension points at all in VCs, you'll need the specification to explain how people can find the meanings of the extensions they run into. You could commit to the IANA process for registries, but I don't recommend working across two standards bodies like that if you can help it.

[msporny]

While there will definitely be some growing pains, if you want extension points at all in VCs, you'll need the specification to explain how people can find the meanings of the extensions they run into.

In JSON-LD, which you can always map a VC to, you just follow your nose to the URL associated with the term you're interested in. In other words, JSON-LD has a decentralized discovery mechanism built in and doesn't need a registry. For example, publicKeyMultibase expands to something that leads somewhere:

https://w3c-ccg.github.io/security-vocab/#publicKeyMultibase

... that could be the discovery mechanism we specify for Verifiable Credentials.

The DID Core Registries were requested by the JSON-only folks in the group in the name of cross JSON/JSON-LD interoperability. If you just use JSON-LD (or can always map to JSON-LD, which you can count on w/ VCs, you don't need registries). However, I expect that to fail because some of the same people are involved in this work as well, and will probably make the same anti-JSON-LD arguments that were made the last time around.

That said, the DID Core registries were not a complete loss. The only registry that's controversial was the DID Methods registry. Every other registry in there has had a fairly boring history: https://w3c.github.io/did-spec-registries/#property-names, https://w3c.github.io/did-spec-registries/#property-values, https://w3c.github.io/did-spec-registries/#representations, https://w3c.github.io/did-spec-registries/#did-document-metadata, https://w3c.github.io/did-spec-registries/#parameters, etc.

To be clear, I'm trying to be practical here. I'd prefer the decentralized solution... it's just that people are going to -1 it and I'm not sure we want to eat up WG time having the same JSON vs. JSON-LD argument all over again for the 3rd WG in a row.

[iherman]

The issue was discussed in a meeting on 2022-03-02

• no resolutions were taken

View the transcript

#### 4.3. Add Deliverables section on Registries (pr vc-wg-charter#85) _See github pull request [vc-wg-charter#85](https://github.com/w3c/vc-wg-charter/pull/85)._ **Brent Zundel:** let's look at #85. … this adds deliverable section. **Manu Sporny:** Sharing screen. This is the new section on registries.. … took description of registries from somewhere, then Jeffrey suggested we add a "based on" column. … also, Mike Jones asked for a change in the name of the CCG registry. That happened historically, before W3C had a registry process.. … we can do more, we can do less, this is just a starting list. **Joe Andrieu:** I want to reiterate - I expect I'm an outlier, so if I'm the only voice, don't expect to uphold consensus. I think DID Spec Registries was a nightmare, I know W3C Registries process exists... contact information was added because I added to it, don't think we're mature enough to take on registry functions. It has been a nightmare, I would prefer an architecture that doesn't presume centralized registries.. **Michael Prorock:** I want to +1 Joe on that.. **Kevin Dean:** I agree, building and deploying registries is a major undertaking, even for something that has a relatively small number of records.. > *Kevin Dean:* +1 to Joe. **Kristina Yasuda:** two things. One: Mike is on vacation. I have a message from him: On enumerating complete potential registries. He agrees with the text above the table. We'd work on the registries is good. More work to be done on enumerating the set.. … On the registry at W3C, that seems normal because the process is new. Registries have been proven powerful in other SDOs, so I suggest we keep the text that we will work on registries.. … We think we should have certain aspects of registries in charter.. **Manu Sporny:** I wanted to +1 Joe. I don't think he's alone. the DID Spec registries has been a nightmare.. … at the same time, I'm not going to -1 us working on registries.. … It is going to take an enormous amount of effort. But I think we should do it.. … It was used against us in the DID vote. … The other statement about not enumerating registries is falling into the same trap is that people will argue that we shouldn't do it because it's not in the charter.. … We know we _are_ going to have registries. … This helps us later on when people object.. **Kristina Yasuda:** Because the working group can decide what work items it can pick up or not... that argument doesn't stand.. … even if we do enumerate, even if we are to conclude specific concrete aspects of particular registries. we can't really merge until those are addressed. > *Manu Sporny:* It's true that it's not a 100% guarantee, but I don't think that's what we're looking for.. **Joe Andrieu:** I thought I was going to be a lone voice, but Manu, part of your argument was the assumption that we were going to create registries. Given my comment, I'm not sure that's appropriate.. **Brent Zundel:** is it reasonable to produce a recommendation with intended extension points and not provide extension points for those to be registered. **Manu Sporny:** yes, it is reasonable, that is what we intended to do with DID Core. … in this case, i do think it is a useful thing. … and I'll be a part of that process. **Joe Andrieu:** That was not part of the original intention of DID Core - a significant goal of DIDs and VCs is to be decentralized, compromise between JSON-LD and JSON was a false compromise, and led to expectation of centralized registries. Violates ethos of what we're trying to do here. If we had managed DID Spec registries in compelling way, we failed to properly managed DID Spec registries, and I'm concerned about adding more registries w/o addressing. > *Manu Sporny:* that.. > *Orie Steele:* +1 Joe, but not sure that the alternative is better.. > *Joe Andrieu:* Understood, Orie, the alternatives are also challenging. > *Kristina Yasuda:* it's not in scope of the charter to outline _how_ we manage the registries. If we agree to potentially have them, that opens up the door to address the managing the registries problem. > *Joe Andrieu:* seems that a way to proceed may be to put in the charter that we "may" do this, but let the WG debate it.. > *Ryan Grant:* +1. **Dave Longley:** seems that a way to proceed may be to put in the charter that we "may" do this, but let the WG debate it.. > *Brent Zundel:* +1 dave. > *Joe Andrieu:* +1 to dave. > *Dave Longley:* and +1 to joe's concerns generally. **Manu Sporny:** if I change the language, would that work? **Joe Andrieu:** Good question, thinking.... > *Orie Steele:* +1 Joe, i would stick to explict charter suggestions. **Joe Andrieu:** Maybe, let's look at it again in a week, I feel like there is a certain inertia/momentum. When you acknowledged with a -1, but said +1 anyway, we're not thinking through these decisions, not convinced that'll lead to the right outcome. Maybe your proposal is the best way forward, need time to think through that.. > *Dave Longley:* i think it would be better to have time and space to litigate that in the group.

[msporny]

@jandrieu wrote:

For what it's worth, as I outlined in #62, I don't think the W3C is the right place to be running registries, especially as github repos. There is more to running a registry than simply maintaining a published document.

I updated the introduction in 0cdfcbb0a2aa8153fe4b34ef8ca8af18f89883d0 to clarify that the WG might decide to NOT publish any registries (so we can have the debate in the WG). The current updated text reads (bold'ing is mine to highlight relevant changes):

The Working Group may deliver a set of registries on the W3C Registry Track to support extension points in the above normative deliverables. The Working Group might produce the following registries and will adjust this list as needed to support the normative deliverables:

@jandrieu, I don't expect that to address all of your concerns, but it makes it clear that the WG could decide to NOT create any registries.

[brentzundel]

Group conversations have come to consensus on a small portion of this PR, as represented by PR #98 and PR #101, the other pieces have failed to find consensus. Closing.