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

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

[jyasskin]

This interacts with https://github.com/w3c/w3process/issues/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.

[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](https://github.com/w3c/vc-wg-charter/pull/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](https://www.w3.org/2013/09/normative-references). **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](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](https://www.w3.org/2013/09/normative-references) 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.