[Openid-dcp] Notes from DCP WG Hybrid Meeting 8th May 2025

[Joseph Heenan]

Thanks to Jan & Timo for taking these notes!



DCP WG Hybrid Meeting 8th May 2025

Attendees
Joseph Heenan
Timo Glastra
Kristina Yasuda
Christian Bormann
Shigeya Suzuki
Jan Vereecken
John Bradley
Nat Sakimura
Steve Venema
Daniel Fett
Martijn Haring
Bjorn Hjelm
Brian Campbell
Aders Mellqvist
Mirko Mollik
Filip Skokan
Gareth Oliver
Lee Campbell
Shigeya Suzuki
Oliver Terbu
Klaus Roehrle
Kaliya
Mirko Mollik 
Paul Bastian
Peter Sorotokin
Notes

OpenID4VP / PR592 
https://github.com/openid/OpenID4VP/pull/592

Clarification is accepted by the WG

OpenID4VP / PR593
https://github.com/openid/OpenID4VP/pull/593

Looking for more approvals (3-4 more needed)
Christian brings up “If empty, no specific constraints are placed on the metadata or validity of the requested”
Martijn finds this approach different from elsewhere in the spec where if empty it should be omitted
Daniel thinks this is better than conditionally making this required

Looking for approvals

OpenID4VP / PR509 make the meta parameter required
https://github.com/openid/OpenID4VP/pull/509

Looking for reviewers. 

Christian wonders if a better place to add this is HAIP for example.

Martijn brings up that there are two ways to review:
1/ Is the text correct (MUSTS, SHOULDS etc)
2/ Is this the correct place (which is more difficult to decide)

OpenID4VP / Issue 569
https://github.com/openid/OpenID4VP/issues/569

Kristina introduces the issue

The type attribute is not part of JSON-LD, so there is no need to specify a relationship with vct. It would introduce a dependency
No strong objections to keep in unspecified
Closing issue.

OpenID4VP / Issue 575
https://github.com/openid/OpenID4VP/issues/575

Martijn comments that there is no requirement for cryptographic key binding (for holder).
The default is that it is required though
The idea here is to make sure that OpenID4VP isn’t blocking this in the future

Issue closed

OpenID4VCI / Issue 202 Security Issue with untrusted Issuer Metadata
https://github.com/openid/OpenID4VCI/issues/202

Paul introduces the issue
In essence Paul argues that either all metadata is signed or not. Now some parts might 
Daniel comments we should have a use case for this
Christian says the unsigned part could be more dynamic and the signed part is more static
Kristina says this what put in as a compromise
Joseph: should we just return a jwt instead of a json with a jwt inside
Kristina: against it, as it would also change the media/content type
Paul: http allows negotiation to accept certain media type
Joseph: Not all CDNs have good support for this

Different options described in the issue. 

Consensus on “option 3: both application/jwt and application/json depending on signed or unsigned”.
Paul will create a PR

OpenID4VCI / Issue 202 Improve references to security BCP
https://github.com/openid/OpenID4VCI/issues/291

It is not about the references, it is about the content
Need to go through the security BCP and make sure that all of it is integrated
Alternative is to use FAPI2

Consensus on either using BCP or FAPI2.
FAPI2 is a concrete list of actionable items 
Some items on FAPI2 would not need to be implemented, so need an exception list.

OpenID4VCI / Issue 370 incomplete parameter definition in Credential Format Profiles
https://github.com/openid/OpenID4VCI/issues/370

Joseph will review if this is still needed.

OpenID4VCI / Issue 339 Support Credential Request application-layer encryption
https://github.com/openid/OpenID4VCI/issues/339

Kristina introduces the issue

Discussion on the design of this feature where request is encrypted.
WG agrees that communication between wallet and wallet backend is not standardised
There are some hypothetical scenarios where this could break down, but WG agrees there is no concrete case for this.

Paul: who decides whether to encrypt, the wallet or the issuer
John: if the issuer provides a key you should encrypt
Mirko: What if you don’t support alg. Fallback?
John: No, you’re not compatible, otherwise open yourself up to downgrade attacks
Kristina: brings up that in response this is also a MUST for the issuer response

Martijn: brings up that if it is required for credential response which is an issue for him

Martijn to create an issue that provides an example of which attributes in the response would not need to be encrypted
Martijn to check and confirm if the encryption of the request is okay

OpenID4VCI / Issue 207 Add section on processing of metadata
https://github.com/openid/OpenID4VCI/issues/207

Daniel: this is linked to https://github.com/openid/OpenID4VCI/issues/202
PR for issue 202 will need to contain processing/validation rules
Kristina: this is more generic issue

Joseph to create a PR for this

OpenID4VCI / Issue 491 Evolution of the nonce fetching
https://github.com/openid/OpenID4VCI/issues/491

Lots of challenges around nonce for key attestations/credential request, ended up with nonce endpoint

Now also considering nonce endpoint for authorization server, can be used for DPoP and wallet attestations. (added to the wallet/client attestation spec)

If both AS and issuer run on same url, they could use the same nonce endpoint

How many nonces do you have?
AS: Wallet attestation
AS: DPoP
Issuer: c_nonce (already in spec)
Issuer: DPoP (PR open to return it in the nonce endpoint)

DPoP error is flawed, want to use DPoP in nonce endpoint
You can allow DPoP to be returned in any responses (success and error), so just require it to always be returned, no need for a new endpoint.
But we need a nonce endpoint anyway, so then we can just piggy beg on it
We need to make sure that the different nonces are correctly distinguished
Nonce endpoint would be in the IETF wallet attestations spec, as wallet attestations can also be used outside of 
Concern that having it defined in IETF can cause divergence between nonce endpoint in VCI and IETF
Discussion on whether wallet attestations spec should be part of OID4VCI, some suggestions going other way that even Key attestations should be a different spec

Agreement that nonce endpoint is useful in wallet attestations spec, will add it there first (in next two weeks)  and then reference it in OID4VCI

Nonce is not a good word, it should not have been called nonce in DPoP, and it should probably also not be called nonce in wallet attestation.Should we also rename c_nonce to challenge (issue 496)?

OpenID4VCI / Issue 61 Redirect-URI for OpenID4VCI
https://github.com/openid/OpenID4VCI/issues/61

We have this in OpenID4VP, it can improve the flow, so you can continue the journey after the credential is issued.
There is the challenge you’re ending up in the same browser tab
Could it be added to 1.1?
Issues with e.g. refresh where the wallet will do the refresh in the background, so you don’t want to redirect in that case
We should not conflate redirect_uri, something like completion_uri?

Where to put it?
Putting it in Credential offer? ->  is not authenticated, so that could introduce phishing attacks
Extend notification endpoint?
Credential response? Should not add it to the credential response due to e.g. batch/multi issuance
New completion endpoint
Some pushback, as issuers might rely on it
Issuer should not rely on it (seems to be agreement on)

Only a problem in same-device

Pushback against completion_uri
Wallet will be free to ignore this
There is also interest in redirection even if credential is not issued immediately (e.g. deferred issuance)
The completion uri could also be used to add extra information for the user (not session related), so e.g. after you got an mdl a page where it’s described what you can do with it.
What about the option that the wallet closes itself?
Does it work on iOS?

Issue contains 5 different options
Consensus to get some implementation experience

It might make sense to return it in the credential response if it’s deferred?
Inform the user about how long it’s going to take
Option also raised to send an email to inform the user of this

Two use cases
After done with all flows in wallet return to the issuer and continue flow
For the issuer to provide more information

WG agrees that the continuing the flow use cases is most important

What if the issuance failed, do we also want to redirect in this case

Question whether we should optimize for deferred flow

WG needs more time to think about it, option 3 (new completion endpoint) is preferred


OpenID4VCI / PR 492 / PR 490
https://github.com/openid/OpenID4VCI/issues/492
https://github.com/openid/OpenID4VCI/issues/490

Shortly discussed, PRs need to be reviewed

OpenID4VCI / Issue 430 
https://github.com/openid/OpenID4VCI/issues/430

WG does not see a good reason to change this, also since it’s a breaking change

Might just need a clarification and remove the reference to RFC 6750 for the error response structure, as it’s the same structure, but separate definitions

OpenID4VCI / Issue 228 Single signed metadata does not scale
https://github.com/openid/OpenID4VCI/issues/228

Do we need OpenID4VP-like multi-rp functionality for signed metadata?

Assumption is that the issuer knows which trust framework it will operate in for a specific credential, if you need multiple ways to authenticate you can use multiple issuer urls

No clear use case, can be added later




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