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

[Sakurann]

I think mandating certain registries in the charter is quite a strong language. I suggest language below would be sufficient

The Working Group may publish and maintain the following registries:

[tplooker]

I think you might be advocating for a may here? your suggested text has both may and will, if so if you agree with the intent of the registries why relax the language to a may?

[Sakurann]

oops, thanks for catching this. I was advocating for may and also removing at least that mandates working on the below four registries. (edited the suggestion in the initial comment)

[Sakurann]

I agree with this registry. However, I suggest we remove a link pointing to a CCG work item since a new registry will be created and having this link is misleading.

[TallTed]

As above.

[Sakurann]

I agree with this registry. However, I suggest we remove a link pointing to a CCG work item since a new registry will be created and having this link is misleading.

[tplooker]

Personally I find these links useful to frame what the registry will likely look like, however we could provide a note to clarify that these linked registries are not finalised and merely included as informative links?

[TallTed]

I believe that intent is for the existing CCG Work Item to be subsumed into the output of the new VCWG (VC2WG? VCWG2? VCWG Part Deux?), probably retaining a redirect of some kind to the WG's new registry, but otherwise leaving no actual registry in the current CCG Work Item's space. The CCG Work Item exists because there was no W3C support for Registry maintenance at the time of this Registry's creation, which maintenance was and is as necessary as the Registry itself.

[jyasskin]

WebApps has links like this in its charter. The links continue to point places like https://wicg.github.io/web-share/ even after the document is adopted by the WG, but that redirects to https://w3c.github.io/web-share/.

Or you could add a column like

Registry	Description	Based on
Verifiable Credential Extensions Registry	A registry of extensions to the Verifiable Credentials Data Model specification.	https://w3c-ccg.github.io/vc-extension-registry/

[Sakurann]

Thank you for clarifying. I like a suggestion to have a Based on column, but given the explanation, that might not be needed and we can leave the table as-is.

[msporny]

What @TallTed said, and fixed in d38c69b.

[Sakurann]

I agree we might create such registry, but a WG charter should not include a registry for a CCG document. Suggest we remove this item from the charter.

[TallTed]

As above.

[msporny]

Addressed in #85 (comment).

[Sakurann]

I agree we might create such registry, but a WG charter should not include a registry for a CCG document. Suggest we remove this item from the charter.

[TallTed]

As above.

[msporny]

Addressed in #85 (comment).

[jyasskin]

Thanks for adding registries to the deliverables!

[jyasskin]

WebApps has links like this in its charter. The links continue to point places like https://wicg.github.io/web-share/ even after the document is adopted by the WG, but that redirects to https://w3c.github.io/web-share/.

Or you could add a column like

Registry	Description	Based on
Verifiable Credential Extensions Registry	A registry of extensions to the Verifiable Credentials Data Model specification.	https://w3c-ccg.github.io/vc-extension-registry/

[selfissued]

Please remove the non-specific "Verifiable Credentials Extensions Registry" from this PR. It would be far better to simply say that creation of registries is in scope than to make ones up that are almost certainly incorrect.

[selfissued]

"Verifiable Credentials Extensions Registry" is far too generic. There almost certainly will be multiple kinds of extensions, each of which should have its own registry.

As an illustrative example, the specification https://www.rfc-editor.org/rfc/rfc8809.html creates registries for two different specific types of WebAuthn extensions. Similarly, the set of registries at https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml are for eleven distinct kinds of OAuth extensions.

[msporny]

Fixed in fb17a5a and c47ffd5.

[selfissued]

Per my earlier review, please delete the incorrect "Verifiable Credential Extensions Registry", as this will almost certainly be multiple registries for individual kinds of extensions.

Likewise, per @Sakurann 's comments, please delete all proposed registries for CCG items from our charter. We should control our own destiny and only define registries for things that the WG produces.

[selfissued]

Per my earlier review, "Verifiable Credential Extensions Registry" is almost certainly wrong, since each kind of VC extension will need its own registry. Please delete this overly-specific and misleading entry. Compare this to https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml, which defines eleven extensions registries for OAuth.

[msporny]

Fixed in fb17a5a and c47ffd5.

[selfissued]

At the risk of repeating myself. Please remove the overly-specific and probably incorrect proposed registries. And please remove all dependencies on CCG outputs.

This can be simple. Please stop making it complicated!

[selfissued]

I shouldn't have to keep repeating myself about this. "Verifiable Credential Extensions Registry" is both overly specific and almost certainly wrong, as there will be many kinds of extensions, each with its own registry.

It's probably best to stop trying to enumerate the registries in the charter. Just say that creation of registries for WG-defined extension points is in scope and call it good.

[msporny]

I shouldn't have to keep repeating myself about this.

That document is the official registry for VC Extensions and the management of it was handed over to the W3C CCG per official resolution by the VC1WG. It has, for the last several years, with the involvement of the VCWG, been called the "Verifiable Credential Extensions Registry".

If the VCWG would like to change the name, it should resolve to do so. Given that it's an input document, and given that it's name is currently the "Verifiable Credential Extensions Registry", we should probably keep calling it that to make sure we don't confuse people by calling the document by a different name.

As I noted previously, I have renamed the potential registry (column 1) to "Verifiable Credential Properties Registry" per your suggestion that the target name is misleading. If you would like it to be changed to a different name, please suggest something concrete that will achieve consensus among the group.

[selfissued]

Again, please remove all proposed registries that cite CCG documents. We should control our own destiny and only create registries for things that this working group creates. Our outputs should have no dependencies on CCG documents.

[jyasskin]

The CCG documents are described here as inputs, rather than outputs, so I think that matches what you've been asking for. It's plausible to leave out the list of likely registries entirely (although I think it's useful), but mentioning CG documents matches the precedent in the WebApps charter.

[jandrieu]

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.

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.

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 0cdfcbb 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.

[selfissued]

Please close this PR without merging it, as #98 already does the job that needs to be done well, without all the additional clutter that's causing disagreements.

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