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

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>"
   }
}

Start with the credential request examples in the issue and review how proof types are currently defined and validated in the OpenID4VCI specification. Done means reaching agreement on public-key-only proof types and documenting their request shape and processing requirements.