Support credential requests which communicate only the public key instead of the pop

[tplooker]

As was raised recently during the DCP WG face to face call.

If a wallet is making use of cryptographic keys that require some form of user authentication in order to perform a cryptographic operation, this creates problems when say multiple credential copies are being issued in the same user flow, because the credential request currently requires a proof of possession per key. Meaning the user would have to authenticate N number of times, where N is the number of credential copies being issued.

In these situations instead of requiring a proof of possession per key, we could consider a credential request where only the public key or cryptographic identifier is communicated instead of also communicating the proof of possession.

As one possible solution. We could expand the proof types to not only be proofs of possession but also just public keys by defining a jwk and COSE_Key proof type.

E.g here is a credential request using the hypothetical jwk proof type

POST /credential HTTP/1.1
Host: server.example.com
Content-Type: application/json
Authorization: BEARER czZCaGRSa3F0MzpnWDFmQmF0M2JW

{
   "format":"mso_mdoc",
   "doctype":"org.iso.18013.5.1.mDL",
   "proof": {
      "proof_type": "jwk",
      "jwk": { ... }
   }
}

Whereas a proof type of COSE_Key might look like

POST /credential HTTP/1.1
Host: server.example.com
Content-Type: application/json
Authorization: BEARER czZCaGRSa3F0MzpnWDFmQmF0M2JW

{
   "format":"mso_mdoc",
   "doctype":"org.iso.18013.5.1.mDL",
   "proof": {
      "proof_type": "COSE_Key",
      "COSE_Key": "<b64 CBOR encoded COSE_Key>"
   }
}

[paulbastian]

This may also relate to PR on reworking batch credential issuance.

Additionally it relates to the latest thinking that wallet/client attestation could include an array of public keys that are already attested by the Wallet provider.

[jogu]

I think this change as suggested would make the security issue highlighted in https://github.com/openid/OpenID4VCI/issues/19 worse?

On Paul's comment:

Additionally it relates to the latest thinking that wallet/client attestation could include an array of public keys that are already attested by the Wallet provider.

Is there an issue about that somewhere? If the wallet is authenticating to the verifier (required in the EU?) then that would mean the wallet needs attestations both with and without the public keys (and to use the correct one in the correct place) or we've broken the unlinkability property?

[tplooker]

I think this change as suggested would make the security issue highlighted in https://github.com/openid/OpenID4VCI/issues/19 worse?

Thanks for connecting the dots, have left a comment there, I wouldn't say it makes it worse at this stage because I'm not sure I agree that the current proposed solution in that issue actually fixes the issue.