Is proof type flexibility needed?

[Richard Barnes]

The credential request contains a proof of possession of a private key by the client. The specification has a proof_type parameter that allows for multiple proof types, but only jwt is actually defined. Is this flexibility actually needed? It seems like if a client is already doing the work of integrating with this API, signing a JWT to prove possession is probably not a lot of extra work.

[Tobias Looker]

This is a good question to ask, as the flexibility has the potential to harm interoperability. The rationale for supporting multiple proof types to date is that existing implementations surrounding certain credential formats e.g iso mdl have alternative proof of possession formats that are difficult to control because they leverage technologies such as HSM or secure areas. IMO the constraints that secure areas or HSMs often create in this area are more around attestations than ordinary proofs of possession. So perhaps we should be separating along this conceptual line and treat the possible extensibility points differently? E.g proofs of possession MUST be JWT but attestations can be of different formats?

[Richard Barnes]

Yeah, interoperability is precisely my concern. HSMs seem unlikely to be an issue, since their interfaces are typically defined at the level of raw signatures; you could implement JWT signing with an HSM-backed key. If you wanted to provide the OP with an attestation about the key, you could make that an independent, optional attribute. So you would have a credential request something like:

{
  "type": "MyFavoriteCredential",
  "format": "jwt_vc",
  "proof": "... JWT ...",
  "attestation": {
    "type": "SafeNetAttestation",
    "value": "... base64url(attestation) ..."
  }
}

At that point, however, I don’t really think it would be worth defining the attestation field in this document, unless there were a couple of examples that could be cited in this document. It would be yet another negotiation point / point of interop failure, since as here, the client would need to know when the server needs attestation, and of what type. You would end with a whole pile of server metadata or a complicated negotiation. Better to handle it in an extension.

[Torsten Lodderstedt]

The primary reason for this flexibility is to support other kinds of proofs, especially blinded commitments as used by AnonCreds/CL-Signatures (and other ZKP capable crypto suites).

[Michael Jones]

On the 31-Oct-22 working group call, DW said that the information that needs to be included in the proof will, in general, vary by proof type.

[Kristina Yasuda]

we tried define attestations claim in addition to a proof claim in a PR #293 but we did not reach consensus.

if we are mandating proof claim, and are not introducing an option to send only attestation, this option is definitely needed.

There are implementations that are using OID4VCI to issue ISL mDL, where the key signing the proof will be COSE_key1, so proof_type jwt will not work.

[Torsten Lodderstedt]

There are implementations that are using OID4VCI to issue ISL mDL, where the key signing the proof will be COSE_key1, so proof_type jwt will not work.

Isn’t that the rationale to introduce a cwt proof type (PR #384)?

[Kristina Yasuda]

SIOP Feb-09 call. agreed to review PR #384 to see if this feature is useful. (cc @Oliver Terbu )

need to ask how proof_type will work with ZKP-useing credentials… (cc: @Tobias Looker )

[Kristina Yasuda]

agreed that this is needed with the introduction of cwt proof type.