[Openid-dcp] EU call notes 16 Jul 2026

Christian Bormann chris.bormann at gmx.de
Thu Jul 16 18:38:33 UTC 2026


Hi all,

Below are the notes of today’s DCP call:

Best Regards,
Christian
-------

--- Attendees:

Bjorn Hjelm
Brent Zundel
Christian Bormann
David Zeuthen
Frederik Jacobsen
George Fletcher
Lee Campbell
Lukasz Jaromin
Martijn Haring
Michael Jones
Oliver Terbu
Paul Bastian
Rajvardhan Deshmukh
Ryan Galluzzo

--- Events/Other business:

- Next week is IETF 126, therefore there are no planned DCP calls
- DCP will be meeting on the Monday before GDC (before the DCHP meeting) - expected 10:30-14:30. More information will follow on the mailing list
- Ask if WG agrees to move with the conformance test towards certification phase --> no objection - conformance team con proceed to move to certification phase

--- Technical discussion:

OpenID4VP:

A few open PRs and we are almost done with 1.1

- Normative version inconsistency for SD-JWT VC in 1.0 final - https://github.com/openid/OpenID4VP/pull/726:

Oliver asked in the PR to update to SD-JWT VC -13 (or -17 which would be the most current version). Martijn asks what this decision means and what happens to implementations that currently use older versions. Oliver mentions that it would be better to update to the most current version. Christian mentions that he'd prefer to not keep an old version and maybe we want to make the reference informative.
Christian continues that ecosystems already define versions anyway. Lee responds that we cannot keep updating openid4vp all the time when formats get updated. Brent asks if we should make the references informative for 1.1.
Martijn asks what exactly that means and what a wallet would be allowed to return. Lee responds that it would be better to move credential format specific definitions elsewhere. Martijn states that OpenID4VP defines the identifier and Lee responds that it probably shouldn't be defined in this specification - which mainly happened for historical reasons. Lee proposes to make all references to credential formats non-normative and move this into a separate document. If we land this PR, we can only return what is referenced and Lee agrees with Martijn that this is a bit problematic.
Martijn asks what the reference of -13 vs -16 would have in terms of normative statements. Oliver agrees that ecosystems are already defining versions and that is why profiles exist that make choices and allow for interoperability. Oliver agrees that in principle the presentation protocol should be fully format agnostic and documents outside should define the necessary parts.
Lee states that maybe the typestring should be versioned and type metadata should probably communicate that versioning, but all of the format-specific parts should be outside of OpenID4VP. Brent asks if the WG agrees to make this informative? Martijn asks where it is going to ge specified how to request an SD-JWT and Oliver responds that we also cannot easily introduce versions into the types since that would break existing ecosystems. Paul proposes to push for the latest versions and update to RFC when finalized.
Martijn asks what exactly happens if we update to -16, could we then respond with -16 and -10 (since 10 is in 1.0)? Brent asks how to best proceed for this issue/PR and if we need to replace the PR with a different one. Paul responds that going forward, we should encourage formats to define these rules in their specifications, but we kinda need to keep mdoc and sd-jwt vc rules in openid4vp.
Martijn responds that 18013-7 was asked to not specify things before and that would be important to know. Paul responds that it is meant for future credential formats. Brent proposes to point to media types instead since they are registered, can reference the correct specs etc. Lee agrees that it sounds like a media or mime type problem. Martijn asks what exactly that means for 18013-7 and if it should only reference HAIP, or define something on its own.
Lee responds that in principle putting all of these format-specific parts into the protocol is not good and maybe we have to re-visit the discussion. Oliver repsonds that there are also protocol-specific parts like the binding to the protocol-specific values and for historical reasons it happened in OpenID4VP. Mike is asked if it is possible to create an IANA registry from OIDF and Mike responds that in principle only an RFC can register an IANA registry, but there are registries that were created for other organizations such as for webauthn. If we wanted to rely on registries, we could do the same thing.
Brent asks again what the summary of the current status is since there seems to be no clear consensus. Lee repsonds that maybe we have to accept the errors of the past and OpenID4VP defines those 2 normatively and we will fix that later. For that we just pick a version and if you return another version you would not be compliant.
Christian mentions that we cannot change the past and should update to the most current version.

Security considerations for client_metadata parameters - https://github.com/openid/OpenID4VP/pull/735:

Frederik introduces the PR that it looks like this is waiting for a response by Dima to the comments made in the PR.

Add additional text clarifying how to match vct and doctype - https://github.com/openid/OpenID4VP/pull/744:

Oliver explains that there is a slight mistake in the proposed text since metadata resolution in SD-JWT VC is an optional feature and "extends" is in metadata. For that reason, it is a bit odd to normatively depend on that feature since it could be understood as making it required.
Christian proposes to make it clear that vct type matching always goes first and then we slightly adjust the text that it is up to the verifier or ecosystem policies if they support the SD-JWT VC type matching with extends. Christian will propose changes to the PR.

Clarify an empty object in a VP Token cannot be used to signify an error response - https://github.com/openid/OpenID4VP/pull/745:

There is a new comment by Joseph about returning an error response without getting user consent which is already mentioned in other parts of the specification that should probably be referenced. Oliver will make changes to the PR to address Joseph's concerns. Brent asks for additional reviews of the PR. Paul agrees to review.

723 duplicate claims entry - https://github.com/openid/OpenID4VP/pull/750:

Christian introduces the PR and an ongoing discussion on if instead of adding more text to clarify the duplicate entries, it would be better to just remove the statement on duplicate claims. Brent asks the WG if we should continue adjusting the language in the PR to meet the correct statement on what duplicates means and how to deal with them, or if we remove the requirement altogether.
Frederik agrees with Martijn's comment from the PR that the requirement seems unnecessary. Oliver agrees with the proposal and Christian will modify the PR to remove the statement. Oliver asks what tat would mean for the expected Wallet behaviour and Christian states that from his perspective the duplicate claims cause no change in wallet behaviour, they just add additional payload.

Add text on untrusted input to 1.0 - https://github.com/openid/OpenID4VP/pull/759:

Brent explains that this just mirrors the changes that were already merged for 1.1 and asks for reviews to add it to the 1.0 errata.

Handling of origin in Native Mobile Platform App to App flows for DC API - https://github.com/openid/OpenID4VP/issues/646:

Lee will ask Helen to join the OIDF gh organization and she will create an example. Frederik responds that it is also about the properties, not only an example.

how to combine DCQL text language with ISO 18013-5 age_over_xx language - https://github.com/openid/OpenID4VP/issues/718:

The issue is about the age_over_NN matching logic introduced in ISO 18013 and it currently not matching with OpenID4VP DCQL logic.
Christian and Frederik introduce the issue that the main thing to figure out is if this should be seen as credential format or credential type specific feature. That will likely inform any follow-up decisions on a solution.


> On 15. Jul 2026, at 18:05, Brent Zundel via Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
> 
> Agenda for the 16 July 2026 DCP WG meeting:
> 
> Code of conduct / Antitrust policy / IPR policy: https://openid.net/wp-content/uploads/2025/06/OIDF_Groups-Activities-Events-Note-Well_Final_2025-06-12.pdf
> Note-taking
> Introductions
> Agenda bashing
> Events
> IETF meeting Vienna, July - no DCP WG calls next week
> Solar eclipse https://en.wikipedia.org/wiki/Solar_eclipse_of_August_12,_2026 in Europe.
> GDC Geneva in September - do register as there may be limited tickets: https://globaldigitalcollaboration.org/
> Standing topics for general updates
> Test requirements document for the EU 
> Conformance test updates - 
> ISO interop for VP
> Verifier
> Wallet
> DCP chairs: can you try to get to consensus on some of the certification issues please?
> https://github.com/openid/OpenID4VCI/issues?q=is%3Aissue%20state%3Aopen%20author%3Ajogu%20label%3Acertification
> https://github.com/openid/OpenID4VP/issues/718
> https://github.com/openid/OpenID4VC-HAIP/issues/364 
> https://github.com/openid/OpenID4VCI/issues/744  is probably the biggest one as we're seeing real interoperability issues from that..
> Presentation
> Review open PRs/issues: https://github.com/openid/OpenID4VP/pulls 
> Issues already tagged for 1.1: https://github.com/openid/OpenID4VP/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A%22Final%201.1%22 
> Is there anything else we should plan to address before we do WGLC for VP 1.1: https://github.com/openid/OpenID4VP/issues?q=is%3Aissue%20state%3Aopen%20no%3Amilestone 
> Issuance
> IAE / Building Interactive Authorization on top of first-party apps draft:https://github.com/openid/OpenID4VCI/pulls?q=is%3Apr+is%3Aopen+label%3Aiae  
> Server2server
> Call for adoption has started, will be done 29 July 2026
> Draft PR: https://github.com/openid/OpenID4VCI/pull/753 
> Review other open PRs: https://github.com/openid/OpenID4VCI/pulls 
> Issues https://github.com/openid/OpenID4VCI/issues 
> Triage UoStuttgart feedback & other issues on IAE: https://github.com/openid/OpenID4VCI/issues?q=is%3Aissue%20state%3Aopen%20label%3Aiae
> Priority issues for 1.1: https://github.com/openid/OpenID4VCI/issues?q=is%3Aissue%20state%3Aopen%20label%3Apriority
> 1.1 Issues: https://github.com/openid/OpenID4VCI/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A1.1 
> 1.1 or later, which is it? https://github.com/openid/OpenID4VCI/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A%221.1%20or%20later%22
> Issues to triage: https://github.com/openid/OpenID4VCI/issues?q=is%3Aissue%20state%3Aopen%20no%3Amilestone 
> timelines for 1.1: https://github.com/openid/OpenID4VCI/issues/687Display metadata: https://github.com/openid/OpenID4VCI/issues/421
> 
> --
> Brent Zundel
> Standards Architect | Yubico <http://www.yubico.com/>-- 
> Openid-specs-digital-credentials-protocols mailing list
> Openid-specs-digital-credentials-protocols at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols

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


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