Proposal: require VCDM 2.x in OB 3.1/CLR 2.1

[ottonomy]

Among other things, the optionality of the JSON-schemas in accepting VCDM 1.1 and VCDM 2.0 makes the schemas pretty unwieldy. Historically, it made sense that we allowed VCDM 1.1 and 2.0 in OB 3.0/CLR 2.0, because VCDM 2.0 had not yet been published as a final recommendation, so many implementers were still on VCDM 1.1.

Now that we look ahead to our next version, that's no longer the case.

I think removing VCDM 1.1 support would be fairly minimal in difficulty while carrying significant benefits for reduced complexity. And no worries if a vendor can't update right away, OB 3.0 will still remain viable even after the market begins moving to a forthcoming 3.1. Backwards compatibility of OB 3.1 credentials would seem to not be harmed by this slight narrowing of the options.

The ability to use JWT proofs is the main place where we would need some planning and careful decision-making. While vc-jose-cose exists, it may remain quite light in VCDM 2.0 implementation. The JWT method used to sign VCDM 1.1 credentials is not in use for VCDM 2.0 credentials. Some significant portion of the JWT-favoring community seems aligned on SD-JWT securing mechanisms for claims, though SD-JWT support for VCDM itself is not quite clean. We should listen to our implementer community on the securing mechanisms they want to use with OB/CLR credentials and make careful decisions about how we describe the options to use different securing mechanisms and also (separate question) on what we choose to bring into our certification program.