[Openid-dcp] Preliminary Results: OpenID4VCI v16 Interop #3

[Gail Hodges]

DCP WG



We are pleased to share the preliminary results and report for the OpenID4VCI Interop #3, today July 16th, 2025 from 8-945am PT.



Preliminary Results

Of the 39 pairs tested today:

  *   67% (26 pairs) had a passing result!
  *   31% (12 pairs) had a Fail, but with a resolvable issue by the implementers
  *   3% (1 pair) had a Fail with an unknown issue



So far—strong results!



Below is a Preliminary Report of the pairwise configurations, participants, and some early insights prior to release of the final results Friday. The data will change as the teams conduct some triage and pairwise asynch tests. This may also surface issues not identified in today’s session.



Fantastic work yet again by:

  *   Our many expert implementing teams!
  *   By Thomas who led on the OpenID4VCI test suite development
  *   By Joseph, supporting Thomas behind the scenes and adding to some of the tests himself
  *   By Gareth, hosting the interop and coordinating with the teams in advance.
  *   And of course, the WG itself, whose v16 of the spec is looking good (so far!) as this spec move towards final



Any questions, please let me, Thomas, Joseph and Gareth know.



Gail



Preliminary Report



Participants included a robust group of implementers:

  *   7 issuers: Bundesdruckerei GmbH, Fikua, Multipaz/Open Wallet Foundation, Mattr, Meeco, the OIDF test suite, and one additional issuer without permission to use their name
  *   6 wallets: Bundesdruckerei GmbH, Multipaz/Open Wallet Foundation, Meeco, MyMahi, and the OIDF test suite
  *   1 demonstrator: Credman wallet (for DC API, future configuration)



The pairwise results are based on several configurations of the OpenID4VCI spec as shown below:

  *   5 pairs tested with OpenID4VCI v16 + SD-JWT + Custom URI Initiated+ HAIP mode where HAIP mode = "wallet attestation-based client authentication (with x5c header)”
  *   20 pairs tested with OpenID4VCI v16 + SD-JWT + Custom URI Initiated + client assertion with private_key_jwt
  *   7 pairs tested with OpenID4VCI v16+ SD JWT+ Custom URI initiated + No client attestation
  *   7 pairs tested with OpenID4VCI v16+ mdoc+ Custom URI initiated + No client attestation



Between now and 12pm PT Friday, we expect the teams to continue triaging

  *   12 pairs that failed with resolvable issues.
  *   16 net-new pairs, pairs that were not tested today, but which should be possible for the teams to test offline with light effort (e.g. exchange of configuration information, or testing in timezones not friendly to some teams today)
  *   @Gareth Narinesingh<https://oidf.slack.com/team/U07NKSVNY7R> will email the interop team leads to gather as many updated/new results as possible

By end of day Friday, Gail will circulate the final results to the DCP WG.



Based on these highly preliminary findings:

  *   No material, new issues with the OpenID4VCI v16 spec flagged; nothing obvious that would merit escalation as part of the public review of v16 now underway.
  *   No material issues with the OpenID4VCI tests raised. Tests “as is” are already adding value for implementers. Enhancements to tests are of interest and could further support implementers (mdoc credential type added to the test suite, proving out the DC API initiation test option, adding tests for optional features)



Initial observations from the group :

  *   The broad range of configuration options within the OpenID4VCI spec underscores the importance of profiling of the spec.
     *   This is a challenge which HAIP seeks to address by default.
     *   Some of the implementers had not enabled HAIP yet.
  *   Although the pairs with results recorded all had Custom URI initiation, the interop participants discussed the potential for DC API to initiative the transaction, which could come in OpenID4VCI V1.1 of the specification.
     *   The Credman team briefly demonstrated their implementation using the DC API to initiate the transaction
     *   The OIDF certification team confirmed that the test suite now allows for DC API initiated transactions. We hope to have the first implementers passing those tests shortly.
  *   There did not seem to be a material need for a 4th interop for the purpose of proving out the specs, or the OID4VCI test suite.
     *   That said, ad hoc implementer pairwise tests or a future interop may be desirable to bring additional implementers along, refine new tests in the test suite etc.



Requests for the DCP WG/ Cochairs, after release of the final results :

  1.  Acknowledge OpenID4VCI v16 final interop results
  2.  Share final results with ISO WG10, WG4 to inform their spec development
  3.  WG triage of issues/PRs raised
  4.  WG feedback on test requirements for handling optional UX requirements in the specifications
        *   these optional requirements could be ignored in the tests (as they are now since they are not required)
        *   we can add tests to check for optional features, but if we do, we need WG guidance on how to handle optional tests that do not pass (e.g. flag an optional test that does not pass, but overall implementation passes? Or a failure on an optional test is a failure overall?) There are some governance decisions to consider in this, e.g. UX failures the spec sought to address.

5. Suggestion for the DCP WG to maintain a reference sheet for ad hoc pairwise testing with restricted access.

  *   lists of implementers, their configurations (issuer, verifier, wallet, etc), credential types, security configurations etc.
  *   list of their certificates, endpoints, registration requirements
  *   contact information (part of reason restricted access is suitable)
  *   If this turns into a more complex exercise, DCP Cochairs and OIDF staff may want to explore alternatives to maintain this permissioned repository

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