[Openid-specs-digital-credentials-protocols] [notes] EU-friendly DCP WG + SIOP call

Sun Sep 8 14:44:23 UTC 2024

Hi,

Below are the notes for the DCP WG cal on 5th of September 2024:

-----

Attendees:

Christian Bormann

Kristina Yasuda

Joseph Heenan

Andreea Prian

Bjorn Hjelm

Brian Campbell

Daniel Fett

David Chadwick

David Waite

Jan Vereecken

Juba Saadi

Judith Kahrer

Lukasz Jaromin

Martijn Haring

Michael Jones

Nemanja Patrnogic

Oliver Terbu

Paul Bastian

Sebastien

Steve Venema

Timo Glastra

-----

Joseph explains the situation around the EU implementing acts that were initially published a month ago and can only mention finalized standards. It is too late to get into this round of implementing acts, but there will be a next round that will be open. Martijn asks about version 1.1 and what happens if the law references 1.1 - would people be still allowed to use 1.0? Kristina clarifies that this was brought up with the commission and further changes after 1.0 are expected. [Joseph will write an email explaining the situation to the mailing list - more details will be in that mail].

Martijn asks about breaking change and brings up the example that presentation exchange has to be implemented right now and if we introduce another query language in 1.1, would it still be mandated to be implemented? Martijn proposes to change the language to something like PEX can be used, but other methods are also allowed. Martijn then also brings up that a lot of OAuth features are referenced and some of them might for example to be applicable when used together with Browser API. So we would need to add exceptions here and he asks if this would be a breaking change? Kristina answers that the Appendixes can overwrite parts of the spec and we already have a precedence for it. Martijn also asks about missing parts for Browser API and if there should be new issues for them and then corresponding PRs or how to deal with them for 1.0? Kristina clarifies that issues/PRs with a small scope would be nice.

Joseph adds that worst case would be to advance the 2.0 timeline and introduce breaking changes. Oliver adds that it would be good to have PEX and the new query language as equal alternatives in 1.1. Andreea adds that it would be good to have some kind of versioning within the protocol. Kristina answers that this topic was discussed and there was the fear of getting it wrong right now and introduce it in 1.1 - if that is missing, implementations could just assume it is version 1.0. Joseph adds that there he has little hope of creating a versioning scheme in the timeline for 1.0.

https://github.com/openid/OpenID4VP/pull/237:

Oliver explains that one of the discussions was the order of validation. He explains his comment (https://github.com/openid/OpenID4VP/pull/237#issuecomment-2331820525) that proposes a validation order with specific instructions to validate [The link explains this pretty in detail - check there]. Oliver asks if people have questions about this. Daniel thanks Oliver for providing this order, but is not convinced that the choice of which mechanism to be used should be given to the wallet. Daniel points out that you could still mess with the request, for example by removing the signature. Oliver answers that this issue already exists today and the verifier does not know which mechanism the wallet used to verify the client_id. If the verifier has different certificates for different ecosystems, this problem would still exist. It could be solved by adding the key used to verify in the response.

Daniel answers that he thinks these are 2 different problems. The first one is where the verifier doesn't know which client_id_scheme was used. The second one is that within some client_id_scheme, there might be a different certificate or key that was used to check something.

The the client_id_scheme in its current form allows you to take a request and remove the signature. The difference between two different x509 certificates might be a problem, but probably much smaller than the first one. We should solve both, but the first one is way bigger. Oliver shows an option to add the key used to verify together with the client_id in the response, for example in the audience. Paul asks if requiring signed requests was discussed. Brian adds that some of the requests using browser API will not be signed and Kristina agrees. 

Daniel restates the problem that we have client_id_scheme and client_id, but only client_id is in certain messages. It might be a solution to change one of the parameters: keep the client_id unchanged for all systems where the wallet supports exactly one client_id_scheme and for other systems that allow more schemes, we could add a "client_id_with_scheme" that is client_id_scheme:client_id. The response with this mechanism would include this in the audience. The nice part would be that if we do not require a key, it would also work for unsigned cases.

Mike adds that the shown attack is not possible with the changes Oliver proposed. Mike also mentions that Oliver could add to the PR the algorithm for evaluating client_id values and describing the special case of the unsigned option. Brian asks about Daniels proposal whether this client_id_with_scheme would be a replacement for client_id and Daniel agrees. Brian asks if it would be fine to require the audience to include the client_id_scheme at the discretion of the verifier. [There was a bit more discussion on this, but there will be a separate call and presentation to clarify]

Kristina mentions that next week is an ETSI/CEN workshop for the European Digital Identity Wallet that might be interesting for people (https://www.etsi.org/events/2353-etsi-cen-workshop).

Regards,

Christian

From: Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols-bounces at lists.openid.net> On Behalf Of Kristina Yasuda via Openid-specs-digital-credentials-protocols
Sent: Thursday, September 5, 2024 5:02 PM
To: Digital Credentials Protocols List <openid-specs-digital-credentials-protocols at lists.openid.net>
Cc: Kristina Yasuda <yasudakristina at gmail.com>
Subject: [Openid-specs-digital-credentials-protocols] [agenda] EU-friendly DCP WG + SIOP call

Hi All,

Below is the suggested agenda for today's DCP WG + SIOP call. It is the same as for Tuesday, with some more focus on other open PRs.

1.	IPR reminder/ Note-taking
2.	Introductions/re-introductions
3.	Agenda bashing/adoption
4.	Events/External orgs
5.	Update from editors/chairs on the EU implementing acts
6.	Update from editors/chairs on proposed items to prioritise & suggested plan for publishing of next revisions of VCI & VP
7.	Update on c_nonce PR:  <https://github.com/openid/OpenID4VCI/pull/381> https://github.com/openid/OpenID4VCI/pull/381
8.	Update on Oliver/Tobias proposal for client_id_scheme security (  <https://github.com/openid/OpenID4VP/issues/124> https://github.com/openid/OpenID4VP/issues/124 )
9.	PRs for enabling non-breaking extensibility ready for review:  <https://github.com/openid/OpenID4VP/pull/240> https://github.com/openid/OpenID4VP/pull/240   <https://github.com/openid/OpenID4VCI/pull/382> https://github.com/openid/OpenID4VCI/pull/382
10.	Other PRs/issues needing reviews/discussions
11.	Issues ready for PRs - who can help please?  <https://github.com/openid/OpenID4VP/issues?q=is%3Aissue+is%3Aopen+label%3Aready-for-PR+label%3Aeditorial+no%3Aassignee> https://github.com/openid/OpenID4VP/issues?q=is%3Aissue+is%3Aopen+label%3Aready-for-PR+label%3Aeditorial+no%3Aassignee
12.	Other Open PRs/Issues

Thank you!

Kristina

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