w3c
Require registries to include "enough" standardized entries
The Verifiable Credentials 1.0 Recommendation defines several fields (e.g. "proof") by referring to CG draft reports from within notes. The VC WG is currently rechartering to, as I understand it, fix that by replacing those non-normative field definitions with normative references to some Registries whose entries will define the meaning of those fields' contents. Discussion in https://github.com/w3c/vc-wg-charter/issues/67 indicates that some members of the WG are opposed to including any entries for those registries in the REC-track deliverables for the WG. That means that by indirecting through a Registry, the WG would avoid the requirement in https://www.w3.org/2013/09/normative-references that Recommendations' normative references be to similar-maturity documents.
I don't see anything in the Process or the normative references guide that discusses how to tell if a registry's contents are mature enough to reference normatively, and I think there should be such guidance.
I don't want to claim that normatively-referenced registries can only have REC-level entries: it's appropriate to allow non-standardized terms to be registered early and easily, so that implementers can experiment with and incubate extensions.
However, a REC should be sufficient to produce interoperable implementations, and one that refers critically to names defined in an empty Registry isn't sufficient for that. Similarly, if the REC looks up a name in a registry in order to find an algorithm associated with it, and none of the possible resulting algorithms are REC-level, that's again not sufficient to produce interoperable implementations.
Hi, thanks. The conceptual model of registries was that the viability/implementability/conformance of the spec. should not depend on what's in the registry. I think that this mental model is put under strain here, and we should dig a bit. One aspect of the strain is that in many specs there are 'baseline' values for registerable fields that represent mandated technologies that all must implement, but 'proof' here has no mandated proof methods, and so indeed the viability of the spec. depends on there being at least one viable registered proof method (or else we risk being in the assume a can opener state).
I think we should try to write the (normative) registry definitions for those registries, and see what we come up with. Perhaps this registry will be very strict – to enter into it, you have to show interoperability, proof of implementation, and the definition must be something that could be normatively referenced under the W3C's normative reference policy, for example.
