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

[Shannon Day]

Approved for all

On Tue, Aug 26, 2025, 4:50 PM Christian Bormann via
Openid-specs-digital-credentials-protocols <
openid-specs-digital-credentials-protocols at lists.openid.net> wrote:

> 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
> .
>
> --
> Openid-specs-digital-credentials-protocols mailing list
> Openid-specs-digital-credentials-protocols at lists.openid.net
>
> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250826/fda43fac/attachment-0001.htm>