<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><b>Attendees</b></div><div><div>- Joseph</div><div>- Bjorn</div><div>- David</div><div>- Gareth</div><div>- Lee</div><div>- Peter</div><div>- Timo</div><div>- Mirko</div><div>- Gail</div><div>- Brian</div><div>- Hicham</div><div>- Rajvardhan</div></div><div><br></div><div><b>Announcements</b></div><div><b style="font-style: italic;">* </b>The usual **Tuesday and Thursday calls are canceled**, replaced by hybrid meetings, one of which aligns with the Thursday call time.</div><div><div><b style="font-style: italic;">* </b>The **mailing list subject prefix will be shortened** from "openid-spec digital credentials protocols" to **"openid-DCP"**.</div><div><b style="font-style: italic;">* </b>Discussions are underway with **ISO WG4 (23220-3) to align work**, specifically exploring adding an **mdoc issuance profile to HAIP** so ISO can reference HAIP and VCI.</div></div><div><b><br></b></div><div><b>Issues</b></div><div><br></div><div>* **Issue #473 (Presentation during issuance):**</div><div> * Initially a priority for 1.0.</div><div> * Scope clarified to focus on **presentation *during* issuance**, specifically using **OpenID for VP (oid4vp)**, while allowing extension points for ecosystem specifics like EU ID cards.</div><div> * **Cross-wallet presentation was seen as highly complex and risky** due to issues with origin and transparency for the user.</div><div> * **Presenting from the same wallet was deemed "super valuable"**, particularly for use cases like payments requiring an MDL during issuance. This scenario supports a "one tap presentation" and has been successfully demoed.</div><div> * Despite improving user experience, this feature **does not block use cases** as a browser redirect fallback exists. This fallback can be difficult to implement correctly.</div><div> * Consensus leaned towards viewing this as a **"nice to have" for 1.0**, easily added in 1.1 as a non-breaking change.</div><div> * The functionality will be **defined within the oid4vci spec** itself.</div><div> * The 1.0 priority label was potentially dropped, and the issue was marked **ready for PR**.</div><div><br></div><div>* **Issue #145 (Dynamic Credential Request):**</div><div> * This existing spec section was described as **"terribly underspecified"**.</div><div> * The approach developed for Issue #473 effectively provides the necessary concrete specification.</div><div> * Agreement to **delete this section** from the spec for tidiness.</div><div> * Requires careful removal due to cross-references.</div><div> * Marked as **ready for PR**.</div><div><br></div><div>* **Issue #300 (Notification):**</div><div> * Discussion reiterated the decision to move this to **Version 1.1**.</div><div> * Reasons: It's a **non-breaking change** and there is **no implementation experience** yet.</div><div> * The essential polling mechanism via the Deferred Endpoint is already in the spec for 1.0. Push notifications are primarily a user experience improvement.</div><div> * **No adjustments are needed in 1.0** to enable this for 1.1.</div><div> * Shifted to 1.1, but remains a priority for that version.</div><div><br></div><div>* **Issue #410 (DC API support):**</div><div> * Currently tagged for **1.1**.</div><div> * Arguments against 1.0 inclusion: **non-breaking** and **insufficient implementation experience** (only one reported).</div><div> * Concern about rushing it into 1.0 without testing, potentially resulting in a suboptimal spec being finalized.</div><div> * It is being used to justify rushing work in another group (W3C).</div><div> * **Offline discussion** on potential unintended consequences is planned.</div><div> * Will be included in the **interop testing schedule for May** to gain experience.</div><div> * The PR will be finalized, with the decision on merging for 1.0 to be made later, potentially during public review if testing provides sufficient data.</div><div><br></div><div>* **Issue #480 (Batch issuance / Patch issuance / Dehydrated credentials):**</div><div> * Linked to discussions with ISO WG4 regarding the 23220-3 spec.</div><div> * The ISO structure bundles credentials for potential space savings.</div><div> * However, this structure **increases complexity** and may not offer significant benefit over simple compression.</div><div> * Implementation experience found a complex version **not particularly worthwhile**, and dehydrated credentials add processing overhead on devices.</div><div> * General preference for **reducing complexity**.</div><div> * **Plan A is to try and persuade ISO to modify their structure** for better alignment.</div> * **More feedback from implementers is required** before marking as ready for PR. A consensus towards avoiding the complexity seems reasonable.- <br><div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br></div><div>Cheers</div><div>Mirko Mollik <br><br>Identity Architect (EUDI-Wallet-Projekt) mirko.mollik@eudi.sprind.org<br><br>SPRIND GmbH <br><br>BUNDESAGENTUR FÜR SPRUNGINNOVATIONEN <br>FEDERAL AGENCY FOR DISRUPTIVE INNOVATION <br>Lagerhofstraße 4, 04103 Leipzig <br><br>www.sprind.org <br><br>Geschäftsführung: Berit Dannenberg, Rafael Laguna de la Vera <br>Vorsitzender des Aufsichtsrats: Dr.-Ing. E. h. Peter Leibinger <br>Amtsgericht Leipzig – HRB 36977 <br>USt-ID DE328253854 <br>Disclaimer</div></div>
</div>
<br></body></html>