[Openid-specs-digital-credentials-protocols] DCP WG + SIOP Call (APAC) 29th April Meeting Notes

[Tobias Looker]

Attendees

- Lee
- Joseph
- Martijn
- Christian
- Torsten
- Paul
- Daniel
- Mirko
- Brian
- Gareth
- Andres
- Peter
- Andrew
- Kristina
- Tobias

Announcements

- DCP event pre EIC, please register on eventbrite ahead of time (https://www.eventbrite.co.uk/e/oidf-dcp-wg-mtg-prior-to-eic-mon-05-may-2025-berlin-tickets-1317925955009) (https://www.eventbrite.co.uk/e/oidf-dcp-wg-mtg-post-eic-thurs-8th-may-2025-berlin-tickets-1318081771059).
- We've had feedback that the prefix for DCP mailing list is too long, so we will be changing it to `oidf-dcp` unless there is any objection.
- ISO 23220-3, we had a meeting with ISO where this specification had extended parts of VCI in a way that wasn't defined in VCI. The intent is to define what is required so that 23220-3 can point at VCI and HAIP with the required features in a similar way that ISO 18013-7 Annex D works. Significant discussion was had about this topic, refer to meeting recording for more details. In short no body appears to have concern about this proposed direction rather just logistics around how to best achieve the outcome.

Notes

Issue #473

- Dr Fett introduced the issue, outlining that there is multiple ways to solve this problem but this specific approach proposes to use OAuth for first party apps.
- Main questions from Joseph, 1) Do we build on the first party draft which won’t be an RFC anytime soon 2) What error codes do we need to define for things to be interoperable.
- Lee raised an alternative proposal where an OpenID4VP request can accompany the credential offer to indicate to the wallet this requirement rather than requesting a credential during issuance.
- Torsten: asked to clarify Lee's proposal is a summary that "if you are offering credential to be issued you accompany that with an OpenID4VP query?"
- Torsten: perhaps the main trade off with Lee's proposal is that it might support less dynamic situations like deciding what credential to request based on what has occurred in the issuance flow.
- Paul: now that we have a proposal for issuance over the DC API has been raised we should review that impact.
- Brian: agree with Paul here, we've gone to a lot of trouble to make presentation a nice user experience, I'm a bit worried we are potentially re-inventing presentation here. Why isn't a normal OpenID4VP (DC API flow) not the best way to solve this problem and remove all the coupling between VCI and VP.
- Tobias: I think we need to separate situations where we are trying to work around limitations around the web platform to say fetch an EID from situations where we might actually request a digital credential (e.g SD-JWT and mDoc).
- Discussion was had around whether logistically we could reference the first party draft and whether it is suitable considering many of the interactions between the wallet and issuer might not be first party in nature.

Issue 339

- Gareth introduced the issue and the basis of the proposal
- Discussion was had about exposing a JWKs that enables the wallet to encrypt the request with and the wallet can signal which key it used via the kid in the header of the JWE.
- Brian: unsure whether this feature is as simple as it seems and might be more difficult to specify in an interoperable way.
- Gareth: agreed with Brian that there are complexities that request encryption create
- Kristina: do you have an alternative proposal Brian?
- Brian: not specifically
- Joseph: could you provide some feedback in the issue around specific problems you think this proposal might encounter?
- Joseph: will also just point out that some believe that request encryption is a missing piece that makes response encryption more useful/powerful

Issue 300

- Joseph quickly introduced and asked that people please review with whether it is possible to add to v1.0, time ran out to progress the conversation further.

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/20250430/068c989a/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/20250430/068c989a/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/20250430/068c989a/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/20250430/068c989a/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/20250430/068c989a/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/20250430/068c989a/attachment-0009.png>