[Openid-dcp] [notes] DCP WG + SIOP Call (EU) 5th of June

Thu Jun 5 20:52:28 UTC 2025

Hi,

Below are the meeting minutes from the working group call June 5th.

Best Regards,
Christian

--- Attendees:

Andreea Prian
Bjorn Hjelm
Brian Campbell
Christian Bormann
Cosmin Mogos
Daniel Fett
Gareth Oliver
Hicham Lozi
Jan Vereecken
Joseph Heenan
Kristina Yasuda
Lenah Chacha
Max Crone
Michael Jones
Oliver Terbu
Oriol Canadész Díez
Patrick Amrein
Paul Bastian
Rajvardhan Deshmukh
Thomas Darimont
Torsten Lodderstedt

--- Events/Updates

- Mike mentions that Working Group Last Call started on JOSE HPKE: https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/ - https://mailarchive.ietf.org/arch/msg/jose/Oj8c3wqoOvI0j9u5zH8MF_LIEsU/

--- Issues/PRs:

OpenID4VP Issues/PRs:

Kristina explains the current timeline, which would currently would mean that the start period for voting would start 9th of June, but the expectation was that the encryption PR would be merged sooner. There is the option of extending the public review period if necessary - will be discussed at the end of the call depending on how the PR discussion goes.

Defined APV values for ECDH-ES - https://github.com/openid/OpenID4VP/pull/628:

Gareth and Kristina explain the current discussion between defining APU/APV values or creating a profile identifier that could be used to specify and signal encryption profiles later on. Kristina asks about the opinion of the working group of the encryption topics and the current timeline of public review. Mike asks what attack this prevents and how it is prevented. Kristina references the original issue and Mike asks what the attacker can achieve if we don't do this? Gareth answers that with detached the gain is a lot clearer (especially under the assumption of lazy verifiers), but for the current mode of APU/APV the benefit is a lot weaker.
Mike asks for a concrete attack that is possible if we don't do this. Hicham responds that there is not a strong argument describing an entire attack, but it helps the RP to better detect relay or MitM scenarios and fail early before decrypting, not even looking at the payload data. Mike responds that forcing the verifier to correctly construct the apu/apv values would help, but by having the apu/apv in the header, you don't get those properties without detached mode.
Hicham responds that it doesn't solve the lazy verifier problem without detached, but a RP that does proper checks would still be allowed to fail early with those values in APU/APV. Gareth agrees that a properly implemented verifier can fail early with those values. Joseph relays Torsten's question that we have nonce and audience in the signed payload and asks why we need that additionally for encryption. Gareth agrees that we have that information in the signed parts, it would just allow earlier in more simple code before decoding the possibly complex credential structures. Christian asks if we can go the easier route for the non-detached variant and only use single values for APU/APV making the construction a lot simpler
Kristina sums up the general 3 options existing right now:
1. Do not define APU/APV right now for non-detached mode and once detached comes out define clearly the inputs
2. Define APU/APV right now and we can discuss the concrete values
3. Create an extension point to define values later/elsewhere

Hicham responds that the benefit of the input verification is always and detached mode only forces those checks. APU/APV values only make sense if someone expects those values and checks them. Hicham asks if the receiver is asked to blindly use those values and not check them and Mike responds that that is how JOSE libraries currently work. Joseph responds that he is relatively sure that some JOSE libraries allow you to check the header before doing decryption. Hicham asks that later on for HPKE, we would need to define those values that are used as input for the key derivation or signal a profile that conveys what to use. Gareth says from a spec point, we could either say for 1.0 the values are undefined, or define specific/fixed values, or define an extension point.
Kristina asks if people are convinced that defining APU/APV values are of value right now. Mike responds that he is not convinced since you need to implement those extra checks to get any benefit from it and we already validate those values within the decrypted payload. Brian responds that there has been quite a bit of discussion about this but from his perspective, we have not reached the point where a clear rationale for this feature is shared by everyone in the WG. He states his opinion that this will add unnecessary complexity and likely cause interoperability problems. Joseph responds that from his perspective the added complexity isn't too high and avoiding the credential parsing is of value if possible (by failing early in the decryption).
Kristina mentions that in 18013-7 APU/APV values were defined and tested. Mike asks which APU/APV values were used and Oliver answers that the values are different and there has been discussion in the working group that other values might have to be added which matches the PR from Gareth. Patrick states that he is a bit reluctant to add this last minute and points out that we already had some problems with such constructions and mentions the problems we had with the nonce and doubly base64 encoding. Gareth adds that -7 is the pre-DC API and there would need to be some differences. He also adds that from his perspective the overall complexity of this addition is not too big.
Kristina summarizes that there is a slight benefit of defining these values and there is some experience with this feature, but there seems to be no consensus of adding this, especially this late in the process. Kristina proposes to close both PRs and go forth with the current version.
Gareth responds that the practical implication is that we cannot easily change this in 1.1 since it would be a breaking change. Joseph adds that the practical implication might be that the Annex B in the ISO WG might have a dependency on the HPKE draft. Mike responds that profiles could overwrite the APU/APV values since the spec is silent about them, so profiles could define their own values. Joseph responds that was the point we started with and we would need an identifier to signal that mode.
Kristina asks if there is really no option to specify this later? Oliver responds that if people create a profile right now without a profile indicator that would break the implementations - it would be really hard to add this later on in a non-breaking manner. Christian adds that if we do not define values right now and we do not define a parameter to signal encryption profiles, it would break implementations if we add this later. Gareth responds that it would cause failure of the presentation and it would be nicer if the client could fail, but this flow would just result in the verifier to fail the validation.
Paul adds that this is a pretty significant change and he would be in favor of adding this later. Kristina summarizes that given the current discussion, the direction seems to be to close the 2 PRs and go final as is without defining APU/APV and asks if anyone objects. There are no objections.

Add privacy considerations - https://github.com/openid/OpenID4VP/pull/509:

Kristina asks of feedback from reviewers. Daniel responds that he didn't finish yet, but so far it looked fine to him. Kristina asks for people to review and several people volunteer to review until next week.

OpenID4VCI Issues/PRs:

Kristina quickly goes through issues/PRs in VCI that need reviews/attention:
#540 #522 as the 2 options to integrity protect the encryption key
#500 needs more reviews

PRs that need more reviews are labelled - please review.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250605/3275c13d/attachment.htm>