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

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1952

Original Reporter: TimoAnimo

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?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

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.

[TimoGlastra]

After thinking about this issue again, I think a follow up question I have is that if cryptographic_suites_supported is about the wallet's signature of the key proof, and only cwt and jwt are supported for this, what is the purpose of this sentence?

Cryptosuites for Credentials in ldp_vc format should use signature suites names defined in Linked Data Cryptographic Suite Registry.

The issued credential can use ldp_vc (and thus proof.type) or jwt_vc (and thus alg), but if this is only about the verification of the proof in the request, then we don't need support for types from linked data cryptographic suite?

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.

In our implementations we've always opted to verify a credential before storing it, mainly because it prevents faulty credentials from being stored (and making sure it can be used later on). But this is of course not a requirement.

I do think the wording in the spec is misleading, as the cryptographic_suites_supported indicates it has relation to the credential that is issued, but rather it's about the algs that can be used for the jwt/cwt proof in the request.

[TimoGlastra]

@Sakurann I think this might be a good clarification to get in before ID-1. It won't have any changes in functionality, but it does provide some clarity on the purpose of cryptographic_suites_supported if my understanding as described in the last comment is correct (that it has nothing to do with the format of the issued credential -- and so the sentence "Cryptosuites for Credentials in ldp_vc format should use signature suites names defined in Linked Data Cryptographic Suite Registry." can be removed)

[Sakurann]

related to issue #214, I think

[tlodderstedt]

Can someone please write down a summary of the proposed changes?

[TimoGlastra]

I'd say we just reword the definition for cryptographic_suites_supported to refer only to the supported cryptographic suites that are supported by the issuer for verifying the proof in the credential request. Not relate it at all to the actual format of the credential that is being issues (as it doesn't matter)

New wording:

• cryptographic_suites_supported: OPTIONAL. Array of case sensitive strings that identify the cryptographic suites supported by the issuer for verifying the identifier of the End-User who possesses the Credential, as defined in (#credential-binding). Cryptographic algorithms for Proof Key Types in jwt and cwt format should use algorithm names defined in [@IANA.JOSE.ALGS]. Cryptographic algorithms for Proof Key Types in ldp_vp format should use signature suite names defined in [@LD_Suite_Registry].

---

But it might be better to move the definition of which values are allowed for each proof_type to section 7.2.1 where the different key proof types are defined. So jwt (in section 7.2.1.1) defines that values in the cryptographic_suites_supported must be valid JWA signature algorithms, ldp_vp (in 7.2.1.2) defines that the values must be valid cryptosuite values, etc...

And here I agree that it might be beneficial to move towards an object-like structure (as proposed in #214). I've created a proposal below how it could look when integrated into proof_types. The same could be done in cryptographic_suites_supported and not combine it with proof_types, but if we update the wording of cryptographic_suites_supported to only refer to the proof in a credential request, it may make sense to combine it with proof_types.

Make proof_types an object with proof_type keys

This is a very breaking option, but just want to propose it here. We could make proof_types an array of objects, and remove cryptographic_suites_supported altogether. It may also make sense to move cryptographic_binding_methods_supported into proof_types as well, as you may support different binding methods based on the proof_type.

An example below, which identifies which proof_types are supported, and for each of the proof types, it also defines which algs/cryptograhpic suites are supported as well.

// cryptographic_binding_methods_supported can be moved
// to proof_types as well if more granular control is needed
cryptographic_binding_methods_supported: ['jwk', 'did:key'],
proof_types: {
  ldp_vp: {
    // can represent both `type` properties as well as `cryptosuite`
    // for when type is `DataIntegrityProof`
    cryptosuites_supported: ['eddsa-rdfc-2022']
  },
  jwt: {
   algs_supported: ['EdDSA', 'ES256']
  },
  cwt: {
   algs_supported: ['EdDSA', 'ES256']
  }
]

This could also be an array, but I think the object with keys as identifiers is more in line with other parts of this spec:

proof_types: [
  {
    proof_type: 'ldp_vp',
    cryptosuites_supported: ['Ed25519Signature2018', 'eddsa-rdfc-2022'],
  },
  {
    proof_type: 'jwt',
    algs_supported: ['EdDSA', 'ES256']
  },
  {
    proof_type: 'cwt',
    algs_supported: ['EdDSA', 'ES256']
  }
]

If we think only one value will need to be represented it can also be just an array, but I like the object structure better for flexibility.

proof_types: {
  ldp_vp: ['eddsa-rdfc-2022'],
  jwt: ['EdDSA', 'ES256'],
  cwt: ['EdDSA', 'ES256']
]

[Sakurann]

discussed on the call:

• change proof_type to a map
• clarify that top level crypto_suites_supported is used for Credential's signature (do we need this one? might remove later)

@paulbastian to open an issue discussing cryptographic_methods_supported being underdefined.