[Openid-dcp] APAC DCP WG Call 20th Wed Call Notes

[Tobias Looker]

# Attendees

- Kristina
- Martijn
- Hicham
- Ian
- Lee
- Brian
- Danieal
- Elizabeth
- Mike
- Peter
- Raj
- Rene

# Events & Announcements

- OpenID4VCI vote announcement has gone out, URL for this announcement is currently being fixed.
- IIW dates have changed back to the 21st of October, DCP WG calls still plan to coincide with this.

# Issues

## OpenID4VCI

- Martijn raised that issue 605 was merged with some agreed changes missing, either Gareth or Martijn will follow up with an additional PR to address.
- Kristina created a new issue to track the required changes.

## HAIP

- 7 open PR's, reviews welcomed
- All issues apart of the 1.0 milestone are now tagged as such

- Issue 109, what should we say about ISO mDocs for status management
*Lee* Why do we need to say anything?
*Kristina* For interoperability
*Lee* I think it should be out of scope of HAIP to concretely define this
*Martijn* I also don't see why we need any normative language around this for mDocs in HAIP, could we instead point via a non-normative note to rev 2 of ISO 18013-5
*Kristina* Im ok with that
*Lee* Likewise provided it is non-normative

- Issue 185
*Kristina* The suggestion with this is to allow both HTTPs and data URI's but limit the content type to certain image formats such as SVG and PNG
*Martijn* Just clarifying that the logo mechanism is not mandatory
*Kristina* Thats correct
*Lee* I think in the event this mechanism is used it makes sense to constrain the image formats supported.
*Lee* Should we do this in VCI instead of HAIP
*Kristina* Could be too restrictive, if we want MUST lets do it in HAIP
*Tobias* I'll review text in both HAIP and VCI in relation to this

- Issue 227
*Martijn* It feels a bit strange to me to mandate a feature pre-auth that may come with additional security considerations
*Paul* I feel somewhat similar
*Lee* Pre-auth appears to be a pre-dominant pattern that many usecases require so if pre-auth isn't suitable in its current form we need to adapt the mechanism
*Tobias* Lots of useful usecases are addressed with this I think we could constrain the usage to say using the DC API for transmission
*Kristina* Lets put it into v1.1 when a DC API based mechanism for pre-auth should be defined.

- Issue 104
*Kristina* Any issues with mandating this based on the findings from FAPI
*Brian* I don't believe there is much benefit in requiring it
**Lots of discussion, review recording**
*Kristina* I will document and we can discuss with Joseph when he is back
*Paul* Worth considering if we mandated this then we may not need PKCE

- Issue 98
*Tobias* With the current state of DC API this basically makes cross device flows impossible
*Gareth* Understand this complication but the security considerations are real for cross device flows I don't think we should allow cross device using ordinary OpenID4VP
*Paul* Agree with Gareth

- Issue 236
No objection to suggested change, Oliver is going to do a PR

- Issue 237
Briefly discussed, please review proposed changes in the issue

Thanks,
[MATTR website]<https://mattr.global/>

Tobias Looker
MATTR
+64 273 780 461
tobias.looker at mattr.global<mailto:first.last at mattr.global>
[MATTR website]<https://mattr.global/>
[MATTR on LinkedIn]<https://www.linkedin.com/company/mattrglobal>
[MATTR on Twitter]<https://twitter.com/mattrglobal>
[MATTR on Github]<https://github.com/mattrglobal>

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it – please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250821/471f7c97/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 22001 bytes
Desc: image001.png
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250821/471f7c97/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 872 bytes
Desc: image002.png
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250821/471f7c97/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 528 bytes
Desc: image003.png
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250821/471f7c97/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 921 bytes
Desc: image004.png
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250821/471f7c97/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 1045 bytes
Desc: image005.png
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250821/471f7c97/attachment-0009.png>