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.

[ssanchocanela]

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.

Hi Paul, could you kindly link here that PR? Thanks

[c2bo]

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.

Hi Paul, could you kindly link here that PR? Thanks

That should be this PR: #293

[Sakurann]

we should prioritize this since if we decide to do it, this would be a breaking change

[paulbastian]

I think this is somewhat solved with key attestation.

[c2bo]

Yeah, I'd agree that the key attestation proof type would solve this problem and was a motivation to introduce that proof type in the first place.

[Sakurann]

WG discussion

• key attestation allows to receive credentials without generating a signature using a public key (PoP), so only one signature by wallet provider. it solves originally raised issue in a slightly different way - would this meet your requirements @tplooker ?

[awoie]

This means that even for simpler use cases that don't require wallet attestations, the issue @tplooker raised wouldn't be solved, right?

[tplooker]

Key attestations provide at least one solution that avoids the repeated re-authentication prompt implementations would otherwise encounter when device keys are generated that require authentication for use. However I think it would be beneficial to enable implementations to also just be able to supply a public key in the credential request. Especially those that are using wallet attestations for client authentication and DPoP bound access tokens which in effect provide some level of assurance about how the device key is stored/managed in directly.

[Sakurann]

WG discussion:

• no support / consensus to add this right now
• we can do it in 1.1
  • by defining a new proof type?
  • key attestation can be used for this (@awoie to check if anything in the current spec text prohibits this)
• push back on defining a new proof type