Missing link between `cryptographic_suites_supported` and `format` of credential

[Timo Glastra]

The credential issuer metadata defines the cryptographic_suites_supported property, which indicates to the wallet which cryptographic suites an issuer supports for a specific credential type.

However I feel like there’s a missing link between cryptographic_suites_supported, the algorithm used in the proof in the credential request and the cryptographic suite that is used for signing the credential.

‌

When the issuer offers the wallet a credential of type ldp_vc and the cryptographic_suites_supported includes Ed25519Signature2018, however the proof in the credential request includes a proof with an ES256 JWS for did:example:123, is this valid?

The credential is issued in the ldp_vc format and the spec mentions:

Cryptosuites for Credentials in jwt_vc format should use algorithm names defined in IANA JOSE Algorithms Registry. Cryptosuites for Credentials in ldp_vc format should use signature suites names defined in Linked Data Cryptographic Suite Registry.

However this doesn’t mention how the cryptosuites should impact the proof in the credential request. Could the cryptographic_suites_supported also contain EdDSA / ES256 even though the credential is issued in ldp_vc format? Or should you infer the alg to use for the proof type based on the crypto suites supported (Ed25519Signature2018 maps to EdDSA, etc..)?

‌

In some API’s I’ve seen where we used ES256 for the credential request proof, but the credential was always issued in Ed25519Signature2018 format. Should the wallet have control over this?

[Kristina Yasuda]

Assumption is that the credential is bound to a representation of a key pair (jwk, cose_key, or a DID expressed using cryptographic_binding_methods_supported. the same key pair is being used to sign the key proof in the credential request. There should not be a case when a key proof is signed using an algorithm that is not in the cryptographic_suites_supported.

Probably the definition ofcryptographic_suites_supported should be updated to say that it is Array of case sensitive strings that identify the cryptographic suites that are supported to verify the Wallet's signature on the Key Proof.

[Kristina Yasuda]

this kind of triggers a separate question in my mind whether the issuer needs to publish the metadata of the supported crypto suites for signing the issued credentials. at least in my current mental model, it is not mandatory for the wallet to verify whether the signature on the issued credential is valid or not, so no need for such a parameter. the wallet only cares about generating the key binding signature using its private key during the presentation.

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VCI