[Openid-dcp] DCP WG APAC call (23rd of September) notes

[Christian Bormann]

Hi all,

Below are the notes for today’s call.

Best Regards,
Christian

-------

--- Attendees:

Brian Campbell
Christian Bormann
Daniel Fett
David Zeuthen
Gail Hodges
George Fletcher
Hicham Lozi
Joseph Heenan
Juliana Cafik
Kristina Yasuda
Lee Campbell
Nate Hardt
Oliver Terbu
Paul Bastian
Peter Sorotokin
Rajvardhan Deshmukh
Steve Venema

--- Events/Updates:

- Gail explains that great results came out from NIST NCCoE. Some of their findings released in early September and helped identify some concerns with financial institutions and Juliana created a short overview of concerns (mainly eKYC, but perhaps also DCP WG related?). Juliana explains that usually institutions managed their own solutions and operational controls lacking in the area of mdl might cause problems. Juliana will provide a link to the work and asks for people to reach out for any questions. https://pages.nist.gov/nccoe-mdl-project-static-website/building_mdl_assurance/building_mdl_assurance.html

--- Issues/PRs:

HAIP PRs/Issues

Resolve issue with conflicting 'MUST' & 'SHOULD' for key attestations  - https://github.com/openid/OpenID4VC-HAIP/pull/282:

Joseph explains that while proof types are an extension point, the attestation proof type currently mandates the usage of the client attestation mechanism. You could still introduce a new proof type for other forms of key attestations, but the current text mandates the attestation proof type. Peter adds that you could always use the jwt-based attestation proof type, it is mainly about the additional step of conversion / contacting the wallet backend. Kristina clarifies that we need to update the text so that it is clearer that for other types of key attestations, new proof types have to be defined. Martijn asks about the jwt proof type and whether that is only applicable to the proof of possession and Joseph agrees. Martijn adds that the assumption that you can always sign things is not always accurate.

Add text explaining that some features rely on browser/OS support - https://github.com/openid/OpenID4VC-HAIP/pull/264:

Joseph explains that making the custom URI schemes optional solved part of the problems of this PR and thinks that it is mainly resolved. Kristina and Christian disagree and add that we should still mention DC API requiring support from the Browser / OS. Lee adds that similar concerns still hold true to custom URI schemes and it doesn't work with all platforms and browsers. Christian agrees that we should still have text mentioning both, custom URI schemes and DC API as the main wallet invocation methods depending on browser & OS level support.

Add some mention of certification/conformance tests - https://github.com/openid/OpenID4VC-HAIP/issues/271:

Agreed to add a small PR to mention the conformance tests.

Text x509 certificate profiles should be moved together & made consistent - https://github.com/openid/OpenID4VC-HAIP/issues/267:

Joseph explains that we use MAY and SHOULD when talking about X.509 profiles and we should align to only use one. "ecosystems are encouraged to define" could be understood as a normative SHOULD. Kristina proposes to reword to "encouraged to have policies.." (see PR for full proposal).

HAIP currently requires PAR, potentially preventing HAIP 1.1 requiring/allowing use of IAE - https://github.com/openid/OpenID4VC-HAIP/issues/283:

Paul suggests to mandate PAR only if authorization endpoint is used. That leaves room for IAE since it introduces a new endpoint.

clarify batch issuance requirements - https://github.com/openid/OpenID4VC-HAIP/pull/229:

Paul explains that his perception of HAIP was to also focus on the privacy features and single-use of batch issued credential would be such a feature. Paul proposes to define a policy claim in VCI that signals from the issuer that this credential is supposed to be single-use. Since VCI has gone Final, Paul proposes to introduce that in HAIP for the time being. Martijn responds that we should be very careful with this, that the reality of single-use is often more complicated and it is often not single-use but maybe limited use and for offline use it becomes even more complicated. Martijn continues that there are a lot of cases that trump the privacy requirement like showing your ID when entering a country. This might force wallets into behavior that might be bad for the user. Paul asks if a policy indicator would be better suited than tying it to the batch credential parameter and Martijn agrees that batch issuance should not automatically mean single-use. Paul advocates for adding a policy indicator rather soon and allowing those policies to evolve over time. Martijn responds that this behavior should be handled very carefully and not end up in situations where privacy trumps usability in all cases, which could happen with such a flag. Lee agrees that it shouldn't be defined in the spec and there are many credential presentations that are fully identifying where single-use doesn't gain you anything. Lee advocates to leave it to the wallet to decide. Paul replies that such a feature is likely being introduced by ETSI and it would be preferable to introduce it in the openid specs to preserve interoperability. Lee responds that a policy likely doesn't really cover all of the implications in real-use very well. Martijn responds that if the use-case really requires to do single-use for a good reason, then it might be fine to have such a flag, but he worried that this would do more harm than good. Martijn would like to better understand the requirements from ETSI. Brian warns just doing things just because some other entity thinks it is a good idea and might lead to more fragmentation.
Kristina asks to open a new issue on this to separate this discussion from the rest of the PR.

consider adding MTI crypto suites - https://github.com/openid/OpenID4VC-HAIP/pull/112:

Kristina asks about the discussion that happened last Thursday. Christian explains that from his perspective, the core mandatory to implement requirements should probably center around the wallet and asks why ISO ended up mandating support only for verifiers. Martijn explains that the spec requires support by verifiers, but the wallet is an implementation detail.

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