JWT VC/VP support

[clehner]

VC Data Model has a proof format for JSON Web Token (JWT): https://www.w3.org/TR/vc-data-model/#json-web-token. Currently DIDKit only offers the linked data proof format. We should support the JWT format as well.

ssi has JWT support already, as used in its vc-test-suite driver; we just need to expose this in DIDKit's API.

DIDKit's API for VCs and VPs is largely based on VC HTTP API. vc-http-api does not yet support JWT format; there is an issue about it here: w3c-ccg/vc-api#42

Another API for JWT VCs/VPs is here: https://github.com/decentralized-identity/did-jwt-vc

Adapting the vc-test-suite driver API is another option. But I don't think it is really meant for this.

The API needs to support JWS Compact Serialization. Does it need to support JWS JSON Serialization also?

ssis VP verifiableCredential field uses a type CredentialOrJWT. We could update VC issue/verify functions to accept that type. Or extend the Credential type to be able to (de)serialize in either format based on a field indicating the format. Adapting the existing credential type could avoid needing breaking changes in the API. We could also similarly update the VP issue/verify functions, either adding a PresentationOrJWT type, or extending the existing Presentation type.

We should also support JWT VCs/VPs that don't have a JWS but use a linked-data proof instead, as described here: https://w3c.github.io/vc-data-model/#jwt-encoding
Credential::encode_jwt_unsigned and Credential::from_jwt_unsigned functions can be used for this. The Presentation struct could have a similar functions added. But vc-data-model says "the issuer MUST use JWS to represent proofs based on a digital signature", while all our existing supported proof types are based on digital signatures, so in practice we would probably not be able to use this mode until we can externalize proof types (spruceid/ssi#174).

We may be able to adapt DIDKit's VC/VP issue/verify functions for JWT VCs/VPs. To do this, we must handle LinkedDataProofOptions for JWTs. We could either adapt and use the existing proof options, or define a separate set of options, or a combination. If using only existing options, we probably still need to define an option to request JWT issuance - or a new function/method.

This problem of mapping linked data proof options to JWTs is also approached in the did-jwt-vc library: decentralized-identity/did-jwt-vc#61. did-jwt-vc maps the domain linked data proof option to the "aud" (Audience) JWT Claim, as they have a similar meaning. They also map the challenge option to the nonce claim defined in OpenID Connect Core 1.0 and registered in JSON Web Token Claims, as these also seem to have a similar meaning. nonce is also used in a non-normative example of a JWT VP in vc-data-model.

After domain and challenge, other linked data proof options are:

• verificationMethod - DID URL of the verification method creating the proof. We could map this to the kid JOSE header property; that would be consistent with vc-data-model JWT encoding. The JWK may already have a kid property; in that case we could either error or override it.
• proofPurpose - This is supposed to mean the purpose of the proof. It corresponds (as far as I can tell) to a verification relationship in the DID document, that is between the verification method (public key) and the DID subject (as VC issuer or VP holder/presenter). Proof purpose for VCs is usually assertionMethod, and for VPs, authentication; those are the defaults DIDKit is using for issuance and verification. We could disallow the proofPurpose option for JWT VC/VP issuance/verification and assume the defaults (assertionMethod for VC, authentication for VP). If we want to support JWTs for other things than VCs/VPs, we could revisit this. Or we could use a JWT claim for proofPurpose, e.g. proof_purpose; this should be registered as a public claim name.
• created: datetime of proof creation. vc-data-model notes, "Linked Data Signature created property establishes a date and time before which the credential should not be considered verified"; this seems consistent with the meaning of the "nbf" (Not Before) Claim, "the time before which the JWT MUST NOT be accepted for processing". But vc-data-model already defines "nbf MUST represent issuanceDate". vc-data-model does not seem to define the meaning of nbf for VPs, which don't use issuanceDate. It is noted that a future version of vc-http-api may deprecate issuanceDate in favor of issued and validFrom - but those are not defined in the context for VerifiablePresentations either. It's not clear to me if it would be safe to use nbf for created for a VP, as maybe other implementers would interpret it as corresponding to issuanceDate of the VP's embedded VC. We could disallow created as an issuance option for JWT VCs/VPs, but for verification use it to verify the nbf field.
• checks (verification option): the checks to perform. Unspecified currently, except for "proof".

If we want to support verifying JWTs VCs/VPs issued from non-DID issuers, additional work will be needed, either to add a way to pass public keys in the API, or to resolve non-DID URLs to retrieve public key material.