[Openid-dcp] Notes from 20th October 2025 hybrid meeting

[Joseph Heenan]

Many thanks to Frederik for taking these notes!



DCP WG notes - 20th October 2025 Hybrid meeting

Attendees

Gail
Joseph
Kristina
Gareth Oliver
Mike Jones
Dirk
Mohammed
Lukasz
Ryo Nakashima
Hideaki Furukara
Chris Philips
Federick
Steve Venma
Mark Haine
Nancy Camwing
Paul Bastian
Christian
Hicham
Brian Campbell
Oliver
Martijn
Dorin Ciobanu
Bjorn Hjelm
Dima
Thomas Darimont
Peterri Stenius
Andrii
Frederik Krogsdal Jacobsen
Lee Campbell

Notes

Notetaker: Frederik Krogsdal Jacobsen


We’re delighted to invite you to join fellow OIDF members & WG participants for an informal reception – please see below for timing and location details....
📆 Date: Monday 20th October 2025
🕓Time:  6:30pm to 8:30pm PDT.
:round_drawing_pin: Venue:  Sportspage Bar & Grill
🗺️ Address: 1431 Plymouth St, Mountain View, CA 94043, United States
🌐 Web: www.sportspage.bar  


HAIP
Outstanding pull requests
Mention VP & VCI in Privacy Considerations
https://github.com/openid/OpenID4VC-HAIP/pull/310

Christian: either keep the language in both of Privacy and Security Considerations, or change it in both.
Joseph: People did not want the language to be normative because the interaction with the parent specs would be unclear.
Kristina has approved.
Paul and Christian will also review.

No objections to merging later today after reviews.

Add references to Ecosystem implementation guidelines
https://github.com/openid/OpenID4VC-HAIP/pull/312

Editorial: Adds links to sections in the bullet list.
Parked until Gareth joins the meeting.

Jan will need to accept suggestions for changes.
No objections to merging later today after reviews.

Add issuance clarification
https://github.com/openid/OpenID4VC-HAIP/pull/313

Christian: there is a proposed change to the PR.
Christian’s suggestion: wallet MUST support issuer-initiated, everything else is ecosystem-dependent.

Hicham: MUST you support issuer-initiated flow?
Christian: It is nice to have ONE mechanism that every ecosystem can rely on as a minimum. Issuer-initiated flow is a nice baseline because it does not involve any upfront negotiation.
Hicham: We should clarify that the wallet still decides whether it wants to actually accept a credential or not.
Tobias: You could say this for every normative statement.
Hideaki: Is this about the user or the wallet?
Christian: User consent should always be granted before accepting anyway.
Kristina: This is about the technical protocol, not the business logic.
Paul: There is no alternative to issuer-initiated flows in a general ecosystem.
Tobias: This does not define the mechanism enough to be normative. Does this belong in the ecosystem implementation guidance instead? Some ecosystems may not (for some reason) need issuer-initiated flow.
Paul: If you don’t have issuer-initiated flow, you don’t have an ecosystem.
Many people: Why?
Gareth: An ecosystem could have a registry of issuers and there would be no problems without issuer-initiated issuance.
Kristina: This is led by the credential types and their associated policies.
Tobias: There are many VC-like implementations today that only allow issuance from the wallet/app itself. The ecosystem should define what the wallet needs to support. We should only require issuer-initiated flow in HAIP if NO ecosystems don’t need it.
Dorin: It sounds like this is a SHOULD instead of a MUST.
Gareth: The underlying mechanisms are not established enough for this to be normative. It would be a different story if e.g. DC API was already widely available.
Joseph: The suggested language means the issuer MUST have some sort of website or the ability to send an email.
Paul: This does not mean the issue MUST do anything.
Lukasz: In practice, it does because this establishes a standard for the wallets that issuers will need to be interoperable with.
Tobias: We don’t need to mandate this because the incentives are there anyway for scaling large ecosystems.
Frederik: Maybe we should do it as a SHOULD for now with an explanation of the scaling issues.

Kristina has drafted a suggestion.

Paul: Ecosystems needs to define how to send credential offers for issuer-initiated issuance.
Chris: Is the language for issuer-initiated issuance still too strong?
Gareth: Maybe add a recommendation for the ecosystem to at least add issuer-initiated issuance?
Christian: Yes.
Gareth: It depends on the type of wallets and issuers in the ecosystem.
Christian: There should be guidance for the ecosystem.

Summary: If you have an ecosystem where the wallet is the “best known” thing, it is recommended to support wallet-initiated issuance. If you have an ecosystem where the issuers are the “best known” thing, it is recommended to support issuer-initiated issuance.

Christian will write a suggestion for the exact language.

Improvement to wording around ephemeral encryption keys in VP
https://github.com/openid/OpenID4VC-HAIP/pull/322

This has been open for a week and has enough approvals.
No objections to merging. PR has been merged.

Open issues

sudden appearance of ISO/IEC 23220
https://github.com/openid/OpenID4VC-HAIP/issues/320

Hideaki: The ISO spec is not mentioned in HAIP except in a title.
Kristina: This is a leftover from a reference to VP.

Kristina has a PR ready which fixes this by clarifying the reference:
https://github.com/openid/OpenID4VC-HAIP/pull/323

Add text on acceptance of crypto suites
https://github.com/openid/OpenID4VC-HAIP/issues/297

Should ecosystems be able to reject e.g. P-256 algorithms?

Kristina: This looks like a business/ecosystem decision again. We could not reach consensus on adding language on this earlier.
Tobias: The main reason for this is that crypto moves on, so normative statements may not age well.
Paul: Could you solve this by adding an expiration date for the crypto suites?
Tobias: Maybe not, countries can change their mind any time.
Gareth: The intent was to make it possible to reject unwanted crypto suites.
Tobias: Maybe this should be a SHOULD or a RECOMMENDATION?
(Note: OIDC says OPs MUST support SHA-256 signing)
Chris: What will this mean for certification?
Kristina: All MUSTs have to be certified.

Christian will add a reference to the new ECCG crypto guidelines in section 10.1.

How does an Issuer communicate a single-use (or similar) policy
https://github.com/openid/OpenID4VC-HAIP/issues/260

Paul: Some people did not think that batch issuance meant that individual keys should be single-use. There is currently no way to signal to wallets that credentials are single use. We should add that to issuer metadata or in the credential in VCI 1.1.

Proposal to say that wallets can assume that any batch issued credential is single use.
This will be added to ETSI standards, so there is good reason to align with that precedent.

This is really a VCI issue, but it could potentially be temporarily worked around by adding language to HAIP.

Tobias and Lukasz: This is a big topic since there are many ways to ensure privacy with batch issuance.
Gareth: It might be credential specific to gain performance when using non-identifying presentations.

Paul: ETSI will do something, so it would be nice to have an opinion on this to avoid divergence.
Gareth: What does ETSI need? If this is a dedicated policy parameter it might be alright to add a simple configuration option.
Hicham: Can we talk to ETSI to figure out what they want?
Paul: ETSI proposals have been uploaded so we can take a look.
Lukasz: If this is an issuer metadata config option, how often does the wallet have to update the policy?

No consensus. Only more questions were generated during the break.

Tobias: At the moment, holder confirmation (such as a portrait being shared during an in-person age verification presentation) means that there will often be a lack of privacy anyway.
Paul and Tobias: In places without stable internet connection, single-use exhaustion is a real risk. Rotating batches may be more appropriate in this case.
Paul: The policy is an ecosystem decision based on local factors.

Kristina has added a link to the ETSI document to the issue. ETSI has a relatively strict timeline.

Conclusions:
There are many different requirements, so there is an appetite to make it possible to communicate policies in ecosystems.
Consensus that this is really an issue for VCI 1.1.
We still have time to add language to HAIP if necessary to converge with e.g. ETSI.

Defence against malicious issuance
Chris: Should there be any language about how wallets should protect themselves from e.g. issuers spamming them.
Paul and Tobias: Maybe. If so, it should probably go in the implementation or security considerations.

Chris: It can be valuable for the ecosystem operator to make choices on behalf of the user instead of on behalf of providers.
Christian: We have previously discussed this and added some extension points where ecosystems can define additional rules. There was no consensus on a global level, so ecosystems need to make their own decisions on these topics.
Break
For 10 minutes.

Topics to discuss during break if interested:
Re-adding ecosystem extension examples
Fix mixed usage of document/profile/specification
Single-use issuer policy re. ETSI
Define the term ecosystem (do we want to?)

HAIP again
Issues
consider re-adding ecosystem extension examples
https://github.com/openid/OpenID4VC-HAIP/issues/304

Kristina: Do we want to re-add these examples to the spec? If yes, how should we write them to make it clear that they are examples?
Gareth: I wrote this since it seemed to be useful. I still think there is value in this.
Joseph: The feedback was to make it clear that these are examples and not normative in the scope of HAIP.
Christian: The examples are valuable.
Paul: Put each example after the ecosystem guidance list bullets to make it more clear that they are examples.
Gareth: I disagree, since the idea of the examples is to show that you can combine multiple policies to an ecosystem.
Frederik: What if you did both to make it clear?
Frederik and Joseph: Could we put this into a differently formatted box to make it more clear that these are examples?
Hicham: Could we separate issuance and presentation in the examples?
Kristina and Joseph: Yes.
Gareth: It is useful for the examples to show how the policies on issuance and presentation interact. We should clarify the examples.
Chris: It would be useful to have a recommendation for the coverage you need for an ecosystem policy.
Kristina: HAIP was originally such an example, but the ecosystem implementation considerations are comprehensive.
Chris: My experience from SAML2int is that a comprehensive list is necessary.
Kristina: Is it the examples that need to be more thorough or also the ecosystem considerations?
Gareth: We are not at a place where we can do it at that level yet because government bodies are making a lot of strong choices. If we contradict big ecosystems, we can’t do much.

Kristina: We should make sure the examples cover all of the bullets in the ecosystem guidelines.
Chris: Number the bullets in ecosystem guidelines to make them easier to reference.

Lukasz: Could we make a living document with more guidance?
Chris: We could write boilerplate for this.
Kristina: Big ecosystems have very strong opinions that are not fully aligned, so this will be difficult to get acceptance on.
Chris: From an interop perspective, this is going to lead to issues. Any opinion is valuable, even if it is just the bare minimum.
Kristina: A difference from SAML is that the policies here are very credential-driven, since credential types contain very different information.

Dima: Why is this not in a separate document?
Kristina: What would be the benefit of a separate document? All of the large ecosystems will make their own documents anyway.
Dima: Each bullet is a whole discussion in itself.
Christian: Eventually, some of the guidance will clarify itself because the underlying technology will become more stable. E.g. use of DC API if it becomes widespread.

Kristina: Where is the complexity? Each bullet is relatively easy to take an opinion on.
Paul: I agree. The bullets are things that the working group can not even agree on.
Chris: It is difficult to give guidance because it depends on whose perspective you take. E.g. what is good for the end user, issuer or wallet provider?
Chris: If there are only a few options for each bullet anyway, it would be useful to enumerate them.

Kristina will make a PR to address the issue.

fix the mixed up usage of "specification", "profile", and "document"
https://github.com/openid/OpenID4VC-HAIP/issues/316 

No objections on moving to “specification” everywhere.

Kristina will make a PR for this.

HPKE
Kristina: Rumor says that Japan has requirements around HPKE.
Right now, we use JWE for encryption. The draft for using HPKE in JWE (in IETF) is not final yet, so we could not rely on it. Hideaki and Ryo, can you share the Japanese perspective on this?
Hideaki and Ryoi: We don’t know.
Kristina: Can you take it back to the Japanese government and ask to get rid of the rumors?
Hideaki: Yes.

Tobias: I guess this is only for encrypting presentations in OpenID4VP? We have a stakeholder that would also want it in VCI credential responses, so we should try to make sure any solution for HPKE would also work for VCI.
Kristina: Is HPKE in VP or VCI higher priority?
Tobias: Ideally we would find one solution for both.

Hicham: We still think it’s better to have HPKE. Did anything change since the last time we discussed this?
Kristina: Only that we have now cut 1.0 and can now work on 1.1.
Hicham: If I recall correctly, we said we would work on HPK for 1.1. Am I correct in understanding that the question is whether we should still do this.
Kristina: Yes. The WG works better when we have a single priority at a time. So we want to understand the priority of HPKE in comparison to other things.

Paul: Should we do our own HPKE thing or wait for JOSE HPKE?
Mike: As an editor of the JOSE HPKE drafts, we are describing the use of HPKE as a new key establishment mode in JOSE. I have not done this yet, but I will try to have a draft ready for the next IETF meeting.
Brian: This sounds different from what I understood the plan was at the last IETF meeting.
Mike: I will write a PR to add HPKE as a new key establishment mode and ask Brian and Filip to review it. The intent is to make it fit better into JWE, which has been difficult.
Tobias: I thought there was also feedback about the usage of the integrated encryption mode in JWE?
Mike: There was no consensus at the last IETF meeting about whether to change this.
Brian: There seems to be a disconnect between the content of the draft and the feedback on it. This is unfortunate because it makes it difficult to reference the draft in discussions.
Kristina: Please discuss this further in IETF.

Kristina: Does anyone urgently need HPKE?
Gareth: Google has strong requirements from issuers.
Lee: At least one major government wants this ASAP. They will only do OpenID4VP if they get HPKE at some point. This is more of an approval/policy problem than a technical problem. They will need to get other things approved if HPKE is not available.

Tobias: If JOSE/HPKE was finished, would we use that instead of defining our own representation?
Lee: I think we should define our own container format because there are still many unknowns about JOSE/HPKE. It should not be too hard to do that.
Brian: I don’t think it will be that simple. For something that be used in both VP and VCI and also works well with existing systems, I think defining our own container format will be more effort.
Kristina: Can someone write a proposal?
Gareth and Lee: Yes, we can do that very quickly.

Paul: We don’t need JOSE/HPKE to be final, we just need it to be in a state we like.
Mike: Wait until after the next IETF meeting to decide.
Kristina: Sounds like we should prioritize HPKE and maybe call some IIW session to discuss further.
Priorities
Paul: Do we have a list of potential topics for 1.1 to prioritize?
Kristina: Yes.

List of topics:
HPKE for VP and VCI
VCI interactive authorization endpoint
VCI server-to-server issuance
VCI DC API
VP discovery of public key/certificates of verifier by wallets
VP default behaviour for intent_to_retain
VCI credential usage policies
Per-credential metadata

These are not equally large problems and will require very different amounts of work to finish.

VCI interactive authorization endpoint
This enables a clean way to do presentation during issuance.
There were vulnerabilities in the original design, so it was removed from VCI 1.0.
There are 7 open PRs about this for VCI 1.1.

VCI server-to-server issuance
One architecture for wallets is to have a wallet server behind the wallet on the device. This allows the wallet to take on some scaling burden from issuers.
There are various reasons to prefer this for wallet providers at large scale.
You might not want to do this in some cases because the privacy model is different.

Hicham: This is a high priority for us.
Gareth: This is more complicated than HPKE and will require a larger rework of the spec.

Gareth: Step one should be to figure out whether we want to work on this at all.
Tobias: It should be in scope since it is on the list.
Joseph: It is a decision for the working group as a whole to decide whether this is in scope.
Hicham: We should spend a lot of time on this, but we should also do other things while doing it.

Joseph: Maybe this work should be done in a sub-working group.
Christian: I think a subgroup would be okay.
Paul: I think this fits in the working group scope. We already have calls so often that a sub-working group might not be necessary.
Kristina: We don’t expect the same level of effort in the future as we have had this year since there was so much urgency this year.

Tobias: There are other features that will require architecture changes, so there is a larger amount of work related to this. E.g. wallet notifications. The question is how many of these to tackle at once. The danger is that wallet implementations diverge on features.
Paul: There should be minimal or no changes to the issuer if possible.
Gareth: I agree in principle, but this needs more discussion. The changed privacy model etc. means that this may require changes everywhere.
Hicham: I agree with Gareth. We need to look at it from a problem solving point of view. We need to find out what the requirements are for server-to-server and then see if it can work in the existing system.
Gareth: I have a list of requirements for server-to-server.
VCI DC API
Kristina: Lee made a PR that was then closed because of lack of progress.

Is this a priority for anyone?

Paul: Yes, for everyone in the EU.
Tobias: We are also seeing demand in Australia.

Gareth: We need to discuss how updating information and wallet matching will work. Maybe at an IIW session.
Tobias: There are some potential security issues that platforms needs to avoid.
VP discovery of public key/certificates of verifier by wallets
Joseph: New Zealand requested that it be possible to discover verifiers without a central registry. There is an open issue: https://github.com/openid/OpenID4VP/issues/671
Tobias: I also have some thoughts on this that I will add later. The intent is that the end user needs information to make a decision on whether to trust a verifier instead of the wallet doing it.

Christian: You are basically asking for a new client ID prefix aligned with this use case?
Tobias: Maybe, but not necessarily.

Lukasz: Is it not enough to send client metadata in the request?
Tobias: No, because a human needs to make a decision from some trusted source, e.g. a domain name.

VP default behaviour for intent_to_retain
Krisitina: We parked this for 1.1 to clarify the purpose of intent_to_retain. This is something we could pick up at 

VCI credential usage policies
Paul: This had a lot of discussion today, so we should keep discussing it further.

Per-credential metadata
Gareth and Frederik: We need this.
Christian: We have a proposal for this already.

Paul: Don’t we already have this?
Tobias: Yes, but it needs to be extended.
Paul: This is what Lee has worked on for per-credential display.

Priority decisions
We promised IAE for 1.1 and there are PRs ready for review.

Issuance over DC API should be a relatively small amount of work once there is some implementation experience with DC API and wallet matching.

There is no consensus for priorities yet.

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