[Openid-dcp] Americas call Notes 23 Jun 2026

[Brent Zundel]

DCP WG Americas Call (the call formerly known as Small Group Server to
Server Issuance)

23 June 2026

Notes:

Looking at PR 753: https://github.com/openid/OpenID4VCI/pull/753

It is a starting point, not a complete document at this point.

Goal is to get agreement on top level flows, etc., then continue to iterate
on individual endpoints.

This document defines interaction between Issuer Server and Wallet Server

Has different privacy properties that other flows.

expects a wallet server that isn’t a dumb pipe

Uses mTLS between the servers

We walked through the main flow between the IS and WS

Looked at lifecycle management endpoints

There is also a credential metadata endpoint

Do we still have wallet attestations in this flow?

mTLS connection with the server may be sufficient

Could be provided in initiation as well

Having a mechanism to let it come from the wallet through the server would
still be useful.

If the wallet server does something wrong and the issuer trusts the wallet
server, who is responsible there?

This adds some complexity to the overall system. Additional trust surfaces
need to be explored

Similar to current VCI, it provides some mechanisms for doing attestations,
we should make sure you can provide attestations about any key that you
have. We should be careful to not prescribe specific models for attestation.

Related Issues so far are tracking missing features.

Question is: is this in a good enough state that it can be adopted as a
first draft?

Please point out any glaring errors.

It would be good to have a deadline set by which review is expected.

Suggestion of two weeks was agreed to.

Related issues are labeled ‘server-to-server’, please check them out as
well.

Additional topic:

What is the latest around credential sets and canonical VCI?

Right now you have a top-level configuration that also defines a dataset
category, out of that you get dataset instances, there are also multiple
copies of cryptographic objects. You return a batch of those objects from
an individual call. There’s no way to link credential sets together, and no
way to see if the same data set is in different formats.

One way to solve this is to provide linking information separately, so the
wallet can properly display the multiple versions to the user.

There may be additional sets of linked datasets, but those aren’t currently
being considered. They may be more complicated, and may have different
issuance requirements.

Different sets of data within one proofing session

There needs to be a way to say these are part of the same dataset. They may
be updated or exhausted seperately.

What if you have a specific ZKP format, for example? Even if they have the
same data, they may not be the same. Some fields may be different. Maybe
this should be a hint that things are similar, rather than an expectation
that these things are actually identical.

There seems to be agreement on that point.


The proposal is the one that has provisioning and get as separate
endpoints? How strong do we feel about those being separate?

Right now they take different identifiers and return different things.
Ontological differences exist.

Not sure what the advantages are of combining them. Simple single calls is
one design goal.

Why wouldn’t it be simpler to say you can’t have a set in the provision
call?

For one verification session, there may be multiple identifiers for
multiple datasets.

There may be other ways to use the endpoints that could be explored.


-- 

Brent Zundel
Standards Architect | Yubico <http://www.yubico.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20260623/9a78255d/attachment.htm>