Turn this into a W3C Draft Registry

[jyasskin]

There's some discussion on this in #17, but I'll file this focused issue to avoid distracting further from that one's original topic.

This document is referenced by https://www.w3.org/TR/vc-data-model-2.0/#extensibility as the way for implementers to figure out how to implement the various extension points in the VC data model. To make it effective for that purpose:

1. It should be a normative reference from that document, which implies that it should be able to get to the same maturity as vc-data-model as that goes eventually to REC. Since this document will need to be updated continuously as new extensions are defined, the Registry track seems like the best fit.
2. The tables here should include the "type" value that indicates the particular extension, and (as they already do) a link to the specification that defines what to do when that "type" value appears. (It's possible some of the extension points use a field other than "type" to identify the extension; I only checked https://www.w3.org/TR/vc-data-model-2.0/#status and https://www.w3.org/TR/vc-data-model-2.0/#securing-verifiable-credentials.)

@TallTed is worried in #14 (comment) that "this feels like a competitor to IANA registration, with little to no gatekeeping, especially as compared to IANA.", but the WG is free to define whatever level of gatekeeping it wants. The "registry definition" "Define[s] the method and criteria by which changes are proposed, approved, and incorporated.", which could easily refer to one of the categories from https://www.rfc-editor.org/rfc/rfc8126.html#section-4, and the W3C "custodian" can be used for the same purpose as IANA's "designated expert". As long as y'all don't create a registry that actually duplicates an existing IANA registry, this seems fine.

I suggest using Specification Required as the criteria by which changes are approved. This ensures that the registry is sufficient for helping implementers figure out how to interoperate, but it doesn't allow any particular standards body to gatekeep which extensions are allowed, as long as they're documented sufficiently.

[OR13]

I support this, we have struggled with similar informal registries in the did wg, if a more rigorous process can be applied, I think that will make it clearer to both the registry maintainers and folks wondering what W3C registers vs endorses.

[iherman]

This issue is moot; the official document explicitly says this will not be a registry. I mark it as pending close.

[jyasskin]

https://w3c.github.io/vc-specs-dir/#sotd does say "This document is not a formal registry nor is it intended to become a Registry Track document", but the point of this issue was to argue that those words are a mistake. It doesn't make sense to close this on the grounds that it's not already the status quo.

The WG could certainly make a decision to keep it a note, but that leaves the main spec in an awkward place, with either a mostly-normative reference to a non-normative document, or no breadcrumbs to help an implementer figure out what to do with an unknown extension.

[iherman]

I am fine removing the 'to be closed' flag, @jyasskin. To be discussed further @brentzundel @msporny