[Openid-specs-digital-credentials-protocols] Notes from 11th April WG meeting

[Joseph Heenan]

Minutes are below; please reply to the list if anything needs to be corrected. Many thanks to Raj & Gareth for taking notes!


Post-IIW Spring 2025 DCP WG minutes

Note Takers: Rajvardhan Deshmukh + Gareth Oliver
Attendees
Rajvardhan Deshmukh
Joseph Heenan
Kristina Yasuda
Steve
Christian
Paul Bastian
Torsten
Brian Campbell
Lee Campbell
Hicham
Oliver
Aaron P
Bjorn Helm
James FacePOS
Luca Giorgino
Martijn Haring
Zoey
Stefan
T.P.Selvakumar
Petteri Stenius (Ubisecure)
JC Lee | Turing Space
Gareth Oliver (Google)
Paddy Bolger
Helen Qin
Action Items
https://github.com/openid/OpenID4VP/pull/401
Will address Lucas’s comments during public review until we get written confirmation. Will merge the PR now.
https://github.com/openid/OpenID4VP/pull/523/files
Merging this PR. Chairs encourage folks to read it and then raise issues if they see anything missing.
Oliver will create an issue about cbc vs gcm for default and we will follow up the discussion.
Minutes
60 Day public review. 
Adding a feature is easy, so plan to add more with consensus and if needed remove it during public review. Even for non-editorial changes.
https://github.com/openid/OpenID4VP/pull/401
Will address Lucas’s comments during public review until we get written confirmation. Will merge the PR now.
https://github.com/openid/OpenID4VP/pull/523/files
Merging this PR. Chairs encourage folks to read it and then raise issues if they see anything missing.
Brian will open an issue about adding examples for JARM.
https://github.com/openid/OpenID4VP/pull/477
Oliver is  suggesting a different default for enc algo.
Mike will share a link to text that says gcm default support is required for JARM.
https://www.iana.org/assignments/jose/jose.xhtml is the IANA JOSE Algorithms registry.  In it, A128GCM is Recommended for JWE implementations and support for A128CBC-HS256 is required for JWE implementations.
A128CBC-HS256 is a composite algorithm defined by a cryptographer at Cisco in the CFRG and is an authenticated encryption algorithm - unlike bare A128CBC.
Oliver will create an issue and we will follow up the discussion.
https://github.com/openid/OpenID4VP/pull/465
Won’t need WG time, can resolve in the PR comments.
https://github.com/openid/OpenID4VP/pull/459
Dropping the topic for today, PR to remain open.
https://github.com/openid/OpenID4VP/pull/500
Fully specified/defined algo: Those that fully determine the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc.  Examples are RS256 and ES256K in both JOSE and COSE and ES256 in JOSE.
Reference this definition.
Merging the PR for now. Martijn will create issue(s) to fix it.
‘Device signed’ can be done with signature or mac. What is a ‘fully specified algorithm’ in the context of macing? 
Need to tweak definition to account for mac’ing. None of the hmacs in the COSE registry refer to that one. 
The reason we can use a single value to specify curve + algorithm. HMAC needs to values, or specify inline. 
Suggestion OpenId4VP define new IANA values. Can we do that in this spec? Then register it. 
Yes
 Don’t see why we need to define IANA algorithms. 
Decision to define them in OpenId4VP and use them. 
Also usable in VCI
https://github.com/openid/OpenID4VP/pull/513
State required when keybinding is absent, but not for DC API.
Keep nonce as required.
require_cryptographic_holder_binding as a better and more clear attribute name.
Should not reject for mdocs, need to make sure it is reflected elsewhere
Paul to do changes and be merged in today
https://github.com/openid/OpenID4VP/pull/485
Updating all of the references
What about VCI? Non-normative. 
What new ones are coming in? E,g, Fully-specified
Note: need to do another pass through
https://github.com/openid/OpenID4VP/pull/481
Todo to take a look.
Back to this: Only allows positive ints for matching.  
How to specify types? 
Can’t do everything. 
Can we just do the matching based on the credential you find at the end? 
Example: 
Identifiers
What lee is saying is correct
Provide the field -> base64 in mdoc.
Solution add language of follow the conversion from cbor to json. 
https://github.com/openid/OpenID4VP/pull/517
Adds support for multi-signing as different to signing
Approved -> merging
https://github.com/openid/OpenID4VP/pull/526
Should we stop referencing for anon-creds? 
We can always add it back later. We don’t have any real experience. 
No objection. Remove it last. 
Approved conditional on this. 
https://github.com/openid/OpenID4VP/pull/492
Rules for what can be returned. 
Some clarification to make it correct. 
Merged
https://github.com/openid/OpenID4VP/pull/482
What is needed? 
Should be good, resolving in working session today
Proposal to do a working session then move forward.
One of the implementers of federation of wallets, sentence that says ‘use of automatic registration is required’. Not true, we aren’t normally doing automatic registration flow. 
Approved, will be merged. 
Go through the state. 
Need a dedicated call to the privacy considerations, we want it to match the guidelines section. 
Some too strict (like wallet behaviors) oos
Maybe better in HAIP.
Issue: https://github.com/openid/OpenID4VP/issues/519
Talk with ISO next week? 
Any strong objections to removing it now? 
Need to redefine some things inline. 
Conclusion is to remove references to 18013-7, 
https://github.com/openid/OpenID4VP/issues/347 APU/APV issue
Problem: if you want to use them as an attached value. You need a way to indicate it.
Define `validate_apu_apv` boolean that defaults false so we can extend this in the future. 
https://github.com/openid/OpenID4VP/issues/510
This is a breaking change
Solution: parameters specific to a client_id should be in the header not the payload. 
Going to last call with two outstanding PRs. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250412/af9522bd/attachment-0001.htm>