[Openid-dcp] Notes from 5th May 2025 hybrid meeting

[Joseph Heenan]

Thanks to Timo & Christian for taking these notes!

(Please reply to this email if anything needs correcting/adding!)



Attendees
Joseph Heenan
Paul Bastian
Timo Glastra
Mirko Mollik
Gail Hodges
Kristina Yasuda
Torsten Lodderstedt
Adam Cooper
Christian Bormann
Dima Postnikov
Masa Obata
Oliver Terbu
Gail Hodges
Soshi Hamaguchi
Steve Venema
Shigeya Suzuki
Mike Jones
Brian Campbell
Gareth Oliver
Martijn Haring
Bjorn Helm
Naohiro Fujie
Soshi Hamaguchi
Sebastian Bickerle
Micha Kraus



Minutes
Updates on standards
Targeting June 30th release of OpenID4VP
Targeting June 30th as ready for final review OpenID4VCI
After OID4VCI and OpenID4VP switch to HAIP (so end of June) 
OpenID4VP PR 509
https://github.com/openid/OpenID4VP/pull/509
Hoping to discuss later this week
Please leave reviews
OpenID4VP PR 589
https://github.com/openid/OpenID4VP/pull/589
Arrays should be non-empty
OpenID4VP Issue 590
https://github.com/openid/OpenID4VP/issues/590 
Meta in DCQL query is marked as optional, but the vct_values, doctype_value etc are required
Should make meta required as well
Proposal from Chirstian to keep it optional, but make it required per credential format, as there may be credential formats that don’t need meta
Question is, will there be formats that don’t require meta
Or do we even want to allow that
Setting it to required is a security feature, interoperability feature
Keeping it optional keeps more options open
Worst case scenario you need to send an empty object if it’s required but the credential format does not require it
Leaning towards making meta mandatory, and you can send empty object if no meta properties are needed
Christian will make a PR
OpenID4VP Issue 347
https://github.com/openid/OpenID4VP/issues/347
What to do with APV and APU values, as they might be specific to a profile (e.g. 18013-7). How do you know which APU and APV values?
 Need to communicate whether APU or APV are defined, and which values to use
Suggestion in the issue to add a new encryption_details_supported parameter
Question whether a generic profile supported vs specific encryption details supported parameter should be added
OpenID4VCI PR 451
https://github.com/openid/OpenID4VCI/issues/451
Do we want to merge this PR?
Agreement on the PR, needs to be reviewed
OpenID4VCI PR 452
https://github.com/openid/OpenID4VCI/pull/452
Need guidance on how to treat batches of credentials
Comment from Tobias on the PR, how do you know the new dataset is the same?
Hard to know for a wallet that the new credential batch replaces the old one (new credential vs same credential but new batch)
There was an issue/proposal to return a credential_dataset_identifier and link it based on that.
Current PR describes to only throw them away if they are not valid anymore (expired, etc.)
If you get a new dataset you should throw them all away
Would there be a reason why people would want to keep a credential even if a new one is issued.
Confusion about what Credential Data set means?
Doctype + namespace + claim names
Above + the specific values
Credential data set identifier points to a specific data set, which can evolve over time
If old credentials should not be used anymore, revocation could be used, but the wallet does not know when credentials are revoked
Suggestion to not say “delete old credentials”, but “start using the new ones”
Wallet still doesn’t know what to do with it
This can be solved using dataset identifiers, but that is aimed for 1.1
No implementation experience yet
General consensus to close the PR and fix it in 1.1 with credential versioning
There is already an implementation consideration in section 13.5
OpenID4VCI PR 458
https://github.com/openid/OpenID4VCI/pull/458
Move proof types to appendix
Only consideration is that all specs that reference OID4VCI need to be updated
Consensus to review/merge, add it to Appendix F to now mess with key/wallet attestations references
OpenID4VCI PR 460
https://github.com/openid/OpenID4VCI/pull/460	 <https://github.com/openid/OpenID4VCI/pull/460>
Oliver to resolve conflicts, then it will be merged
OpenID4VCI PR 464
https://github.com/openid/OpenID4VCI/pull/464
Daniel to take a look at the PR
OpenID4VCI PR 472
Agreed to move it to 1.1
Close PR for now to keep number of open PRs small(-ish)
https://github.com/openid/OpenID4VCI/pull/472 
OpenID4VP PR 478
https://github.com/openid/OpenID4VCI/pull/478 
DPop Nonce on the nonce endpoint
There is a nonce endpoint for the c_nonce, also allow it to return a DPoP nonce for optimization
Will only work for the resource server, not for the authorization server (as you can’t assume the AS and resource server are the same entity)
Do we need this optimization?
It would help with wasting credential proofs (that might need to go through HSM), as you first submit the proof, then get a DPoP error, then you submit it again, but maybe some issuers invalidate the proof/nonce used after it has been used
Consensus to add this optimization
OpenID4VCI Issue 356
https://github.com/openid/OpenID4VCI/issues/356
Oliver to create a PR
OpenID4VCI Issue 99
https://github.com/openid/OpenID4VCI/issues/99
Previous agreement was
when there is sd-jwt vc metadata, that takes precedence over VCI metadata
when there is no sd-jwt vc metadata, VCI metadata must be used
no alignment between the two is expected and sd-jwt vc metadata can keep evolving regardless of the vci metadata
Still makes sense
Make it generic, as it applies to e.g. W3C and SD-JWT VC
Default is VCI, unless credential format specific says something else (in case of SD-JWT VC the above agreement will apply)
OpenID4VCI Issue 303
https://github.com/openid/OpenID4VCI/issues/303
Match what we did in OpenID4VP PR 553, if there’s issues in VCI, it can be fixed and then also applied to OpenID4VP
Some concerns still with the OpenID4VP PR (related to mapping between fully-specified and non-fully-specified algorithms)
Can’t expect mDOCs to use fully-specified algorithms
There is already an open PR, but it’s not fully aligned yet. Oliver to update
OpenID4VCI Issue 305
https://github.com/openid/OpenID4VCI/issues/305
We have key attestation which fulfils the issue
You still require 1 signature for the key attestations
OpenID4VCI Issue 473
https://github.com/openid/OpenID4VCI/issues/473
Last WG consensus to move to 1.1, but in this WG meeting consensus that it should land in 1.1, as there’s implementation experience and it’s useful, can solve the different wallet presents and receives credential flow later
This solves it for the traditional OpenID4VP flow (not taking into consideration DC API)
There is an issue with using DC API if the credential should come from another wallet for the OpenID4VP part due to the origin being the wallet rather than the issuer
Focuses on the flow where the same wallet that will receive the credential also presents the OpenID4VP credential
Mirko will create a PR
OpenID4VCI Issue 1
https://github.com/openid/OpenID4VCI/issues/1 
Wallet doesn’t know if it will get the credential 1st or 100th time it calls the deferred credential endpoint
Suggestion to add interval to the deferred credential endpoint
There is already an interval
Notifications would be a replacement of polling and interval
You still want an interval with notifications
For deferred issuance, very likely the issuer has an email, so it could send an email that the credential is ready
Could have some wallet invocation that continues deferred issuance, (e.g. a credential offer)
Issuer knows which wallet it will issue into (and could deeplink into it)
Make interval MUST instead of SHOULD
Suggestion to introduce a new error code, Oliver to leave a comment on the issue
OpenID4VCI Issue 226
https://github.com/openid/OpenID4VCI/issues/226
Deferred credential issuance
Should change the 400 response for issuance_pending error, as it’s not an error while invalid_transaction_id is
Change to 202 for pending_issuance and move it to deferred credential response (not error)
Long discussion on errors in credential response
It refers to 6750, which is about authorization errors, while credential request is about application errors
Can we just remove the references to RFC 6750? Need to check if this has implications
OpenID4VCI Issue 103
https://github.com/openid/openid4vci/issues/103
There is a PR solving issue 145, which removes wallet_issuer so this issue won’t be relevant anymore
OpenID4VCI Issue 468
https://github.com/openid/openid4vci/issues/468 
Path in OpenID4VP is limited to be namespace, claim name and does not allow more nesting
In OpenID4VCI, it would make sense to relax that a bit to allow a more detailed display description for nested objects
Question from Gareth how to exactly map a path to a specific element in a CBOR structure
Proposal to create some well-defined way to express a path for CBOR
Should be careful depending how general you want this to be
Since we are defining a path inside of an already known structure that simplifies things - we just need to define a way based on that
Agreed solving this makes sense
OpenID4VCI issue 461
https://github.com/openid/openid4vci/issues/461
Second argument might not be fully true - there might be self-contained nonces → not necessarily a problem of growing database entries
Comparable with web-session ids
If we add the DPoP nonce to the nonce endpoint, it wouldn’t work since we would need the nonce endpoint to fetch the nonce
Nonce is a bit of a loaded term (and challenge would probably have been better), need to be very explicit about expectations around nonce
Freshness can be defined by the server
There seems to be agreement to not mandate protection of the nonce endpoint
OpenID4VCI issue 205
https://github.com/openid/openid4vci/issues/205
There are 2 layers of images: the issuer and the credential
Allowing data URIs might be a security problem
Limiting options seems to be a good idea from a security perspective
Would help interop, but leaves the question which formats to pick
Just defining a subset right now would cause problems
Seems to be an interop problem and should be moved to HAIP
OpenID4VCI issue 480
https://github.com/openid/OpenID4VCI/issues/480
About the dehydrated cbor structure defined in ISO 23220-3
Solves the same problem as compression
Problem seems to be mainly exist for big payloads like pictures
The biggest debate if this optimization is worthwhile and doing it in the same structure
Question to provide some examples/data points about dehydration vs compression
Seems to be 2 separate problems:
Initial issuance, where compression seems to be a good solution
Batch re-issuance, where the picture would not need to be re-transmitted
Gareth will try to generate some numbers
Mdoc could define its own credential-format specific structure in the credential response
There seems to be a preference to leverage JWE compression since it would solve the problem for all formats
Initial PR: strong recommendation to enable compression for big credentials

 Plan to spend some time on thursday on #339 (enable credential request encryption)

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