[Openid-dcp] DCP WG call notes - APAC (2026-07-29)

Wed Jul 29 10:04:36 UTC 2026

Hi all,

Below are the notes of today’s (2026-07-29) DCP call:

Best Regards,
Christian

-------

--- Attendees:

Ashmita Chakraborty
Christian Bormann
Dima Postnikov
Frederik Krogsdal Jacobsen
Lukasz Jaromin
Martijn Haring

--- Events/Other business:

- IETF 126 in Vienna updates
  - Deferred token response might have nice synergies with OpenID4VCI (allowing to distinguish between the authorization and credential issuance parts of deferred issuance)
  - Delegated SD-JWT might be relevant for OpenID4VCI related discussions as well, especially for things like revocation of the delegated credentials
- GDC Geneva: meeting before the DCHP meeting 10:00-14:30 on Monday

--- OpenID4VP:

Dima asks if OpenID4VP should proceed to final or ID. Christian responds that we don't have that many technical changes for it and moving to final 1.1 is the right choice. Noone disagrees.

Add security guidance for platform-specific Origins and DC API - https://github.com/openid/OpenID4VP/pull/761:

Needs comments and Frederik asks Martijn for a review. Martijn responds that there isn't really a spec that defines how to do that so it is hard to review. Frederik comments that this is mainly about the assumptions OpenID4VP has on such a feature.
Martijn comments that the feature is largely undefined and there seem to be a lot of assumptions for this, but it is platform-specific and rather hard to review this. Martijn makes it clear that his review of this means that he doesn't see anything strange in this PR, but not that the general feature works as described.
Christian responds that this is about documenting our assumptions on such a feature from the perspective of OpenID4VP. Dima responds that the formulation has sort of normative statements on the platform implementation. Martijn states that stating platform requirements in openid4vp seem to be a weird thing. Frederik responds that the musts are intentionally non-normative (lower-case) musts. A proposal is made to change that from a lower-case must to clear statements on what the platform does. Frederik states that this is mainly a clarification on our requirements from an OpenID4VP perspective.
Martijn states that the statement on transport of the Origin value is a bit weird. Both entities must be able to generate/retrieve the origin and result in the same value to be able to compare in the actual request. Christian responds that is has to be a deterministic way to calculate or retrieve the origin value for both sides (RP and Wallet/Platform).
Martijn agrees to review the PR. Lukasz asks about the interpretation of the last line in the PR (requirement on transport the origin unmodified) - he asks if that includes integrity protecting that value, making sure noone modifies it. Martijn responds that we should also be careful because of cross-device situations and points towards a discussion in DC API to add a hint that it was communicated cross-device. Unmodified might be tricky in that case.
Martijn comments that usually it shouldn't be the App that generates its own origin, but something else like the platform that generates it and the app somehow retrieves it.
Frederik asks for people to suggest text changes accordingly.

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

Martijn asks if an invalid value would mean that you abort parsing the request. Christian responds that from his understanding we are currently not normatively stating that the whole request must be dropped/aborted, but that is probably the sane thing to do in an implementation (instead of trying to figure out if it is safe to drop a specific value). Frederik comments that this should probably also be tested in the conformance suite (not proceeding on invalid input). Lukasz asks if the language shouldn't be "SHOULD at least implement the following steps" instead of "SHOULD implement the following steps”. Frederik responds that a Wallet can always choose to implement more checks, a "SHOULD implement these steps" does not stop anyone from doing more.

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

Waiting for Joseph to clear his request for changes.

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

Christian explains that we probably want to restructure the section on Privacy considerations slightly since some of the general considerations are in a subsection on DC API. Martijn states that he in general would be very careful with errors and make sure they don't leak any PII. Martijn points out that this PR has pretty strong language on error codes and cautions to be careful with that. Frederik agrees with the general premise of being careful with error codes. Christian points out that we have a general purpose error for access_denied that encompasses all credential based cases (credential doesn't exist, user denied, etc.). Dima comments that this seems to be waiting on Oliver to update.

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

Christian introduces the comment of Gareth to extend SD-JWT VC to make the extend mechanism explicit. This depends on a decision for SD-JWT VC and would make the matching only require data contained in the credential instead of fetching metadata.

'selectively disclosable claims' is not defined - https://github.com/openid/OpenID4VP/issues/717:

Martijn asks for clarification on the term of "selectively disclosable". mDoc allows to return things like attributes (first name, last name) as purely device signed item (no issuer signature) and terminology is a bit unclear right now what exactly that means - we might need a clarification on terminology. Dima agrees to bring the topic up in the atlantic call.

 --- OpenID4VCI

Question on Server 2 Server draft call for adoption by the WG. No-one disagrees with proceeding with the adoption and the topic will proceed in the Atlantic call.

> On 29. Jul 2026, at 07:42, Dima Postnikov via Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
> 
> Proposed agenda for today's call:
> 
> 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 <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
> Standing topics for general updates
> Test requirements document for the EU 
> Conformance test updates
> Presentation
> Are we ready for final 1.1?
> Review open PRs https://github.com/openid/OpenID4VP/pulls 
> Review open issues https://github.com/openid/OpenID4VP/issues 
> Issuance
> Server2server
> Call for adoption - to be completed this week.
> IAE / Building Interactive Authorisation on top of first-party apps draft.
> Review other open PRs: https://github.com/openid/OpenID4VCI/pulls 
> Review open Issues https://github.com/openid/OpenID4VCI/issues 
> 
>         9. AOB
> 
> -- 
> 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/20260729/81e3a5ac/attachment-0001.htm>