Registries and standardized entries

[brentzundel]

This PR build on PR #98 to address Issue #67.

It adds language that requires registry entries for normatively required extensions to have at least one standardized entry.

---

Preview | Diff

[msporny]

We currently don't have normative deliverables in the current charter defined for any of the following extension points:

https://www.w3.org/TR/vc-data-model/#status
https://www.w3.org/TR/vc-data-model/#evidence
https://www.w3.org/TR/vc-data-model/#terms-of-use
https://www.w3.org/TR/vc-data-model/#refreshing
https://www.w3.org/TR/vc-data-model/#data-schemas

One reading of the language in this PR wrt. "normative registry entries" is that every single one of those features should be removed in the VC 2.0 work, which I expect would lead to objections from organizations relying on those extension points out in the field. I have no alternate language or action to propose, other than closing this PR.

[brentzundel]

The language introduced in this PR would require standardized entries for normatively required extension points.

None of the extension points you mentioned are normatively required, so none of them would need to have a standardized entry, i.e., none of them would need to be removed from the spec.

[msporny]

None of the extension points you mentioned are normatively required, so none of them would need to have a standardized entry, i.e., none of them would need to be removed from the spec.

Ah, now I see the intent of the language. I'm not opposed to the premise, though I don't think it would address @jyasskin's concerns? He will have to weigh in on that.

I'll try to propose some alternate language that makes it clear what "normatively required" means, but before I do that... proof is only normatively required for embedded proofs, so even for that, there's an argument that we don't have to define anything normative (even though we're going to do that).

[msporny]

Ok with this given the proposed changes are accepted.

[OR13]

same comment as manu's

[jyasskin]

This interacts with w3c/process#597, where @dwsinger suggested that "we should try to write the (normative) registry definitions for those registries, and see what we come up with." I'm happy with that approach: accept @msporny's position for the charter, and then see if the resulting specification looks reasonable. That does include the risk that it'll wind up looking unreasonable in the Proposed REC and result in a formal objection then, so please remind me and the Process CG folks to take a look before that.

[selfissued]

I support this PR. I believe that it achieves @jyasskin 's goals in #67.

[kdenhartog]

Suggested change

	a Verifiable Credential), must have at least one standardized entry.
	a Verifiable Credential), MUST have at least one standardized entry.

Not sure if this requires normative text to define so just wanted to point it out as an option.

[msporny]

Not sure if this requires normative text to define so just wanted to point it out as an option.

W3C Charters typically do not use normative spec language. Doing so might raise a few eyebrows within the W3C AC during the vote. I suggest we stay away from BCP14 language.

[kdenhartog]

Thanks, will note that info in the back of my head as well.

[iherman]

(Purely editorial) It may be that my non-native English is the problem, but the formulation sounds a bit odd to my ears...

Suggested change

	to support extension points in the above normative deliverables. Registries for
	to support extension points in the normative deliverables listed in the previous sections. Registries for

[iherman]

Same as the previous comment

Suggested change

	extension points that are mandatory to use, for any of the above normative
	deliverables (for example, Verifiable Credential properties that MUST be included in
	extension points that are mandatory to use for any of the normative
	deliverables (for example, Verifiable Credential properties that MUST be included in

[iherman]

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

• no resolutions were taken

View the transcript

1.4. Registries and standardized entries (pr vc-wg-charter#101)

See github pull request vc-wg-charter#101.

Brent Zundel: will spend the last few minutes on 101 instead of 100.
… this adds a line to the section we just merged, that says " registries for extension points that are mandatory to use, for any of the above normative deliverables (for example, Verifiable Credential properties that MUST be included in ... must have one standardized entry".

Kyle Den Hartog: a must for required properties and a should for optional, allows us to get to a more solid ground. This lets us define how extension points work in an interop way.

Joe Andrieu: My question is what does standardized mean?.

Kyle Den Hartog: +1.

Joe Andrieu: all but one SO calls their standards standard, we need to clarify that language to know what it means..

Kyle Den Hartog: we can replace with REC Track document.

Kyle Den Hartog: ahh yeah makes sense.

Dave Longley: "REC track or equivalent level?".

Brent Zundel: we cant say rec track because it might be from IETF or ISO, there is a general understanding and it may be defined somewhere.

Ivan Herman: See "normative references" for W3C.

david: don't think it makes sense to have a must or a should for registries, if you take terms of use the semantics of it is very broad..
… to say you should/must doesn't make sense when the semantics are wide..

Orie Steele: Should we even be using BCP14 language on ANY charter item? - https://github.com/w3c/vc-wg-charter/pull/101/files#r822616764.

Manu Sporny: we can use the same definition, for making a normative reference in the w3c and thats a well known tried and true mechanism. I agree with david chadwick said, I was under the same impression that terms of use status etc, but this PR does not apply to them. This only applies to the proof block. We're saying if you're using an embedded proof, you need ot use a REC track entry. IDK if others had this same understanding, this applies to almost no entry except the proof block.

Ivan Herman: manu almost said but normative reference in w3c recommendations says which kind of document I can refer to normatively, which covers the various things Joe wants, and that is very appropriate add a reference to in the charter..

Kyle Den Hartog: for this PR its probably beneficial to not talk about the should but leave open the issue for optional properties, i think there's consensus on the must aspect. I think the issuer property needs to be more strongly defined, in how we dereference it to Public key materials, which will affect the proof properties.

Joe Andrieu: this does only apply to normatively defined properties but it binds the group in what i think is a bad idea. it means we can't define a normative field that doesn't have a predefined process. I think making it mandatory is premature..

[brentzundel]

Changes requested and made, approved by both listed chairs, merging according to our current work mode.