Each registry should include at least one standardized entry

[jyasskin]

I see that the charter includes "Registries for the data models", but that might not be interpreted as including a definition of the entries in those registries. For example, https://w3c-ccg.github.io/vc-extension-registry/ includes 4 empty registries, which wouldn't be sufficient to make the data model a good specification.

[kdenhartog]

I agree with this. Historically speaking we were still trying to get a better understanding of how registries would work in W3C around the time that this extension registry was formed. As a part of that this registry hasn't operated quite like how the DID Core registry has but I'd expect going forward that it would be a lot more useful or be removed. With that in mind, do you have particular additional text you want to see added here to make sure this doesn't happen again?

[jyasskin]

Maybe

Scope:

• ...
• Registries for the data models
• Enough REC-track specifications to ensure each registry has enough standards-track entries to exercise the expected range of variation for that registry.

Or it could be less precise:

Scope:

• ...
• Registries for the data models and REC-track specifications to appear in those registries.

[kdenhartog]

Ahh I see what you're bringing up now. We're defining extension points without even having one recommendation-track default. This could expand scope considerably if we make it recommendation-track for every point (leaves the question of does level 2 need to drop features from v1 that don't have a rec-track approach?), but I think it's a wise point to bring up even though I suspect it's going to raise some controversy.

[iherman]

I understand the direction your going @jyasskin but I am a bit worried. Indeed, if we consider 'recommendation-track' default then the immediate question is: which working group would have this in its charter? And currently the answer might be: none. Ie, this can work only if we extend this charter by adding those recommendations, and I do not think that would be accepted.

Also (although I admit this is a minor point), the term 'recommendation' is W3C specific, and we may get such documents from other organizations.

I am not absolutely sure what to replace this with. We may say 'stable and open source specifications', or 'stable specifications that have several mutually independent implementations', or something like that (although it is quite verbose).

[jyasskin]

I want to avoid a situation like we had with DID-core where we couldn't review the core spec's full behavior because no standards-track WG had endorsed any of the implementations of a critical extension point. Having only non-standards-track implementations of some extension points also makes it hard for the core REC to effectively foster interoperability, since implementations will have to guess at how to implement those extension points.

It doesn't have to be a W3C WG, but it ought to be in some SDO. Being open source isn't sufficient, and once it's "stable with several implementations", why not bring it to REC? (It's also fine for the registries to include non-standards-track entries in addition to the standards-track ones.)

I get that there are WG members who object to standardizing the extension points, but there are also likely to be AC members who object to leaving them unstandardized.

[iherman]

(@jyasskin I am simply exploring the "administrative" issues here, not taking sides on whether extension point standardizing is o.k. or not.)

It doesn't have to be a W3C WG, but it ought to be in some SDO.

+1

Being open source isn't sufficient, and once it's "stable with several implementations", why not bring it to REC?

What you propose means rechartering a WG; otherwise, "bring it to REC" isn't possible. While this is, procedurally, possible, it takes, alas!, an exceedingly long time, these days, to (re)charter a group (2-3 months?). I.e., I am afraid that adding such a requirement would create a huge hurdle.

One way for compromise could be to agree on a "stable with several implementations" also published by the WG in the form of a WG Note. It may not have the same weight, but does give a stability and an official status of some sort.

Another option would be to put such standardization work into the charter now but, I believe, many in the group would object to that.

[jyasskin]

I think it's not sufficient for a REC to normatively reference a NOTE, even indirected through a registry. (It's not that every entry needs to be more mature than that, but at least enough should be to provide a complete standardized path through all the calls into the registry.)

I'm suggesting to add this to the charter's scope now so that you don't have to recharter later. If it's not in the charter's scope, I would be seriously concerned about whether it's possible to produce an acceptable REC under the charter, and would encourage us to object to the charter in order to avoid the need to object to the REC in 2 years.

[selfissued]

It's absolutely the case that we support wanting interoperable implementations to be created using only actual standards (not non-normative notes, not community group specifications, etc.) I believe that's already possible with JWT VCs today. That said, there are places where we expect to simplify some aspects of the VC spec in 2.0 and make more concrete decisions so as to improve interoperability.

[jyasskin]

@selfissued That's promising. I couldn't find any examples of such VCs in the specification, which is why I've been concerned about the charter shape. For example, https://www.w3.org/TR/vc-data-model/#example-a-simple-example-of-a-verifiable-credential isn't such a standards-based credential, since RsaSignature2018 isn't defined in a REC.

[brentzundel]

This is an interesting idea.
As I understand it, this is motivated by the problems that arise due to the combination of extension points in the data model combined with a registry for those extension points. When an extension point is normatively required, but a registry has no REC-level entries, this can leave an implementer in a hard position.
Requiring at least one REC-level entry for normatively required extension points makes sense to me.

Going beyond that doesn't make sense to me. If an extension point is optional, then does it matter what the related registry contains?

The current text of the most recent version of the VC Data Model only has one normatively required extension point, which is the proof property of a Verifiable Credential.

The proposed Verifiable Credential Data Model Integrity deliverable would be a REC-level document that defines a number of extension points for the proof property.

If any additional normatively required extension points are introduced in v2.0 o the VC Data Model, I fully expect those extension points to be supported in a registry by a REC-level specification.

@jyasskin in light of this information, are there concrete changes to the charter that you still feel are necessary related to this issue?

[kdenhartog]

Here's the idea I'm thinking may work for this and is in line with what @brentzundel proposed.

1. Each registry table requires a good definition for a registry entry in line with the requirements of the W3C process document for registries

2. Registry entries that are "required" status MUST be normatively defined as REC track documents (think default options)

3. Registry entries that are "recommended" or "optional" status MUST be published in a royalty free manor (e.g. REC track docs or community group final reports - wording could probably be improved)

4. Registry entries that are "provisional" status MUST be converted to "required" "recommended" or "optional" status within 1 year or request an extension from the Registry custodian

As @brentzundel pointed out only the "proof" property is required which means we'd have to have one signature suite that every implementation MUST implement. Examples of recommended or optional would be additional cryptosuites that would be supported. Similarly for certain features like revocation there wouldn't be any required implementation because there are times where revocation simply isn't required for the use case. The evidence property would be another example of this where recommended or optional status may be the only entries in the table. In any case, just because something is recommended or optional status, I think it's still useful to have REC track documents for these features since it makes it much more stable. In certain cases, the stability simply isn't there yet (such as the evidence property), but having the extension is useful to encourage convergence around using the property rather than inventing a new one.

The reason for the ability to register "recommended" or "optional" status is to make the process a bit more lightweight for some of these extension points while also keeping in line with the intent of always stablizing to the point of TR. E.g. I'd like to see more of the CCG draft reports finalized and then moved into the WG as REC track documents rather than the approach that's happened most commonly. They sit in the CCG for years with little improvement and then since they're associated with a particular year a new work item gets created but the old draft report is never finalized. A good example of where this happened was RevocationList2020 where the report is still in draft status and 2 years have passed and now we're taking basically the same spec and creating RevocationList2021 which is largely the same thing with a few new features.

The difficulty is we also don't want to re-charter each time a draft report finalizes so that we can REC track it which is where the W3C process isn't quite what we need, so CCG reports are necessary to stabilize most of the work and then pick up new REC track documents when a new WG is chartered and then the WG is being turned into a rubber stamp in a way. I'm not sure this is the best way to do it, but I do think it's a good starting point for us to consider and iterate from.

[OR13]

I'm generally in support of having a single mandatory to implement feature for any given registry list.

[selfissued]

We should be making a clear distinction in the spec between features that are based on completed standards and features that are subject to change. Furthermore, it should be possible to build interoperable implementations using only features using completed standards.

[jyasskin]

Re @brentzundel's #67 (comment), it seems to me that there can be two kinds of optional extension points.

1. The field may or may not be present in a VC object or recognized by an implementation, but it's defined in the main REC.
2. The name of the field itself is found in a registry of extension fields, and the field is defined in a separate specification.

My intuition is that the first ought to have at least one standardized entry in its registry, while the second only needs its registry to include entries at the same maturity level as the field's definition itself.

@OR13's point apparently matches the expectations of the Process CG when they designed registries in the first place: w3c/process#597 (comment)

Re @kdenhartog's concern about needing to recharter too often, you may be able to follow the pattern of other groups that expect to adopt work from incubation CGs. For example, the WebApps charter says:

Depending on the WICG progress, the Group may also produce W3C Recommendations for the following documents:

which lets them adopt the work when the CG and WG members think it's ready.

[kdenhartog]

Ok from the sounds of it we're closing in on consensus for an approach that would properly tread the line between achieving good levels of interoperability while also allowing for extensibility of the data model to continue to occur. I quite like the WebApps charter approach and would be more in favor of that over the proposal @msporny brought forth today around mention which documents we'll keep at FPWD. The WebApp charter approach has clear benefits of not making these documents criteria of the success of the WG, while also allowing for us to not have to re-charter anytime we feel an extension has reached a level of maturity where it can be taken on the REC track.

[iherman]

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

• no resolutions were taken

View the transcript

4.1. Each registry should include at least one standardized entry (issue vc-wg-charter#67)

See github issue vc-wg-charter#67.

Brent Zundel: recommendation by Jeffrey that "Each registry should include at least one standardized entry".

Kyle Den Hartog: this is a useful discussion.
… proposed changes would affect the new charter.
… proof would require one.
… advocating for process documents over notes due to patent protection..

Kristina Yasuda: how is CCG patent policy different from/same with W3C WG patent policy?.

Manu Sporny: I understand the intent..
… it's too early, in some cases..
… (if taking this suggestion) if we don't put evidence-related stuff in for the charter, we won't be ready for this go-around.
… because of that i'm a -1.
… it's well-intentioned and best for a mature ecosystem.

Brent Zundel: +1 to allowing for optional extension points to have registered entries that are not rec-level.

Manu Sporny: we should strive to put normative mechanisms in here, but if we accepted this we would have to remove things and it would reduce the education of people in the space..

Brent Zundel: there are decisions that we as a WG cannot make..
… we can't decide what the next group is going to do with their registries..
… that makes some of this out-of-bounds.

Kristina Yasuda: some elements could be removed for the registry/interop purpose now, and added back once "mature".

Kristina Yasuda: if "not ready" is a concern.

Brent Zundel: i'd like to explore what charter text changes would be needed for this, because I think the charter already supports this..

Manu Sporny: Let's just do a registry and figure out what goes in that registry during the WG... it's premature right now to make broad statements about the registry..

Kyle Den Hartog: defining a registry, and the contents of entries (via the process) must fit definitions. to make this decision now would affect the charter..

Michael Jones: #67 (comment).

Michael Jones: this also gets to standardized vs unstandardized distinction..
… there are features like evidence that are not standardized. We should be clear in the next step which of these things are done, and which are subject to change..
… jyasskin noted that it should be possible to use only standardized features to implement the spec. important for interoperability..

Kyle Den Hartog: My take is that we are fine in terms of the registry being defined in the charter, but if we make the requirement that a REC track document is necessary then we may get forced to re-charter if we don't call out which rec track documents in the charter now.

Orie Steele: +1, not registering things does not stop folks from working on them... we should be clear how reliable a registry entry is, if the registry will accept entries of varying reliability..

Michael Prorock: +1 Orie.

Manu Sporny: furthering kdenhartog_ point.

Kyle Den Hartog: yup that is.

Manu Sporny: it may be that there is better patent and IP protection in a CCG work item than in a WG Note. there is no patent protection on anything until a patent exclusion period hits.

Michael Prorock: +1 manu.

Manu Sporny: however you can get both if things are strategically republished..
… W3C has published notes that get sent to recommendation track later on. that is a signalling mechanism. CCG doing that carries less weight with the AC..

Orie Steele: Sounds like Kyle is directly contradicting what manu just said..

Orie Steele: I would like clarity on this topic..

Kyle Den Hartog: manu highlighted the patent point well. As far as Notes, the process documents state that the point of the note track is for documents that are not intended to be standardized. Showing work this way for the WG introduces a weird patent consideration. We should state what we are going to standardize..

Kyle Den Hartog: "A Group Note (NOTE) is published to provide a stable reference for a useful document that is not intended to be a formal standard." Found in section 6.4.1 of the Process document.

Kyle Den Hartog: https://www.w3.org/2021/Process-20211102/#note-track.

Manu Sporny: +1 to what selfissued just said.

Michael Prorock: +1 mike - and as a Co-chair of CCG it has its place - but it is primarily incubation related.

Michael Jones: leaving things in the CCG does not ring true to building a standard. leaving things in the CCG loses control of our destiny. pull everything that you want to be a standard in the WG..

Brent Zundel: in light of that, what concrete changes should be made to the charter?.
… we already have a rec-track doc for proof property..
… beyond that, what do we need?.

Kevin Dean: add voice to standardizing what we can..

Kristina Yasuda: proof registry is quite general, do we want registry for compatible cryptosuites? curves?.

Manu Sporny: we do, kristina... I'm on queue to speak to that..

Michael Prorock: +1 Kevin - let's try to get what we can in.

Manu Sporny: +1 to Mike Jones.
… going to suggest... remember when we got the advice to not go to candidate rec? we could do a first working draft. "FPWD" and say that we're not going to publish final until we have maturity, yet get patent protection..
… don't know how AC would respond.
… i don't think the above is a good idea..

Manu Sporny: https://w3c.github.io/did-spec-registries/.

Manu Sporny: on what could go to the registry: we published things in the did-spec registry that should be in this WG, due to constrained charter..

Kristina Yasuda: btw alternative to "mandatory to implement" is "default", saying "this is a default, but if you agreed otherwise feel free to use other curves/cryptosuites", etc...

Michael Prorock: +1 manu - significant learnings as a result of DID WG and FOs / Response that we should take into account here.

Orie Steele: +1.

Ryan Grant: verification methods, verification types.

Kyle Den Hartog: can put forward a list that is structured as an issue. example of revocation list 2020. or even FPWD..

Manu Sporny: status-list-2021 should be the target... not revocation-list 2020 :).

Kyle Den Hartog: we could set it as recommended status..

Kristina Yasuda: do we need to agree on all the registries we plan to set up in the charter?.

Manu Sporny: no, we don't need to do that... typically, the WG decides.

Kyle Den Hartog: yes to Manu's suggestion..

Kristina Yasuda: I assume no, based on did-core registry process.

Manu Sporny: (because tons of conversations happen during WG that change the contents of registry and structure).

Brent Zundel: I don't think we do, but we need to know which extension points would need rec-track documents so we can be sure to include those in the charter.

Kristina Yasuda: ok, then from the charter perspective, we just need to clarify that we intend to leverage registries to ensure interoperability purposes..

Kristina Yasuda: would be my suggestion, at least.

Kristina Yasuda: to address Jeffrey's issue.

Kyle Den Hartog: having an understanding that there are some extensions that will never rec-track (like presentation change) [beneficial].

Kyle Den Hartog: to clarify I think presentation exchange could go REC track, but it would depend on whether the VC registries considers DIF to be an SDO in the sense that it can register Required/Recommended/Optional statuses.

[msporny]

@kdenhartog wrote:

I quite like the WebApps charter approach

Having looked at the WebApps charter approach, I agree, it's much cleaner than what I suggested.

We should take a pass at refactoring the charter to be more like the WebApps charter... it's a good model to follow.

[brentzundel]

I believe this issue won't be truly addressable until we actually define at least one registry deliverable in the charter.

[OR13]

Only required features should have this requirement, optional features should be experimented on in CGs / DIF.

[jyasskin]

@OR13, I commented on the optional fields question in #67 (comment). Would that structure work for you, or do you feel it's important to define some optional fields in a REC without any REC-level way to implement them?

[iherman]

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

• no resolutions were taken

View the transcript

5.1. Each registry should include at least one standardized entry (issue vc-wg-charter#67)

See github issue vc-wg-charter#67.

Brent Zundel: on to #67.
… each registry should have at least one standardized entry.

Manu Sporny: Jeffrey is coming from a good place. If we have a registry, we should have at least one officially defined extension.
… points to the VC extension registry which is mostly empty.
… refresh methods, evidence methods, etc., we don't have normative examples.
… people have also been using all of those, but none of them standardized.
… So, while I agree with Jeffrey's intention, but there are concerns about registries.
… Is it just to document what "we" think is official, or to capture anything in the wild?.

Juan Caballero: can non-W3C members come to VCWG meetings to discuss proposals to the registry?

Manu Sporny: juancaballero, not really due to IPR issues....

Orie Steele: manu mentioned the obvious things this would put at risk: evidence, schemas, ... my opinion is that these items don't belong in the core suite.
… I think there is a lot ot be gained from taking a very sharp knife. We looked at this is the first version. And we saw that these extension points were a nightmare for interoperability.
… Why not let CCG continue incubating without requiring everyone to support these extension points.
… We should cut out anything that doesn't have significant adoption.

Brent Zundel: I think this is a good idea for those properties that are normatively required..
… if its required, but there isn't a definition, it is a problem.
… but for optional properties, I think it's less of an issue.

Manu Sporny: +1 to what brent said. For things that are required, yes. But not for refresh, evidence, TOS, etc..

Orie Steele: +1 manu, everything manu just said is optional..

Manu Sporny: orie, the danger in what you said is that then there are no ways to extend.
… that's my concern. It took 10 years for SVG to be standardized and it kept getting panned because it wasn't a standard yet..
… It's premature to say these things are not useful. I know that all of these fields are being used in the wild..
… I would be fairly big -1 to remove them at this point.

Orie Steele: I am in favor of experiments... I am not in favor of experiments in the core spec..

Joe Andrieu: I want to echo the sentiment, Manu summed it up - options vs. required that Brent introduced is vital. My concern, we have to experiment, we don't know what's going to work, we're all still learning. All specs in this area has acknowledged that fact. We're not building a single monolithic system that everyone wants. There are pieces here that create value, but we don't know what all the pieces need to be..
… I know I've pointed out a number of these properties to my clients, the extension points are vital to having a standard that's relevant both today and tomorrow..

[brentzundel]

PR #101 has been opened to address this issue

[kdenhartog]

Can we leave this issue open even if #101 is merged because I'd like to also discuss the addition of the text "Registries for extension points that are optional to use, should have at least one registered entry point". It could be argued whether we should also add "that are either normatively defined or represented as an IPR protected document" to the end of the sentence as well, but I recognize that further nuance will add a greater level of discussion which is why I'm requesting us to not close this issue once #101 is merged.

[brentzundel]

close based on meeting today

[iherman]

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

• no resolutions were taken

View the transcript

2.5. Each registry should include at least one standardized entry (issue vc-wg-charter#67)

See github issue vc-wg-charter#67.

Brent Zundel: Each registry should include at least one standardized entry.
… The WG came to consensus on language that largely addresses this issue..
… Kyle requested that the issue be left open..
… Kyle wants to expand that to "for everything else, there SHOULD be ...".

Manu Sporny: I think we've done what we can..

Orie Steele: I don't think we use MUST or SHOULD on charter documents either... right?.

Manu Sporny: We shouldn't add SHOULD statements that we know that we're not going to satisfy..
… We shouldn't create a charter that doesn't reflect reality..

Brent Zundel: +1 manu.

Brent Zundel: Charters don't have RFC2119 statements..
… I'm going to close it. I hear no screams..
… We have three more issues..