<div dir="ltr">Hi All,<br><div>It was mentioned at the end of yesterday's call, but tomorrow's DCP WG call (Th, Feb 20th), none of the co-chairs are available to chair, so we have asked Christian to chair. He has graciously agree for which we are super thankful. We have coordinated the agenda with Christian, which will be sent out soon (the goal would be to conclude the discussion on issue 395 and PR 308 that we have started on Tue).</div><div>Best,</div><div>Kristina</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2025 at 4:38 PM Christian Bormann via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div lang="en-DE"><div><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Hi all,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Below are the notes for </span><span lang="EN-US" style="font-family:Calibri,sans-serif">this yesterday’s APAC DCP WG call</span><span style="font-family:Calibri,sans-serif">.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Best Regards,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Christian<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">----<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Participants:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Andres Olave<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Bjorn Hjelm<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Brian Campbell<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Christian Bormann<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Daniel Fett<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">David Zeuthen<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Dima Postnikov<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Elizabeth Garber<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Gail Hodges<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Gareth Oliver<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">George Fletcher<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Hicham Lozi<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Kristina Yasuda<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Lukasz Jaromin<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Martijn<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Michael Jones<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Oliver Terbu<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Rajvardhan Deshmukh<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Ryan Galluzzo<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Steve Venema<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Tim Cappalli<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Tobias Looker<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Torsten Lodderstedt<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">----<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Events/External orgs:</span><span lang="EN-US" style="font-family:Calibri,sans-serif"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">- Contract with Stuttgart University for Security Analysis is in place<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">- Remote Interop Prep<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">- OID4VP Tests were released<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">- EC agreed to have a meeting on conformance testing<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">- EC inquiry as basis for official recognition of OpenID4VP and OpenID4VCI<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">- Hybrid meeting before OSW<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">- CSC<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">----<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif"><a href="https://github.com/openid/OpenID4VP/issues/395" target="_blank">https://github.com/openid/OpenID4VP/issues/395</a></span><span lang="EN-US" style="font-family:Calibri,sans-serif"> -</span><span style="font-family:Calibri,sans-serif"> Clarify that signed requests for DC API should be rejected if the signature can't be verfied</span><span lang="EN-US" style="font-family:Calibri,sans-serif">:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Torsten explains the discussion that started with clarifying that the wallet should abandon a request if it cannot verify a request signature and moved on to discussion on downgrading. Torsten states his opinion that a RP does not randomly sign a request, but should know if the Request should be signed or unsigned in advance. He asks for opinions from the working group. Christian states that he thinks we need one way for a flow to allow both unsigned and signed options and the main question is whether that is</span><span style="font-family:Calibri,sans-serif"> <span lang="EN-US">explicitly</span></span><span style="font-family:Calibri,sans-serif"> signaled by the RP or a downgrade function</span><span lang="EN-US" style="font-family:Calibri,sans-serif"> (and decision) purely</span><span style="font-family:Calibri,sans-serif"> by the wallet.</span><span lang="EN-US" style="font-family:Calibri,sans-serif"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Martijn responds that he thinks </span><span lang="EN-US" style="font-family:Calibri,sans-serif">signed requests are </span><span style="font-family:Calibri,sans-serif">a layer on top and RP Authentication can provide a lot of different information. What an authentication means can be different case by case and Web PKI is something that is already used and should be </span><span lang="EN-US" style="font-family:Calibri,sans-serif">perceived</span><span style="font-family:Calibri,sans-serif"> as a layer below. Martijn continues that the RP has no way to check if the wallet checked the signature correctly, so it is end up to the wallet anyway - it should not be up to a policy of the RP. Torsten responds that it was not about a RP policy, but about a choice of the RP how it is authenticated. Martijn states that </span><span lang="EN-US" style="font-family:Calibri,sans-serif">there might be </span><span style="font-family:Calibri,sans-serif">a small privacy issue if the RP can learn what trust issues the wallet supports. Torsten asks how a RP would deal with a signed (x.509 based) request and the wallet cannot verify the signature.Martijn and David respond that it is out of scope of the specification. David further explains that it should be out of scope of openid4vp, but probably in scope of a profile like HAIP. David continues that there might be ecosystems that require authentication with a specific trust framework, but others might not and would be fine accepting an unsigned request instead. David further explains that it should be in scope of the policy of the wallet - if a Wallet receives a signed request, but doesn't know the root CA, then it would respond normally.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Steve </span><span lang="EN-US" style="font-family:Calibri,sans-serif">comments</span><span style="font-family:Calibri,sans-serif"> that in the case of ecosystems of EUDI, there would be wallets that are not allowed to respond if they do not recognize the RP authentication </span><span lang="EN-US" style="font-family:Calibri,sans-serif">and asks</span><span style="font-family:Calibri,sans-serif"> what would </span><span lang="EN-US" style="font-family:Calibri,sans-serif">that</span><span style="font-family:Calibri,sans-serif"> mean to continue the flow in that context? Hicham states that the web-pki is a core part of the system and if it gets broken</span><span lang="EN-US" style="font-family:Calibri,sans-serif"> other parts of the protocol like origin breaks as well</span><span style="font-family:Calibri,sans-serif"> [ missed some part here]. The RP cannot know everything about the wallet, which means that some parts of the requests are sent arbitrarily to the wallet. Depending on regulation and ecosystem, the wallet might behave differently - it might stop the flow, or it might continue.</span><span style="font-family:Calibri,sans-serif"> </span><span style="font-family:Calibri,sans-serif">Kristina states that she is not convinced that it is a privacy issue that the RP learns which trust frameworks the wallet trusts. From a user perspective, the question would be what the expectation is – </span><span lang="EN-US" style="font-family:Calibri,sans-serif">as </span><span style="font-family:Calibri,sans-serif">a user</span><span lang="EN-US" style="font-family:Calibri,sans-serif">, </span><span style="font-family:Calibri,sans-serif">it would be </span><span lang="EN-US" style="font-family:Calibri,sans-serif">the expectation</span><span style="font-family:Calibri,sans-serif"> that the wallet makes sure that the RP is trusted. Tobias responds that there are going to be ecosystems with different policies, like RP and wallet mandating the check of a trust framework. He agrees that a signed request is an additional layer that loses</span><span lang="EN-US" style="font-family:Calibri,sans-serif"> some</span><span style="font-family:Calibri,sans-serif"> value if the web-pki </span><span lang="EN-US" style="font-family:Calibri,sans-serif">would be</span><span style="font-family:Calibri,sans-serif"> broken - it provides upfront authentication, but at the end it still requires web-pki to hold.</span><span lang="EN-US" style="font-family:Calibri,sans-serif"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Torsten responds that the WG seems to agree that it is up to the wallet policy, but we need to be clear on the client_id and make sure it is dealt with and used properly. Gareth explains that there have been cases where the requirement was to explicitly present the credentials from the wallet even if the RP Auth expired. Gareth explains that it doesn't make sense to him to have the RP opinionated. Torsten asks if the usnigned option protected by web-pki should be explicit by the RP, or it should only be the choice of the wallet to downgrade. Lukasz adds that it should be a policy that is attached to the credential. If authentication of the RP fails, the wallet should reply with an error.</span><span lang="DE" style="font-family:Calibri,sans-serif"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif">Christian states that we need to be careful</span><span lang="EN-US" style="font-family:Calibri,sans-serif"> how we deal</span><span style="font-family:Calibri,sans-serif"> with client_id as it is integral to the security of the protocol. Martijn responds that RP authentication can be used to provide information about the RP and he doesn't agree with the different IDs and it shouldn't be taken as a guarantee - that information might be used differently in different systems. Tobias states that the ID should be seen as the same</span><span style="font-family:Calibri,sans-serif"> <span lang="EN-US">entity</span></span><span style="font-family:Calibri,sans-serif"> identifying itself with different options - a human might do the same and use different ways to identify themselves in different ecosystems. He states that he dislikes the distinction of different client ids for the same entity that just uses different trust ecosystems. Torsten responds that there are two different types of identity - the logical identity (the company, name, etc.) and an identity that is bound to a trust ecosystem. One entity will have different client identifiers due to the different trust ecosystems. Torsten implores that </span><span lang="EN-US" style="font-family:Calibri,sans-serif">the WG</span><span style="font-family:Calibri,sans-serif"> should be careful</span><span lang="EN-US" style="font-family:Calibri,sans-serif"> with</span><span style="font-family:Calibri,sans-serif"> what we do with the client identifiers (like having 2 different client identifiers in a response) and Lukasz agrees.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></span></p><div id="m_-1909284308104141021m_2266618923902792029mail-editor-reference-message-container"><div><div><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0cm 0cm"><p class="MsoNormal" style="margin-bottom:12pt"><b><span style="color:black">From: </span></b><span style="color:black">Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols-bounces@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols-bounces@lists.openid.net</a>> on behalf of torsten--- via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>><br><b>Date: </b>Monday, 17. February 2025 at 18:05<br><b>To: </b>Digital Credentials Protocols List <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>><br><b>Cc: </b><a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a> <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>><br><b>Subject: </b>[Openid-specs-digital-credentials-protocols] [agenda] DCP WG + SIOP call<u></u><u></u></span></p></div><div name="messageBodySection"><div><p class="MsoNormal"><span style="font-family:"Helvetica Neue"">Hi all,</span><br><br>below is the suggested agenda for tomorrow's DCP WG + SIOP call at 9pm CET</p></div><ol start="1" type="1"><li class="MsoNormal">OIDF Antitrust Policy at <a href="http://www.openid.net/antitrust" target="_blank">www.openid.net/antitrust</a> applies</li><li class="MsoNormal">IPR reminder/ Note-taking</li><li class="MsoNormal">Introductions/re-introductions</li><li class="MsoNormal">Agenda bashing/adoption</li><li class="MsoNormal">Events/External orgs</li></ol><ol start="5" type="1"><ol start="1" type="a"><li class="MsoNormal">Hybrid meeting before OSW</li></ol></ol><ol start="6" type="1"><li class="MsoNormal">Issues and Pull Requests</li></ol><div><p class="MsoNormal">I would suggest to focus on the following issue and pull request as they are all related to RP authentication (with or without signatures):<br><br>Wallet behavior if request signature validation fails<br><a href="https://github.com/openid/OpenID4VP/issues/395" target="_blank">https://github.com/openid/OpenID4VP/issues/395</a><br><br>How to request credentials using RP credentials (requiring a signed request) and (in the same request) request credentials based on the web origin. <br><a href="https://github.com/openid/OpenID4VP/pull/308#issuecomment-2611251967" target="_blank">https://github.com/openid/OpenID4VP/pull/308#issuecomment-2611251967</a><br><br>How to determine the client identifier used to calculate the session transcript<br><a href="https://github.com/openid/OpenID4VP/pull/308" target="_blank">https://github.com/openid/OpenID4VP/pull/308</a></p></div></div><div name="messageSignatureSection"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">best regards,  </p><div><p class="MsoNormal">Torsten.</p></div></div></div></div></div></div></div></div>-- <br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
</div></blockquote></div>