Encryption details for OpenID4VP over the digital credentials API

[Sakurann]

          WG discussion. 

agreement to encrypt the response. agreement to start with using JWE. agreement to have the same JWE requirements regardless of the credential format. discussion point is how to generate JWE.

does not seem to be agreement to use JWE as defined in 18103-7 already. there seem to be some alignment on detached apu and apv being valuable?

option 1: improve how JWE with ECDH-ES is done. - change apu and apv values?
option 2: define how to do JWE with HPKE. draft in IETF (https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt-02) is not exactly stable. AAD can be set to the combination of [origin, clientId and nonce and encryption public key of the verifier].

Originally posted by @Sakurann in #122 (comment)

[Sakurann]

there is also option 3: define a new encryption mechanism that does not use JWE (see openid/OpenID4VP#310)

we need to document pros and cons of each and make a decision

	pros	cons
option 1	- no breaking changes to the existing implementers	- does not solve lazy verifier problem? (how important is it to solve it?)
	- the simplest / fastest?
option 2	- might or might not solve the lazy verifier problem.	- cannot go to final until the IETF HPKE-JOSE draft is final?
		- not enough expertise in DCP WG?
option 3	- solves lazy verifier problem?	- not enough expertise in DCP WG
		- will take much longer to define
		- can be added later

update: the issue for lazy verifier problem openid/OpenID4VP#65

[andprian]

There are many requirements that are mentioned in /pull/122 that talk about ISO standards. Could we list here what are the exact requirements that we should keep in mind and in which ISO standard they are listed?

[Sakurann]

@andprian they are here: https://docs.google.com/document/d/1AJDDWuRG_b-MOBrAwhBoQV3dhH3LD31WNEQKzOB36SY/edit?tab=t.0

[selfissued]

I'm fine either with option 1 (use an existing JWE algorithm) or option 2 (use https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/). I'm not fine with option 3 because as much as I love the OpenID Foundation, we don't have the cryptographers as members that the IETF does to do cryptographic reviews of a new cryptographic spec.

[Sakurann]

WG discussion:

• what information needs to be communicated in a detached way in this use-case? origin and nonce.
• HPKE seems to be preferred mid-long term
• but IETF HPKE-JOSE draft is probably not reference-able in a stable way before January
• need to check if IETF HPKE-JOSE draft solves lazy verifier problem
• should not rely on session transcript to solve lazy verifier because that is mdoc specific and we want this to work with other credential formats too
• also we need to agree if lazy verifier problem has to be solved right now
• successful decryption alone does not remove the requirement to do all other checks (such as signature validation)
• a viable way forward seems to be to start with option 1 with what we have to meet the deadlines while signaling that we are working on HPKE and add HPKE once it is ready.

[OR13]

Hi, if you wish to get JOSE HPKE to RFC faster, it will need more engagement from implementers.

I've done implementations for compact and json serialization of both integrated encryption and key encryption.

I am not sure which of these options you plan to use / need, but if I can understand what you need, I am happy to generate you some examples.

Do you need to support multiple recipients or JSON serialization?

[jogu]

Thanks Orie!

Hi, if you wish to get JOSE HPKE to RFC faster, it will need more engagement from implementers.

I've done implementations for compact and json serialization of both integrated encryption and key encryption.

I am not sure which of these options you plan to use / need, but if I can understand what you need, I am happy to generate you some examples.

We're using compact serialisation currently, but we do have preference for being able to exclude the AAD or part of the AAD from being communicated to the decryptor in the message. (see openid/OpenID4VP#347 )

I'm not sure about integrated encryption vs key encryption.

Do you need to support multiple recipients or JSON serialization?

We do not currently.

[Sakurann]

WG discussion:

• agreement to what was said in the end of the last call: a viable way forward now seems to be to start with option 1 with what we have to meet the deadlines while signaling that we are working on HPKE and add HPKE once it is ready, since that is more desirable.
  • noting that @martijnharing said they believe HPKE is the better algorithm, better library support, easier, can be implemented in a way that is more secure. (no agreement on this)
• @awoie to open an issue in IETF JOSE-HPKE repo why detached AAD is needed (and say it applies to JWE with ECDH-ES too). should not define that in this WG.
• lazy verifier problem does not apply for OpenID4VP over the digital credentials API?
• @martijnharing said he would like this feature to make the protocol more robust and more secure. agreement that this is not catch-all solution to lazy verifier problem.
• @ve7jtb if the alg supports detached AAD, it should be used to help with lazy verifier check - solution might work with ECDH and HPKE.

next step (@bc-pi volunteered):

• do a PR in OID4VP to say "use JWE with ECDH-ES". that PR will also say parameters in AAD that currently go into the protected header (such as apv and apu), and one of them has to be nonce and the other client_id (or origin when DC API is not signed). will try frame it in a way that does not lose alg agility once detached AAD becomes available
• will need a small PR in HAIP mandating a specific alg/curve, once we agree on it. (consider adding MTI crypto suites  #112)

[TomCJones]

What's the specific requirement to address encryption in high assurance?

[awoie]

• @awoie to open an issue in IETF JOSE-HPKE repo why detached AAD is needed (and say it applies to JWE with ECDH-ES too). should not define that in this WG.

@Sakurann @martijnharing @selfissued issue created here ietf-wg-jose/draft-ietf-jose-hpke-encrypt#13

[jogu]

will need a small PR in HAIP mandating a specific alg/curve, once we agree on it.

Discussed on today's WG call; consensus on P-256 (which matches what new part 7 draft browser profile uses).