[Openid-specs-digital-credentials-protocols] [minutes] DCP WG Meeting April 22nd

Wed Apr 23 12:45:39 UTC 2025

Hi all,

Please find below the meeting minutes of April 22.

Best Regards,
Christian

---

Attendees:

Andrew Regenscheid
Bjorn Hjelm
Brian Campbell
Christian Bormann
Daniel Fett
David Waite
David Zeuthen
Gareth Oliver
George Fletcher
Jin Wen
Joseph Heenan
Kristina Yasuda
Martijn Haring
Michael Jones
Mirko Mollik
Oliver Terbu
Paul Bastian
Peter Sorotokin
Ryan Galluzzo
Steve Venema
Tom Jones
Torsten Lodderstedt

--- Events

- Registration for pre & post EIC events beginning of May.

--- Issues/PRs:

- Improvements regarding DC API - https://github.com/openid/OpenID4VP/pull/465:

5 Approvals, got merged

Revert to JARM style use of authorization_encrypted_response_alg - https://github.com/openid/OpenID4VP/pull/555:

A previous PR removed the dependencies to JARM and changed the way the encryption algorithm selection works, but kept parts of the parameter names (the _enc parameter name). Mike raised an issue that this is inconsistent with JARM and we should revert the change to make it consistent with JARM.
Mike explains that there is a long list of specifications that use a pair alg and enc parameters to identify the encryption and key management mechanisms and that the 2 ways he sees forward are either moving back to the 2 parameters that were present beforehand or using multi-value parameters. Brian responds that the information is redundant and votes to instead rename the _enc parameter to not cause confusion with JARM and agrees to make enc an array if necessary - his main point was to focus on the alg parameter. Gareth voices that he would also be in favor of moving away from JARM parameter name since we are not using JARM and are not following its processing rules. Tobias and Oliver state that they are ok with renaming the parameter and making it an array. Martijn mentions that we should be able to support multiple enc and alg values but asks how those are matched. Brian responds that there is no inter-dependencies between the 2 values and that the motivation to not have alg specified in the PR was to allow Verifiers to move towards HPKE more easily in the future. Mike agrees with Brian that JWE allows for a mix and match usage of alg end enc (no dependencies between the two) and points towards already defined parameters from OpenID Connect Relying Party Metadata Choices 1.0, "authorization_encryption_alg_values_supported" and "authorization_encryption_enc_values_supported". Mike also asks if signing the response might be an option going forward and Kristina responds that since we already have signatures on the vp_token level, we do not need support for signing here. Gareth explains that in their implementation the alg value came from the key anyway and from their experience specifying it additionally was of no value. Martijn adds that allowing all combinations of alg and enc might not be ideal and there might be concerns that certain combinations should not be used (e.g., defined a profile) and it would be nice if we can prevent such behaviour and clearly indicate which combinations are allowed. Mike adds that making the algorithm explicit in the JWK for the case where we choose to pull the alg value from the JWK might help avoid implementation mistakes.
Kristina asks if people object to moving alg to the JWK and not re-introduce the parameter. Martijn asks if a RP would want to support multiple algorithms later on, would this be a breaking change if enc is not an array right now? Martijn voices his concerns that it might be valuable to express support for more than one algorithm in the request, especially given that we generally allow a large set of encryption algorithms. Gareth adds that if the RP would support more than one, then it needs to be communicated. The options seem to be either 2 array for alg end enc, or one array of pairs that specifies allowed alg/enc pairs. Kristina asks if the WG could live with an array of pairs (enc, alg). Mike agrees with Martijn that it would be weird to have multi-valued algs and not have multi-valued encs and it should be single-valued or multi-valued for both. Oliver agrees with Gareth that he would prefer an array of enc values. Brian answers that he understands the general motivation, but is concerned that it might add unnecessary complexity.
Kristina asks the WG to review the PR with her changes reflecting the discussion. Title of the PR will be changed accordingly.

- Error responses for DC API - https://github.com/openid/OpenID4VP/pull/556:

There are quite a few approvals, but that was before the addition of privacy considerations. Kristina asks Gareth to accept some of the editorial suggestions and asks Martijn to review the PR. PR will be merged after Martijn approves.

- remove sub from list - https://github.com/openid/OpenID4VP/pull/568:

Kristina explains that the VCLD profile currently mandated the `sub` claim and the subject information should be in the LD processor part. Kristina asks if there are any strong opinions or objections to that change. Brian voices his general concerns that similar arguments might be made about the other claims and asks if the general requirement for the specified SD-JWT VC claims should be changed from a MUST to SHOULD. Torsten explains that from his perspective this is less about JSON and JSON-LD processing and more about the envelope and payload. From that perspective, everything that is necessary from a security perspective should be mandatory for the SD-JWT VC side and subject belongs to the payload side of things. Brian approves and PR is merged.

- Only reject the presentations that fail checks - https://github.com/openid/OpenID4VP/pull/566:

Merged during the WG call with 7 approvals.

Kristina asks for reviews on "clarify issuer_signed_alg_values and device_signed_alg_values" https://github.com/openid/OpenID4VP/pull/553.

- add language for non-compliant JSON-LD processors - https://github.com/openid/OpenID4VP/pull/563:

Oliver explains that there are cases where you do not require full json-ld processing, but there might be "json only" implementers without proper json-ld processing and this PR aims to make their life easier. The change allows for other methods to compute the type for comparison apart from pure json-ld processing.

- Using 'detached' session information as part of encryption key derivation to solve 'lazy verifier' problem - https://github.com/openid/OpenID4VP/issues/347:

Kristina explains the general concept of APU/APV and prior discussion about not including them in the JWE, but forcing the verifier to make sure that encryption happened with the values they chose might be beneficial from a security perspective, preventing lazy verifier errors for MitM or similar scenarios (since the verifier is force to re-compute those values before decrypting). Kristina continues to propose that APU/APV values might be defined in a profile like HAIP, but that raises the concern that the profile must be known to both sides. Kristina asks the WG if people see value in defining APU/APV values like that.
Mike states that this should be defined in a profile and not within OpenID4VP and Gareth responds that in that case, it would require a signal which profile is used. Andrew states that it seems to make sense to do this within profiles and that NIST SP 800 does not strictly require APU/APV to be conformant (recommended, not required) and if the motivation is mainly compliance to SP 800, then there is no need to worry about it. Andrew continues that generally speaking, from his perspective, defining the APU/APV values seems to make sense to do this and asks what other options for APU/APV values are apart from nonce and client id.
Mike responds that default APU/APV values in SP800 are null, so compliance would be fulfilled without supplying any APU/APV values. Andrew responds that the language in 800 will be cleaned up and the intent was not to make this a requirement (APU/APV not being null). Martijn states that it feels a bit weird to define APU/APV in a profile and requires explicit knowledge about the profile being used. Brian responds that response encryption is fully specified in OpenID4VP right now, only special treatment of the APU/APV values and their validation would be up for a profile to define.
Oliver adds that HAIP currently has a profile indicator for vanilla OpenID4VP flows (via the custom URL scheme), but currently not for DC API and proposes to define a new parameter for the profile used. Martijn also adds that it would also be required for the RP side and it would likely require a new parameter and it would make sense to define that parameter in OpenID4VP.
Kristina goes back to Andrews comment about APU/APV values and asks why not directly define nonce and client_id/origin directly for those in OpenID4VP? Oliver voices his preference to do such a definition in HAIP instead of OpenID4VP. Brian states that a while back we agreed to define specific values for APU/APV and a PR got a lot of push-back and the idea was scrapped - in terms of NIST compliance it seems to not matter, so why revisit the issue? Martijn states that there seem to be different views on the benefits of APU/APV and asks for a profile indicator or guidance in the spec that can be used to signal extra encryption information like also the detached mode.
Andrew states that if the main goal is to protect against a lazy verifier, then including values in the KDF computation can help, but only if those values are generated independently. If you are sending the APU/APV values, then it might not really help with lazy verifiers. If you cannot use implicit values, then there might still be some benefit, but limited and a discussion if that is really needed is fair to have. Andrew later adds in chat that it is arguably a "hygiene" issue, but there doesn't seem to be a clear benefit (of defining APU/APV values if they are explicit) and that he was confused by the relation to the lazy verifier problem.
Kristina asks if there is enough support for a parameter used to profile the encryption. Mike adds that we could add the profile parameter in HAIP. Martijn voices his concerns that this should be in OpenID4VP before it goes to final and there seems to be agreement.

-----

Kristina explains that the first working group last call ended yesterday and there was a majority support, but some concerns were raised like the JARM issue discussed in the call. The chairs propose to start a second WGLC under the assumption that the PRs 563, 556, 555, 536 will be merged and the profile parameter necessary for the encryption profiling will be added before the spec goes final in a non-breaking way. Kristina repeats that we can keep discussing content during the public review if things come up, but this would be the current plan. There are no objections proceeding that way.