Definition of all key formats are left out of scope of the VC data model and crypto suites

[kdenhartog]

At the request of @msporny in #82 I'm opening this issue in order remove key formats from the scope of the VC WG Charter. This has a direct impact on the decision made in #82 as well

[kdenhartog]

In order to consolidate discussion as @quartzjer pointed out in #83 this will help focus this issue a bit so we can close #83.

Potential key formats to consider:

1. DID -> publicKeyJwk
2. DID -> publicKeyMultibase
3. DID -> blockchainAccountId
4. DID -> publicKeyBase58
5. DID -> publicKeyHex
6. HTTP URL -> JWK
7. HTTP URL -> JWK set
8. HTTP URL -> X509 Certificate (Not sure this is how it would normally be dereferenced)
9. HTTP URL -> DER encoded public key
10. HTTP URL -> PEM encoded public key
11. Email -> PGP key

One approach is to not couple the method chosen to the signature suite. This way implementations could choose which they support just as they choose which signature suites they support or which algorithms they support. Another approach is to specifically tie a one or many identifer -> key format patterns to each spec used for securing verifiable credentials. Both are credible paths with different tradeoffs and I believe we should be making a scoping discussion about this now because it will affect whether or not we need to bring new key formats such as blockchain accounts or multibase into the normatively defined documents section so that we can reference that document in the securing verifiable credential documents.

[brentzundel]

closing, based on meeting conversation

[iherman]

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

• no resolutions were taken

View the transcript

2.6. Definition of all key formats are left out of scope of the VC data model and crypto suites (issue vc-wg-charter#97)

See github issue vc-wg-charter#97.

Brent Zundel: Definition of all key formats are left out of scope of the VC data model and crypto suites.

Orie Steele: Kyle and I have been chatting about this a lot.
… I've encountered an argument in favor of his position..
… Basically, we have envelope formats we intended to support - for embedded and external proofs.
… JOSE and COSE define key formats.
… There are non-standard key formats that aren't defined by the IETF.
… If you're defining a new envelope format, should you concretely bind the signature format to the key format?.
… By convention, the answer to that may be yes..
… Kyle is objecting to making that a normative requirement..
… Imagine you have a CWT signed by a key represented in JWK format..
… The two can be represented in different formats..
… This could get very painful if there is an unbounded number of key formats per signature format..

Manu Sporny: There's nothing we're doing that prevents arbitrary key format conversion.
… We aren't preventing this in the charter.
… Telling people that they have to do arbitrary key conversion isn't doing people any favors.
… -1 to not strictly saying what the input key types are for crypto suites.
… We need to provide a full-blown test suite if we're asking for arbitrary conversions..

Michael Jones: Two points.
… Remember we talked about how protocol usage affects data structure design? This is one of those places, I think, in practice..

Orie Steele: +1 to what Mike is saying..

Michael Jones: Again, modelling after OpenID Connect, there are places where JWTs are used, but there are places where keys are included and those keys are JWK format. That promotes interop. To the extent that keys will be passed as protocol elements, we are better off having a small or singleton set to promote interoperability. I'm not asking to put this into the charter, but once we're in the WG, whether we want to make JWK support mandatory is a fair question..
… I agree with Manu that arbitrary key conversion is evil both from implementation and interop mechanism, would rather we have a small set of key formats when moving forward..

Brent Zundel: This is something the WG needs to continue talking about.
… Charter changes aren't needed to have these conversations.
… I'm going to close this issue on that basis if there are no objections.

Dave Longley: +1 to brent, we should have the WG continue this discussion, no charter changes required.

Manu Sporny: +1 to close and take conversation up in VC2WG..

[kdenhartog]

I'm not sure this can be completely left to a future VCWG discussion for one small reason. I see two potential changes to the charter that need to be made to enable certain discussions.

While I do think this is largely a design choice that fits under the patterns and design choices of the specific conditional normative cryptosuites (and wouldn't require any charter changes on that front), the statement "The normative specification of APIs or protocols" will impact the ability to normatively define the authorization model and checks within those cryptosuites. This is because the cryptosuites will require a normative protocol definition in order to resolve the identifiers to the public keys as well as to perform the necessary authorization checks in order to validate that the keys usage is being done properly. I'd propose that to resolve this issue we need to allow ourselves the ability to normatively define how the identifier to public key mapping is being done as well as we need the ability to normatively define the proper authorization checks that need to be done. This is regardless of if we support a single format for each suite, if we support a many to one definition for each suite, or if we leave this undefined and consider it an extension point like I've advocated before (which I think are all options that can be left to the WG later).

The other potential argument to be made is whether multibase/multikey is going to be normatively defined within this WG (and as such needs to be listed in the charter) or if that work will be done elsewhere and then the cryptosuites will reference those definitions. For other formats like PEM/DER/JWK/CWK etc we've got normative references that can be referenced so no concerns on that front.