[Openid-specs-digital-credentials-protocols] Minutes from 7th April 2025 DCP WG meeting

Tue Apr 8 19:52:33 UTC 2025

Thanks to Matt / Tim / Mick for taking minutes!

Pre-IIW Spring 2025 DCP WG minutes

Note Takers: Matthew Miller <mailto:mattmil3 at cisco.com> + Tim Capalli + Mick Hansen
Attendees
Joseph Heenan
Kristina Yasuda
Steve
Naohiro
Christian
Paul
Mirko
Gareth
Oliver
Tim
Gail
Aaron
Mike Jones
Matthew Miller
Dirk
Frederik Krogsdal Jacobsen
Mitchell at WebBadge
Martijn
Bjorn
Helen
Brian Campbell
Daniel Fett
Dima
Nat Sakimura
Oriol Canadés
Rajvardhan Deshmukh
Stefen Charsley
Timo Glastra
Mick Hansen
Lee
Nancy
David Chadwick
Torsten
Kasper
Minutes
Talking about IIW topics
https://docs.google.com/document/d/1yTWnl-vHnKN5Q9rEPpPwFq6Ur-sfJL9qExCH2lhgnxA/edit?tab=t.0#heading=h.y7oexn4u84en
Q: Status on VCs w/o keybinding?
A: PR is in-progress, it’s a big one. Everything in the spec assumes proper keybinding
Approximate ETA is before second DCP meeting, pushing for something to review during IIW
Discussing PRs labeled “editors” (GitHub <https://github.com/openid/OpenID4VP/pulls?q=is%3Aopen+is%3Apr+label%3Aeditors>)
Editorial improvements regarding DC API (#465) <https://github.com/openid/OpenID4VP/pull/465>
Changing JARM references to JWT directly (#477) <https://github.com/openid/OpenID4VP/pull/477>
Make doctype_value and vct_values mandatory  (#480) <https://github.com/openid/OpenID4VP/pull/480>
Trying to confirm consensus
Discussing required properties
Specify value-matching for ISO mdoc-based credentials (#481) <https://github.com/openid/OpenID4VP/pull/481>
Needs updating
add attachment parameter to authz req (#482) <https://github.com/openid/OpenID4VP/pull/482>
Can resolve comments without additional WG time
Clarify key selection for client_metadata jwks (#483) <https://github.com/openid/OpenID4VP/pull/483>
PR to remove JARM dropped a parameter that helps clarify which key to use when multiple keys are specified
Text reads like key selection for presentation. Text should not be modified to not give wrong advice for the wrong use case
This was causing interoperability problems between wallets
There’s likely an existing section in the PR that can be enhanced to help clarify key selection
If the verifier provides more than one JWK in the first place, then it becomes trial and error to find the right encryption key?
Guidance can be for verifiers to only specify one key
JWKS supports multiple keys, not all of which are for encryption. Though encryption is the only defined reason for including a key
This is context not obvious to those outside of the WG
So long as key IDs are not duplicated then there’s a way to specify the key by its ID to help verifiers find the right key
KID may not be there, so we need to clarify behavior when KID is not there. Need to clarify that when another mechanism is used that implementers are on their own
note on pre-final specs (#485) <https://github.com/openid/OpenID4VP/pull/485>
Some discussion around specifying a versioned link instead of “latest”
If there’s a mention of a specific version there’s a need to link to that version
Clarifying intention of note is to communicate, “try implementing latest, if there’s issues then implement Draft 18 instead”
Question on which version of DC API to link to
Depends on when a link is needed by
Link to GitHub.io version for now, by mid-May there should be stable version
What does not having a stable reference mean for us here? Remove section?
Discussion around importance of specific format identifiers between versions of specs
Possibility of generalizing specs to say, “if you get a named version use that,” with future errata to link to specific, updated format versions
OID4VP shouldn’t limit specific format versions
Recommend use of currently published/stable versions, unless no published version then use “latest”?
DC API wants there to be a top-level version, potential for more open-ended versioning schemes can create problems in DC API
Specific versions need to be defined in OID4VP final
Need to remove “drafts” from current guidance
Clarify iss value in Request Object (JAR) (#499) <https://github.com/openid/OpenID4VP/pull/499>
Just waiting for time to elapse
Call for objections to merge all open PRs on Friday with consensus
No objections
Noted that PRs should have approval by then
Discussing issues labeled “discuss” on GitHub (GitHub <https://github.com/openid/OpenID4VP/issues?q=label%3Adiscuss%20state%3Aopen>)
(Question and For the record) Why is Client Identifier Prefix using colon ":" as a delimiter? (#505) <https://github.com/openid/OpenID4VP/issues/505>
Do we introduce this breaking change now?
Breaking change may not be worth it, but if we do change it then can we use a more URL-safe value? Stay with colon?
May cause issues with naively parsing URIs because of colon in e.g. http(s)://, but we can be specific about parsing rules
Processing rule: split by colon, then match first segment by recognized prefixes?
Seeking volunteers to write this PR by EOD tomorrow
Change processing rules to allow same credential fulfilling different queries (#492) <https://github.com/openid/OpenID4VP/pull/492>
MUST NOT seems problematic, especially for credentials that don’t support selective disclosure
Potentially confusing “credential” for “presentation”
“Presentation” is defined as data from potentially multiple credentials
A reference to “Verifiable Presentation” instead is probably what’s needed
“Presentation” seems high-level, the ceremony, vs “Verifiable Presentation” which is likely lower-level
Ambiguity of “in this case” can communicate that there are cases in which the guidance is not accurate
Needs to be something saying, “don’t return things not requested” (in the theme of selective disclosure)
Additional offline discussion needed to refine this PR
Probably addresses final concern from ISO
add sd-jwt vcdm (#459) <https://github.com/openid/OpenID4VP/pull/459>
“VCDM” name collides with W3C VCDM
But people in PR agree purpose of this PR is to enable combining <something> with JSON-LD
Seemingly no observed objections to idea of renaming to “SD-JWT VCLD”
Intended to help existing implementations to transition to SD-JWT VC over time
Changing the name makes it seem like there’s another technology to transition to
Reviewing comments, seems like keeping with VCDM has generally received consensus
What about not giving it a name? This is primarily introducing a new `id` claim
Few objections to trying to drop the name
Strong preference expressed for “VCLD” as it communicates it’s not just a transitional solution
Will bikeshed further in the PR
Ideal deadline is “before Wednesday”
URL-Scheme is the wrong way conveying (wallet-)metadata (#411) <https://github.com/openid/OpenID4VP/issues/411>
Add further details of how errors are returned from Browser API including a example error response (#204) <https://github.com/openid/OpenID4VP/issues/204>
Current consensus is that protocol communicates errors as resolves, not rejects 
Giving error responses after credential selection can be a problem because it can reveal things like a value has been matched
Wallet selection should not be considered consent to present to verifier
In the DC API, before selection, Verifier learns nothing. After selection, it’s okay for wallet to return its own error codes. DC API will resolve with OID4VP errors
No introducing new error codes/behaviors/etc… this is about browser API having errors that map to protocol
No opportunity to have DC API reject on some errors for sake of developer ergonomics because sometimes protocol responses will come back encrypted so DC API can’t know to reject
Suggestion to be careful about returning errors, but uncertainty around what layer
Huge problem in WebAuthn that errors are too vague
Great idea to talk about acceptable errors at IIW as errors exist in three big buckets:
Platform
Protocol
Wallet
Would be great to reach consensus this week to make it into final draft
make consistent the use of prefixes in the client_id prefixing (#401) <https://github.com/openid/OpenID4VP/pull/401>

Tim Cappalli <mailto:tim.cappalli at okta.com> takes over notes.
#401 Client ID prefixing
Kristina giving background: framing has been to not mandate prefixing for OID federation because it’s a breaking change. Recently discussion evolved and determined not to be breaking, as it's happening in the context of OID4VP. Based on that, current direction to mandate prefix for OID Federation in OID4VP. Federation spec stays as is. Chairs: if we can’t reach consensus, consider removing federation from VP 1.0. Should try to reach a conclusion
Joseph: we do have consensus on DID, do have consensus on adding openid_federation prefix, two things there’s consensus on. Main disagreement is on https. Main source of disagreement is around “HTTPS fallback case”. Raised in Connect WG. No consensus in that WG. Don’t think we need to remove federation, but may need to remove “HTTPS” until there is consensus. HTTPS could be breaking change in the future
Nat in chat: “Proposing a minor change to line 497. If a : character is present in the Client Identifier but the value preceding it is not a recognized and supported Client Identifier Prefix value, the Wallet can treat the Client Identifier as referring to a pre-registered client, or a legacy client that does not support Client Identifier Prefix. Unless the Wallet can establish enough security context with it, it may refuse the request.”
Kristina: if client doesn’t understand client identifier prefix, it should not be talking to wallet
Nat: can be a legacy client who can be talking to the wallet, or an old wallet as well. Need to think about migration
Aaron: sounds like it may be trying to add back in the exception for non-prefixed client IDs.
Nat: only for HTTPS
Aaron: that is even bigger concern. Goal of this PR is to address that interop problem.
Joseph: not sure there’s a need to address legacy clients here
Nat: there’s an instance of “openid fed”. 
Kristina: yes, but editorial. Trying to gain consensus on behavior. Options on the table: we say no exceptions to prefixing or something else
Brian: more clarity, current text of PR implicitly disallows non-prefixed but not explicitly
Gail: how would we reconcile it later? 1.1 in VP or Federation?
Kristina: should try to reach conclusion. Been talking about this forever.
Nat: concerns about older clients. Italy using OpenID Federation with 5 million people.
Kristina: need to clearly separate OID Federation with Connect vs wallet ecosystem.
Joseph: Italy targeting older version of the spec. 
Torsten: request types are different (VP vs Connect). Recaps client ID scheme feature: from beginning all diff client ID schemes required the client to pass the prefix as a different parameter. Default if there was no parameter that it was pre-registered. Only way to use with OIDF federation was to add `openid_federation`. Only change was to move the client ID scheme into the client ID value. Realized that there are security issues with a separate parameter. Any existing clients would be using the scheme parameter.
Christian: same point. Only exists in the scope of OID4VP. Lot’s of other breaking changes towards final. They have to update anyway. No effect outside of OID4VP.
Mike: been asking to keep things the way they are so that in OID4VP the client ID is the same as in OID Federation. Done deliberately in October. Unambiguous and solves the security problem. Understand the motivation for consistency as an engineering decision. This would be the first time in my knowledge of the OIDF, that one WG would add text to their spec that normatively contradicts text in another WG’s spec. Bad precedent. Not engineering issue that bothers me. 
Brian: all kinds of conflicts across WGs. FAPI and iGov for example. Don’t agree with comment about precedent. 
Joseph: change made years ago
Mike: agree with Torsten’s point as an engineering point. 
Aaron: Unfair categorization to call this contradictory. There is an existing normative contradiction from OID Federation vs OAuth
Christian: within their scopes, they’re not contradicting each other (OID Federation vs OIDVP)
Gail: procedural point, interesting topic for OIDF staff to take away. There is obviously a vision for specs to interoperate, but becomes increasingly difficult with breadth of areas. Take away an action about the principles approach, and if there are escalations across WG, how does that get resolved.
Kristina (chair hat on): yes, let’s take that offline. Took this issue extremely seriously. Co-chairs spent a lot of time on this topic, leading to proposal. If the remaining concern is non-technical, then the PR would be merged on Friday based on consensus an running code.
Torsten: reflecting on what Mike said. Discovered early in process of OID4VP that client identification for wallets is very unique. Talked about it in IETF 116 for OAuth WG to work on. Also talked to OID Federation editors around the same time. Many attempts to bring attention to this.
Mike: not going to block adding the prefix. Still think it would be preferable to leave a carveout for HTTPS. Asking Brian to revert the change where prohibited using a default in a profile.
Aaron: one driving goal of this change is to clear up interop problems. Leaving carve out leaves interop challenges. Highlights example from implementer’s POV in the PR comment: simple and unambiguous with prefix required.
Torsten: has Connect considered adding a prefix to HTTPS for OID Federation spec?
Mike: there has been some talk of asking the question, but spec is near final status. Already did sec analysis, interop next month. May learn things from developers. 
Kristina: no, question was historically, why have you not considered this?
Torsten: Tobias has a proposal years ago where client ID was HTTPS and there was a well-known. People will use always use HTTPS for resolving metadata in other schemes than federation.
Kristina reminded of OIDF consensus rules
Brian: carveout for HTTPS was added originally in hope to make it more palatable for OID Federation folks. Should I leave change the PR?
Kristina: approvals are based on the current language. No need to change.

Mick Hansen <mailto:mick.hansen at criipto.com> takes over notes
https://github.com/openid/OpenID4VP/issues/511
 <https://github.com/openid/OpenID4VP/issues/511>Should be resolved for 1.0

https://github.com/openid/OpenID4VP/pull/500
 <https://github.com/openid/OpenID4VP/pull/500>Attempt to get WG on the same page.
#500 defines missing vp_formats and indicate crypto suites supported

- mDOC formats, needs to specify curve, suggestion of using fully-specified algorithms
(note: Fully-specified algorithm spec is nearly complete)
What is the impact of changing to fully-specified? Verifiers can specify what fully-specified algorithms they accept.

Martijn: Potentially significant change, impact needs to be discussed.
Timo: Why do we specify it for SD-JWT but not mDOC? Either use it or not.
Paul: Important for OpenID4VCI, not necessarily as relevant for OpenID4VP
Torsten: Also relevant for OpenID4VP to preserve privacy

https://github.com/openid/OpenID4VP/issues/289

 <https://github.com/openid/OpenID4VP/issues/289>
Torsten: Still looking for a viable option to solve the problem. DCQL purpose property is more viable than discussion from thursday. 
Christian: Concerned about rendering in the context of wallet, arbitrary text form Verifier. The consent of the user should be explicit re: purpose
Paul: Signed requests, the purpose is embedded in the DCQL request, eIDAS: could check purpose against registration certificates. Could read purpose on registrars website.
(Name?): Code vs text discussed in previous call, the Verifier can be malicious in either case. Wallet would need to know what Verifier is allowed to do. Transaction log can record the purpose
David: Assumption seems to be that the user is going to interact with untrusted verifiers, thought we decided long ago that a user would only interact with trusted verifiers, where trust in purpose is a non-issue since the verifier is not a bad actor. Does not require a signed request if the trust infrastructure can tell the wallet that the verifier is trusted.
(Name?): Advantage of code over text is that it’s easier to establish trust, and the potential damage is lower from an incorrect/malicious code than from free form text. Wallet has control over how a code can be rendered. 
(Name?): From a UX perspective, with multiple credential sets, how is the wallet supposed to communicate what the purpose is of a multiple set of credentials.
Paul: Likes “purpose”, might make sense to include “purpose” in KB-JWT, to bind authorization to what the verifier asked for at that point. Maybe a compromise of having pre-defined cases for instances such as buying alcohol, and free form for other cases
Mirko: EU; purpose is intended use, each relying party will have dedicated intended use. Intended use could be a list of millions that have to be managed.
Lee: Votes for just removing it, too complicated to solve for now, remove free-form text and enums do not scale. 
Torsten: Argument against free form for text was phishing, agrees with that. Code/index does not solve that problem. Pre-agreed list of purposes, any relying party could randomly choose a purpose, makes rendering useless in terms of phishing. A list of reasonable purposes cannot be managed in an effective way. Takes more than 10 purposes to give users a true context. Flexibility: Relying Party can set the context, drop purpose in request, then need to solve the UX challenge of what subquery fulfils what purpose. 
Christian: Agrees to remove for the time being, really hard to find a generic solution. Tackle at ecosystem level (EU)

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