[Openid-dcp] DCP WG APAC call (26th of August) notes

[Christian Bormann]

Hi all,

Below are the notes for today’s call.

Best Regards,
Christian

-------

--- Attendees:

Brian Campbell
Bjorn Hjelm
Christian Bormann
David Zeuthen
Gail Hodges
Gareth Oliver
Joseph Heenan
Kristina Yasuda
Lee Campbell
Martijn Haring
Oliver Terbu
Peter Sorotokin
Rajvardhan Deshmukh
Robert Gallagher
Tim Cappalli
Tobias Looker

--- Events/Updates:

- VCI vote announcement has been published

--- Issues/PRs:

OpenID4VCI:

#621 - align holder binding terminology to VP:
Kristina asks for reviews/approvals

#640 - Introduce Proven Key term:
Introduces new terminology - moved to 1.1.

#637 - Clarifications regarding mismatches in number of proofs, batch size, and number of issued credentials :
Kristina explains that it should already be clear that it is a decision at the discretion of the AS/Issuer and asks for reviews/checks if that is sufficiently clear in the spec.

#639 - Make language in split-architecture more specific:
Gareth explains that this is mainly a clarification / re-wording and asks for additional reviews/comments. Kristina asks Martijn if this matches his understanding. Some edits happen on the text, removing some aprts of the text and making sure to avoid normative keywords. Needs more reviews!

HAIP:

#165 - Changes to requirements of claims that contain time-related information:
Looks good to go with a few approvals

#228 - refactor OID4VC sections to include ISO mdocs:
No additional comments since this was last discussed on the call. Kristina asks for additional approvals/comments to move this forward.

#229 - clarify batch issuance requirements:
Kristina explains that the PR seems a bit stuck between the 2 options and asks for more comments/opinions to move things forward.

#112 - consider adding MTI crypto suites:
Kristina explains that the issue is about mandatory to implement crypto suites. Martijn raised the question what it means if a wallet supports a curve that is not in HAIP. Kristina asks for comments on the issue. Lee comments that this is mainly about the wallet and the issuer can pick the one it prefers, but from an RP point of view they need to support the correct curves of the issuer. Christian voices his concerns of enforcing the RP to support everything and Lee responds that the verifier can have previous knowledge of the issuer and only support they need to. Gareth responds that issuing with multiple curves would be the worst case. Martijn asks if we want HAIP to make more restricted choices and favor interoperability (and accept that there might be credentials not compliant to those choices), or add more options to that selection at the cost of increased implementation complexity.

David suggest to add a section to "support for signing", "support for verification", etc. Lee asks why a verifier should be mandated to support something it doesn't need if they know the issuers they are verifying credentials from and what signature scheme and curve they use. Joseph responds that if you already explicitly know the issuers you want to accept credentials from, then you might not need an interop profile. Lee responds that the wallet must support everything we offer, but issuers and verifiers have choices. The interop works by the wallet supporting HAIP and issuers and verifiers have choices. Kristina responds that if we want to have full interoperability, then the verifier should support all options. Christian proposes language. David asks what we want for HAIP compliance, Wallets will probably be required to be tested against a conformance suite supporting everything, but it is not entirely clear what we want for the issuers/verifiers. The core question is how complicated we want this to be. Gareth responds that the same argument limiting what the verifier needs to support would also apply to wallets if they are in a smaller ecosystem with stricter choices. Oliver responds that he is worried issuers would not be making cautious decisions on requiring HAIP which would then also mean requiring support for all the curves.

Joseph mentions the option of basically requiring ecosystem profiling. Kristina summarizes the options discussed. Lee responds that if you pre-agree everything, then you don't really need HAIP, so HAIP should define a set that the wallet must support and the issuer/verifier can pick. David voices that if we purely leave it to the ecosystem, then it will cause interop problems on a global scale. Kristina summarizes that it sounds like we want to mandate a few signature scheme / curve combinations, but ecosystems might also support additional algorithms. David responds that we need to choose if we want global interop for HAIP and mentions that the same discussion happened in the context of ISO 18013-5 which resulted in a list of mandatory to support algorithms. Tobias agrees with Lee's position that the wallet is kind of bound to have to support everything and issuers/verifiers might be able to make choices. Lee brings up the point of versioning of HAIP, and that we likely will have additionally supported algorithms like ML-DSA as an additional option in 1.1 or 1.2 of HAIP, and we would later on need to deprecate with something like HAIP 2.0. Martijn voices his concern that we probably need to be more careful for device signing algorithms. Gareth points out in the context of ISO 18013-5 compatibility, we could add Brainpool curves as an additional requirement if necessary.

Kristina summarises the different options discussed and comments on the issue: https://github.com/openid/OpenID4VC-HAIP/issues/112#issuecomment-3225561705.

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