[Openid-dcp] DCP WG EU 2025-09-18 Meeting Notes

Fri Sep 19 07:30:20 UTC 2025

Please find below the notes from our September 18, 2025 meeting.

Meeting Information
- Date: September 18, 2025
- Time: 8:02 AM PDT
- Working Group: Digital Credential Provider (DCP) Working Group
- Chair: Joseph Heenan
- Note Taker: Jin Wen

Attendees
- Klaus Roehrle (Sony)
- Lukasz Jaromin (Raidiam)
- Michael Jones
- Patrick Amrein
- Peter Sorotokin
- Rajvardhan Deshmukh (Cisco)
- Ryan Galluzzo (NIST)
- Christian Bormann
- Steve Venema
- Jin Wen
- Joseph Heenan (Chair)
- Hicham Lozi
- Brian Campbell
- David Waite
- Daniel Fett
- Andy Lim
- Bjorn Hjelm

Administrative Items
- Reviewed OpenID Foundation Code of Conduct, Antitrust Policy, and IPR policy
- Reference document: https://openid.net/wp-content/uploads/2025/06/OIDF_Groups-Activities-Events-Note-Well_Final_2025-06-12.pdf

Key Announcements

Major Milestone Achievement
- VCI (Verifiable Credential Issuance) specification 1.0 final has been approved and published. This represents major progress, with announcements distributed and multiple LinkedIn posts celebrating the achievement. The specification is now ready for reference in the next round of EC (European Commission) Implementing Acts for digital wallets.

Upcoming Events
- Pre-IIW DCP Working Group hybrid meeting: https://dcpwg-iiw-20oct25.eventbrite.co.uk/
- OIDF workshop: https://oidf_workshop_iiw_fall2025.eventbrite.co.uk/
- Location: Both events will be held at Cisco with limited spaces
- OIDF member discount: 20% discount codes for IIW were distributed by Stephanie last week

Technical Discussion - HAIP Pull Requests

PR #252: Prohibit Self-Signed Certificates for x509_hash
Link: https://github.com/openid/OpenID4VC-HAIP/pull/252
- Joseph Heenan reported on discussions with Stefan from New Zealand regarding their planned use of self-signed certificates due to the absence of a central registry. After extensive discussion on the morning APAC call (including input from Tobias), Stefan approved the changes after recognizing alternative solutions that don't require self-signed certificates.
- Steve Venema noted that Oliver addressed his comment regarding x5c header consistency across the specification, allowing him to approve the PR.
- Status: Seven approvals received, open for three weeks, all comments addressed.
Decision: Approved for merge.

PR #266: Separate Schemes for VP/VCI, Make Custom URI Support Ecosystem Decision
Link: https://github.com/openid/OpenID4VC-HAIP/pull/266
- Joseph Heenan explained the rationale for this significant change:
  - Separate HAIP-VCI and HAIP-VP schemes introduced instead of single scheme
  - Custom scheme support changed from mandatory ("MUST") to optional ("MAY")
  - Rationale: EU law will reference this specification with third-party test houses testing for compliance. Mandatory features that might not work reliably would be problematic
  - Addition of explicit HTTPS claimed HTTPS URIs support as alternative invocation method
- Technical Details:
  - Different security properties between custom schemes and HTTPS URIs
  - IANA considerations section needs updating (action item for Joseph)
  - Charles suggested this resolves additional issues
- Status: Open for two days but topic discussed extensively.
Decision: Consensus to merge pending IANA section fix.

PR #231: What Does High Assurance Mean?
Link: https://github.com/openid/OpenID4VC-HAIP/pull/231
- Joseph Heenan reported that Torsten updated the PR following Adrienne's comments, clarifying scope limitations and defining high assurance objectives:
  - High assurance defined as: Claims are authentic and holder has been authenticated
  - Explicitly states what is out of scope (exact authentication methods)
  - Non-normative but important for context setting
- Steve Venema volunteered to review and approve.

PR #229: Clarify Batch Issuance Requirements
Link: https://github.com/openid/OpenID4VC-HAIP/pull/229
- Discussion of language clarification around credentials and datasets. Oliver and Paul made suggestions that Kristina hasn't yet applied.
- Proposed language: "If batch issuance is supported, the wallet should use it rather than making consecutive requests for a single credential of the same credential dataset. The issuer must indicate whether batch issuance is supported by including or omitting the batch credential issuance metadata parameter. The issuer's decision may be influenced by various factors including but not limited to trust framework requirements, regulatory constraints, applicable laws or internal policies."
Decision: Consensus achieved. Action: Joseph to request Kristina apply the suggested changes.

PR #214: Require Use of (Most of) FAPI2 with VCI
Link: https://github.com/openid/OpenID4VC-HAIP/pull/214
- Joseph Heenan presented this significant proposal requiring FAPI2 compliance for VCI implementations:
  - Use FAPI2 as recommended method to comply with OAuth Security BCP
  - Constrain to DPoP as sender constraining mechanism (mTLS difficult for wallets)
  - Carve-out for client authentication (use wallet attestations instead)
  - Remove redundant PAR requirements (already covered by FAPI2)
- Discussion Points:
  - Daniel Fett supported referencing FAPI2 rather than copying text to avoid complications.
  - Christian Bormann requested clarification notes for sections not applicable to VCI.
  - Brian Campbell raised concerns about mTLS guidance, strongly disagreeing with "throwing mTLS on everything" and requesting careful exclusions.
  - Joseph Heenan acknowledged the need for notes excluding:
    - OpenID Connect sections
    - mTLS deployment guidance
    - Potential exception needed for JWT signing algorithms (ES256, RS256, EDDSA requirements)
- Benefits Identified:
  - Reuse existing FAPI2 conformance tests
  - Ensure security compliance
  - Prevent insecure implementations in production
Decision: Consensus to reference FAPI2 with appropriate exclusion notes.

Open Issues Discussion

Issue #211: Allow Use of Other Wallet Attestation Formats
Link: https://github.com/openid/OpenID4VC-HAIP/issues/211
- Joseph Heenan noted ongoing discussion without clear resolution. The debate centers on:
  - Current approach: VCI wallet attestations provide interoperability
  - Concern: Lower privacy and additional implementation burden
  - Alternative: Support for hardware-specific attestations
Status: Pending further discussion between Martin, Torsten, and others.

Issue #112: Consider Adding MTI (Mandatory to Implement) Crypto Suites
Link: https://github.com/openid/OpenID4VC-HAIP/issues/112
- Critical Discussion on Cryptographic Requirements:
  - Ryan Galluzzo (NIST) provided crucial US regulatory context:
    > "I don't think we want to write anything that excludes existing mDL/mDOC deployments writ large. One thing to note, at least in the US, they need to use NIST approved algorithms per the TSA Real ID waiver program. So, at least in the US, a smaller set is somewhat specified. This should be framed around the algorithms regardless of the credential type. This should be achievable if framing as a recommendation rather than a hard requirement."
- Key Technical Challenges Identified:
  - ISO 18013-5 Permissiveness: Current standard allows wide range of algorithms
  - Live Deployment Reality: Multiple jurisdictions (US states, Japan, others) have active mDL deployments
  - Unknown Algorithm Usage: Limited visibility into actual cryptographic algorithms in production
  - Conformance Testing: ISO 18013-5 conformance requires implementing all algorithms including Brainpool
- Christian Bormann proposed mandatory-to-implement approach focusing on wallet compatibility:
  - Wallets need MTI algorithms for generic credential acceptance
  - Verifiers may have more specific requirements
  - Recommendation: 1-2 MTI algorithms for interoperability
- David Waite clarified standards landscape:
  - No standardized way to use Brainpool with JOSE stack
  - Different regulatory requirements across jurisdictions
- Hicham Lozi questioned algorithm restrictions by credential format, suggesting consistency across mDoc and SD-JWT.
- Two Options Identified:
  1) Restrictive approach: Exclude existing deployments that don't comply
  2) Permissive approach: Allow ISO 18013-5 defined algorithms with recommendations
Decision: Issue requires further analysis. Action: Joseph to draft proposal incorporating discussion points.

Action Items
1) Joseph Heenan
   - Fix IANA considerations section in PR #266 and merge
   - Add exclusion notes to FAPI2 PR for OpenID Connect and mTLS sections
   - Contact Kristina to apply batch issuance language changes
   - Draft crypto suites proposal incorporating meeting discussion
2) Steve Venema
   - Review and approve PR #231 (What does high assurance mean?)
3) Christian Bormann
   - Create PR for signing request rationale (editorial)
4) Oliver
   - Arrange ISO small group meeting for intent to retain discussion (scheduled next week)
5) All Members
   - Continue reviewing open pull requests
   - Provide input on Issue #112 (crypto suites) and Issue #211 (wallet attestations)
   - Register for pre-IIW meeting and OIDF workshop

Resources
- HAIP GitHub Repository: https://github.com/openid/OpenID4VC-HAIP/
- Pull Requests: https://github.com/openid/OpenID4VC-HAIP/pulls
- Open Issues for 1.0: https://github.com/openid/OpenID4VC-HAIP/issues?q=is%3Aissue+state%3Aopen+-label%3Aafter-wglc+-label%3Ahas-PR+-label%3Aready-for-PR+milestone%3A%221.0+Final%22

Next Meeting
- Next regular DCP Working Group meeting scheduled according to standard cadence. Many attendees expected to participate in Tuesday Americas call.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250919/46849313/attachment-0001.htm>