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.