[Openid-specs-digital-credentials-protocols] DCP WG + SIOP Call (EU) 1st Mai Meeting Notes

Mirko Mollik mirko.mollik at eudi.sprind.org
Thu May 1 16:28:29 UTC 2025


Attendees
- Joseph
- Bjorn
- David
- Gareth
- Lee
- Peter
- Timo
- Mirko
- Gail
- Brian
- Hicham
- Rajvardhan

Announcements
*   The usual **Tuesday and Thursday calls are canceled**, replaced by hybrid meetings, one of which aligns with the Thursday call time.
*   The **mailing list subject prefix will be shortened** from "openid-spec digital credentials protocols" to **"openid-DCP"**.
*   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.

Issues

*   **Issue #473 (Presentation during issuance):**
    *   Initially a priority for 1.0.
    *   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.
    *   **Cross-wallet presentation was seen as highly complex and risky** due to issues with origin and transparency for the user.
    *   **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.
    *   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.
    *   Consensus leaned towards viewing this as a **"nice to have" for 1.0**, easily added in 1.1 as a non-breaking change.
    *   The functionality will be **defined within the oid4vci spec** itself.
    *   The 1.0 priority label was potentially dropped, and the issue was marked **ready for PR**.

*   **Issue #145 (Dynamic Credential Request):**
    *   This existing spec section was described as **"terribly underspecified"**.
    *   The approach developed for Issue #473 effectively provides the necessary concrete specification.
    *   Agreement to **delete this section** from the spec for tidiness.
    *   Requires careful removal due to cross-references.
    *   Marked as **ready for PR**.

*   **Issue #300 (Notification):**
    *   Discussion reiterated the decision to move this to **Version 1.1**.
    *   Reasons: It's a **non-breaking change** and there is **no implementation experience** yet.
    *   The essential polling mechanism via the Deferred Endpoint is already in the spec for 1.0. Push notifications are primarily a user experience improvement.
    *   **No adjustments are needed in 1.0** to enable this for 1.1.
    *   Shifted to 1.1, but remains a priority for that version.

*   **Issue #410 (DC API support):**
    *   Currently tagged for **1.1**.
    *   Arguments against 1.0 inclusion: **non-breaking** and **insufficient implementation experience** (only one reported).
    *   Concern about rushing it into 1.0 without testing, potentially resulting in a suboptimal spec being finalized.
    *   It is being used to justify rushing work in another group (W3C).
    *   **Offline discussion** on potential unintended consequences is planned.
    *   Will be included in the **interop testing schedule for May** to gain experience.
    *   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.

*   **Issue #480 (Batch issuance / Patch issuance / Dehydrated credentials):**
    *   Linked to discussions with ISO WG4 regarding the 23220-3 spec.
    *   The ISO structure bundles credentials for potential space savings.
    *   However, this structure **increases complexity** and may not offer significant benefit over simple compression.
    *   Implementation experience found a complex version **not particularly worthwhile**, and dehydrated credentials add processing overhead on devices.
    *   General preference for **reducing complexity**.
    *   **Plan A is to try and persuade ISO to modify their structure** for better alignment.
    *   **More feedback from implementers is required** before marking as ready for PR. A consensus towards avoiding the complexity seems reasonable.- 

Cheers
Mirko Mollik 

Identity Architect (EUDI-Wallet-Projekt) mirko.mollik at eudi.sprind.org

SPRIND GmbH 

BUNDESAGENTUR FÜR SPRUNGINNOVATIONEN   
FEDERAL AGENCY FOR DISRUPTIVE INNOVATION  
Lagerhofstraße 4, 04103 Leipzig   

www.sprind.org    

Geschäftsführung: Berit Dannenberg, Rafael Laguna de la Vera  
Vorsitzender des Aufsichtsrats: Dr.-Ing. E. h. Peter Leibinger  
Amtsgericht Leipzig – HRB 36977  
USt-ID DE328253854 
Disclaimer

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


More information about the Openid-specs-digital-credentials-protocols mailing list