[Openid-dcp] Notes for 2026-06-30 meeting (Server 2 Server)

[Christian Bormann]

Hi all,

Below are the meeting minutes from today’s (30.06.2026) DCP call:

----------

--- Attendees:

Ali Almoharif
Brent Zundel
Christian Bormann
David Zeuthen
Gareth Oliver
George Fletcher
Martijn Haring
Peter Sorotokin
Rajvardhan Deshmukh
Vaibhav

--- S2S discussion:

Gareth introduces the general state of the PR (first proposal of S2S as a separate document in the VCI repository).

First discussion point is terminology and Gareth showing some of the comments, for example "Verification" being a very generic name. Christian comments that he likes enrolment for that process being described. Gareth asks for feedback from the group so we don't keep changing terminology all the time while working on the draft - it would preferable to get this figured out early on.

There is some discussion about terminology of the entities involved and Christian notices that Wallet Client as currently used might cause confusion since that would be understood differently in the more traditional openid4vc context. Brent comments that credential manager seems to be more used right now for that and Gareth responds that Wallet would be called credential manager, but we are sort of splitting it up into two pieces. David comments that maybe the Wallet Server should be called Wallet backend instead.
Martijn proposes to only define the Wallet Client as informative concept, where from an API point of view you are mainly interacting with the Wallet Backend/Server, but the interaction of the Wallet Client is out of scope. This would mean only having security and privacy guidance around the Wallet instance, but normatively describing it. Gareth responds that we have to make normative statements about the wallet signing key, but that is about it.
Martijn continues that we don't want to overdefine/overstate what exactly the Wallet Client ist and once we are talking about more specific types, then we can make stronger/more precise statements. Christian repsonds that we should be clear on our mental model of what that entity is and what capabilities or properties it has, but we can be less strict on normative requirements in the beginning.

Gareth explains the comments in the PR on different endpoints that could be merged into a single endpoint / re-use IAE from vanilla OpenID4VCI. This would cause it to become a polymorphic endpoint, making a bit less clear what the JSON schema being allowed is since it would be state dependant. Gareth explains that the comparison to IAE doesn't seem to fully fit since we don't really have the option of several endpoints there. Gareth asks on opinions of one vs several endpoints. Christian responds that if it allows us to harmonize with vanilla OpenID4VCI, then it would absolutely be worth it to change the architecture. Martijn states that for the verification endpoint, he'd expect significant changes to "normal" IAE interactions, so it might make more sense to diverge here.
Christian states that the overall functionality of IAE should fit and the Client needs to hold state anyway, so re-using one endpoint shouldn't be too problematic.
George comments that FirstParty App draft does not say anything about the schema and messages that are being exchanged, so there shouldn't be too many restrictions on what we do with it in the scope of IAE. Gareth responds that the part is the VCI schemas on top of first party draft and we require some other things in s2s that you don't really need of the vanilla VCI flow. At the end you also don't really need a code, just a state transition. Gareth proposes another way to look at it where we have some wrapper around it that makes it easier to harmonize the interaction part of it.
Martijn responds that it would be very helpful to have 2 examples later on (1 harmonized, 1 not harmonized) to make the comparison more tangible / a more exact comparison - direct A B comparisons of flows.

Christian asks how long we want to review this PR before we merge it since a lot of the current discussion would probably be better in detailed issues/PRs. Gareth explains that the idea is to have roughly 2 weeks for this PR and people sohuld provide feedback during that time. After that we can iterate on the document with normal issues/PRs. Martijn also asks people in comments for the PR to flag comments that should be addressed before merging as such. Christian mentions that non-blocking comments might be better in an issue then, so they don't get lost after the PR is merged.

Christian comments that we should probably create a bit more content for the overview section to make it easier for people to understand the general mental model. Gareth agrees and asks for feedback on the PR to help improve the introduction and also proposes to create a slide-deck to explain the core ideas behind S2S.

Martijn provides feedback that negotiation is pretty hard to figure out and it might be better to start with out-of-band negotiation and slowly move to more standardized ways. Gareth responds that there are a couple of key mechansism that would be very good fallback mechanisms like redirect-to-web that we've already seen in the IAE discussion. For more specialized ones, we likely need some kind of relationship between the wallet and the issuer anyway. Martijn agrees that anything we can easily specify, we should specify and we shouldn't spend too much time on the more complex variants. There will be a lot of cases where doing it right will take a lot of time and we should not spend too much time on designing those before we have a first version of the protocol out.

Brent reminds people to get reviews in on the PR.