[Openid-dcp] DCP Working Group Call 29-May-25
Michael Jones
michael_b_jones at hotmail.com
Thu May 29 16:14:54 UTC 2025
DCP Working Group Call 29-May-25
Christian Bormann
Joseph Heenan
Mike Jones
Kristina Yasuda
Brian Campbell
Gareth Oliver
Lee Campbell
John Bradley
Oriol Canadéz Díez
Tim Cappalli
Peter Sorotokin
Jan Vereecken
Rajvardhan Deshmukh
Filip Skokan
OpenID4VP #598 - Implement signature verification requirements
Waiting for feedback from Martijn
OpenID4VP #597 - Add encryption details parameter
Christian - It's odd that we would be defining profiles but not using them
Gareth - Made a remark about defining a default profile
Joseph - Are we actually defining a profile here, or is HAIP the profile?
Kristina - Commented that when using mDOCs, she would use mDOC values
Joseph - We do need a name. What should we call it?
Mike - Is this for 1.0, which is in final review, or for 1.1?
Kristina - 1.0
Brian in the chat - We should not define a non-interoperable extension point for a problem we don't have
Kristina - Wrote a comment in the PR about apu and apv values
Joseph - Summarized that there's a desire in the future to be able to encrypt in different ways
It would let implementations indicate profiles to be used in the future
There isn't wallet metadata at the time the request is being made
Kristina - This is for fine-tuning how to use JWE
John - What the receiver supports needs to be known to the sender
Lee - Why are we doing this at all? Why not just define it?
Does anyone need the additional profiling?
This seems to lead to more fragmentation
John - You're recommending fully-specified encryption schemes
Lee - Is this really about apu and apv values or is there more to it than that?
Christian - Some people are asking for the detached mode
This is a way to indicate things like that
Brian - There are breaking changes caused by the extension point and varying levels of support
Encryption already works
Lee - This feels messy - we'd have to carry this burden forever
Why not figure this out in advance
Kristina - Lee and Brian, please make comments in the PR
OpenID4VP #610 - Add session transcription for redirect-based flow
Gareth - Are we intending to never support it?
Gareth - The use case for multi-RPs is understood
It would be good to clarify the expectation
Christian - Our security architecture relies on Client ID
I would be reluctant to remove it at the last minute
John - The trust framework needs to be able to support a single identifier belonging to multiple trust frameworks
Multi-RP may be trying to solve the problem the wrong way
Joseph - I think we don't have a solution
Kristina - Asked for volunteers for a related Implementation Considerations PR
Gareth volunteered
Kristina - Asked for objections to merging
Someone pointed out that ISO was asked to review
We should give them at least a day to do so
Joseph - We got objections about the same Client ID thing
Gareth - That was me
It may have also been Martijn
Kristina - Please re-review
Otherwise, Kristina plans to merge tomorrow night
OpenID4VP #615 - Transaction data hashes
Joseph - There is a potential interop issue
Kristina - There are questions about doing the hash over base64url-decoded data
Kristina - This hasn't been discussed on a WG call
People may need more time to look at the issue
OpenID4VP #509 - Privacy Considerations
Kristina - Nat added content
Lee - I can go through this offline
OpenID4VCI
We don't have any issues that are awaiting PRs
OpenID4VCI #527 - .well-known syntax
Joseph - Proposes changing from Connect syntax to IETF syntax
Christian - I don't think we have much of a choice
John - This is unfortunate, but probably inevitable
Having two ways to do it is worse
The keep-off-my-lawn advocates are clear
Kristina - I don't hear objections for moving in this direction
Christian - We should probably wait a week
Kristina - No, because we're coming up to WGLC, we're not waiting a week
Once we have enough approvals, we're golden
OpenID4VCI #522 - Integrity of JWK used for Credential Response encryption
Christian - Would be good to have someone familiar with LDP review
Kristina - We investigated multiple options
Decided to have an extra parameter to carry the encryption key
Decided not to bind it to the use of DPoP
Lee - Why do we need this at all?
We're already using TLS. What are we worried about?
Gareth - Prevents decryption by TLS middle parties
Kristina - Are onboard with this approach or do we want to consider the DPoP approach?
Gareth - Having to define how to provide a key for every proof type is problematic
There's an elegance to doing whole request signing
Then it's just a question of how to choose the signing key
Christian - We don't have a key that is mandatory for the wallet
John - You can only have integrity-protected encryption if you sign the request
Gareth - Friction caused by differences are problematic
We plan to go the DPoP route
John - The best practice would be to integrity protect the credential request
I don't think we've properly thought through all the things in a request that would be useful to attackers
Integrity protecting the request is a natural complement to encrypting the response
Kristina - I've been trying to avoid coupling features
John - I think it's reasonable to tie these together
If the attacker can change the encryption key in the request, we haven't achieved anything
Having an integrity-protected request is reasonable
Christian - Do we need a second PR?
We have two options - Wallet attestation and DPoP
John - Those are the only two keys I'm aware of
Christian - We would need a way to signal which to use
John - The attestation key may not be a key that the wallet has access to
The key that the attestation is over is available to the wallet
Kristina - We need more discussion on this
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250529/41554c02/attachment-0001.htm>
More information about the Openid-specs-digital-credentials-protocols
mailing list