<div dir="ltr"><div dir="ltr">Hi Torsten, below some points for clarity<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mar 13 ago 2024 alle ore 18:18 Torsten Lodderstedt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> ha scritto:<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 name="messageReplySection"><br><div>Having a write up is very useful. However, I think a whitepaper or blog post would be the appropriate format for that.</div></div></div></blockquote><div><br></div><div>I don't want to confuse communication strategies with technical solutions and specifications, which was published, and very often updated, in a public repository which I suppose is already known to our community. The link is the following one:<br><a href="https://github.com/italia/eudi-wallet-it-docs"><br>https://github.com/italia/eudi-wallet-it-docs</a></div><br>The scope of the draft extends beyond the Italian implementation profile, aiming to clarify the use of OpenID Federation in wallet architectures. This draft is designed to provide guidance to a global audience, significantly surpassing the focus of the Italian solution.<div> </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 name="messageReplySection">
<div dir="auto"><br></div>
<div dir="auto">Writing a spec to allow for interoperability is something different. It requires discussions with other implementers to find a common ground,</div></div></div></blockquote><div><br></div><div>I fully agree with you, we're on the same page in this.<br></div><div> </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 name="messageReplySection">
<div dir="auto"><br></div>
<div dir="auto">This draft defines extensions to the OID4VP and OID4VCI spec, something I would feel more comfortable with in the DCP WG simply because that’s were expertise and implementers of OID4VC are. Also, some of the proposed extensions were proposed to the DCP WG already but haven’t been adopted (yet). So it feels like this draft tries to create facts without a WG discussion.<br><br></div></div></div></blockquote><div> </div><div>I suggest creating a GitHub label to group all issues related to trust and policy evaluations, even those not directly linked with OpenID Federation. This will help us filter them from the list of open issues and focus on addressing all matters concerning trust and policy evaluation mechanisms, as well as their connections to the draft under discussion.<br><br></div><div>Below I can bring a non exaustive list of discussion already happend in the DCP WG, apologies for the incompleteness cause by my current holiday situation<br><br>client metadata including redirect_uris and request_uris sanification and presentation_definition<br><a href="https://github.com/openid/OpenID4VP/issues/17#issuecomment-1702545425"><span>https://github.com/openid/OpenID4VP/issues/17#issuecomment-1702545425</span></a></div><div><br></div><div>presentation_definitions_supported<br><span><a href="https://github.com/openid/OpenID4VP/issues/189">https://github.com/openid/OpenID4VP/issues/189</a></span></div><div><br><span></span></div><div><span>openid4vci metadata jwks<a href="goog_1397075857"><br></a></span><a href="https://github.com/openid/OpenID4VCI/issues/324"><span>https://github.com/openid/OpenID4VCI/issues/324</span></a></div><div><br></div><div>openid federation generals in HAIP<br><a href="https://github.com/openid/oid4vc-haip-sd-jwt-vc/issues?q=is%3Aissue+is%3Aopen+federation"><span>https://github.com/openid/oid4vc-haip-sd-jwt-vc/issues?q=is%3Aissue+is%3Aopen+federation<br><br></span></a></div><div><span>but more specific its call to implementation in HAIP, here<a href="goog_1397075869"><br></a></span><a href="https://github.com/openid/oid4vc-haip-sd-jwt-vc/issues/88">https://github.com/openid/oid4vc-haip-sd-jwt-vc/issues/88<br><br></a></div>Given that many of these issues have been open for over a year, I assumed that I had already initiated a discussion about the requirements and proposed solutions for them, but honestly I admit that I was not able to attend to the DCP WG call during the previous 3 or 4 months due to other, ineludible, priorities for which I feel the need to present my sincere apologies. <br><br>However, I am aware that I may have missed some, as the substantial number of open issues in the openid4vc specs makes it challenging to track them all. This presents a valuable opportunity for us to summarize and address these issues in line with the conversation started by the OpenID Federation Wallet Architecture draft. <br><br>I feel on myself the task to open separate issues in the openid federation wallet architecure repository, to link all the openid4vc issues and coversations (even provided through the mailing list) as already promised to Joseph and Mike. At the same time I hope that this work, exquisitely library-related, does not slow us down but only helps to consolidate the retrospective that we want to achieve and in support of our work.<br><div><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 name="messageReplySection"><div dir="auto"></div>
<div dir="auto">Content wise, I‘m wondering why the specification includes a token endpoint for the wallet provider. It seems it is used to issue wallet attestations. I think wallet instance to wallet provider communication is not related to interoperability, the design should be left at the wallet provider’s discretion.</div>
</div></div></blockquote><div><br>We suppose that the wallet provider can only issues attestations of complaince to the wallet instances belonging to it.<br></div><div>In the brand new world that is coming with the Wallet ecosystems, there might be more complex scenario where a wallet instance attestation might be issued through a neutral attestation service.<br>This opportunity may arise from real-world market dynamics, extending beyond the current and temporary limitations we might perceive.<br><br></div><div>This opens several challenges, since it requires a clear guidance about the interoperability. There might be wallet providers using propertary flows with their wallet instances, at the same time there might be other situations where interoperability (and security) requires a common standard.<br><br>To simplify, I would address this point by focusing on the needs of our implementers who rely on technical specifications to implement solutions comfortably. The advantage of using OAuth 2.0 or the OpenID Frameworks is that they significantly reduce implementation costs. Our specifications should aim to meet these needs and address these questions.<br><br>We could continue this work in a dedicated draft concerning wallet authorization servers. The scope of this draft would be how to authorize a wallet performing its operations in accordance with a framework, providing proof of its compliance (token, thus wallet attestation). This could introduce several architectural points of interest for technical implementations and also for the market. This would remark the need to reduce the content in the openid federation wallet architecture by referencing other openid4vc specifications. <br></div><div><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 name="messageReplySection"><div dir="auto"></div>
<div dir="auto">best regards,</div>
<div dir="auto">Torsten.</div>
</div></div></blockquote><div><br></div><div>thank you as usual, I want to say that in my sparse replies I try to answer to more than the single email I reply to, therefore I hope that this reply represents an alternative summary, adddressing also other emails and points raised during this call of adoption.<br><br></div><div>See you in the DCP Call after the 28 August, I really hope to stop missing dcp calls.<br></div><div> </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 name="messageReplySection"><div dir="auto"></div>
<blockquote type="cite" style="border-left:thin solid rgb(26,188,156);margin:5px;padding-left:10px">
<div>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt"><br></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><br></span></p>
<p class="MsoNormal"><span style="font-size:11pt">People on the call also expressed agreement with Joseph’s written feedback that metadata values that are in the contributed draft that are more generally applicable should be moved to the appropriate OpenID4VC specs and then deleted from the Federation Wallet spec. But no one on the call expressed the opinion that having written them down in the contributed spec before their inclusion in other specifications should block consideration of adopting the contribution as-is now. The call was well attended, with 14 people participating, and no one expressed reservations with starting the call for adoption.</span><br></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Joseph helpfully provided specifics on what metadata values he would suggest moving to other specifications and other clarifications that could be applied in <a href="https://lists.openid.net/pipermail/openid-specs-ab/2024-August/010370.html" target="_blank">his message</a> before the Thursday, August 8<sup>th</sup> call. We discussed that additional feedback on that call, as recorded in <a href="https://lists.openid.net/pipermail/openid-specs-ab/2024-August/010371.html" target="_blank">the notes</a>. Giuseppe took the action item to reply to the call for adoption enumerating the existing OpenID4VC issues about the metadata values currently specified in the Federation Wallet contribution, which if resolved, would result in them being added to the appropriate places in the OpenID4VC specs. And he agreed to file new OpenID4VC issues to fill any gaps identified in what it would take to define these metadata values there.</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">I agree with Joseph that future versions of the spec should be clearer about what is new normative text and what is repeating already normative text in other specifications.</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Kristina wrote: “</span>Please do not adopt this draft until all the changes that define OpenID4VP or OpenID4VCI parameters that are not currently defined in those specs right now are removed from this document.<span style="font-size:11pt">” Speaking as an individual, this is a point where reasonable people can and do hold different positions. Having them written down now for interoperability purposes is useful. Moving the definitions of them to other specifications where they are also applicable would be good. There’s agreement on that. But whether adoption of the spec containing their current descriptions should be blocked by not having first incorporated them into other specifications – a process that could take a while – is a fair question.</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Finally, I’ll observe that using Federation for trust establishment in wallet ecosystems (the purpose of the draft) necessary involves topics pertinent to both the Connect and DCP working groups, so coordination and collaboration will be required. The good news is that that practical coordination happens by having individuals active in both working groups do so, and there are numerous individuals active in both. (For what it’s worth, developing important specifications in coordination across multiple working groups and organizations isn’t new for the OpenID Foundation. Developing OpenID Connect involved participants working together in all of the Connect, OAuth, and JOSE working groups.)</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Thanks all for your attention to these important topics!</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt"> -- Mike</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) currentcolor currentcolor;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:"Calibri",sans-serif">From:</span></b> <span style="font-size:11pt;font-family:"Calibri",sans-serif">Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>> <b>On Behalf Of</b> Joseph Heenan via Openid-specs-ab<br>
<b>Sent:</b> Friday, August 9, 2024 1:00 PM<br>
<b>To:</b> Artifact Binding/Connect Working Group <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
<b>Cc:</b> Joseph Heenan <<a href="mailto:joseph@authlete.com" target="_blank">joseph@authlete.com</a>><br>
<b>Subject:</b> Re: [Openid-specs-ab] Call for Working Group Adoption of OpenID Federation Wallet Architectures 1.0</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Hi all</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Thanks Kristina!</p>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Just to reply to a specific point:</p>
</div>
<div>
<p class="MsoNormal"><br>
<br></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">On 9 Aug 2024, at 13:14, Kristina Yasuda via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:</p>
</div>
</blockquote>
<p class="MsoNormal"><br>
<br></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<div>
<p class="MsoNormal">Moreover, in the minutes of a Connect WG call that happened after Joseph's email with not supporting adoption say "[Openid-specs-ab] Call for Working Group Adoption of OpenID Federation Extended Subordinate Listing 1.0 All respondents so far support adoption", which could have been an oversight, but please be precise.</p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">There’s unfortunately two different calls for adoption for Federation extensions right now which I think has caused confusion - I’m happy that my feedback was correctly record in yesterday’s minutes at <a href="https://lists.openid.net/pipermail/openid-specs-ab/2024-August/010371.html" target="_blank">https://lists.openid.net/pipermail/openid-specs-ab/2024-August/010371.html</a> and I’m pleased to see that Giuseppe plans to look into them.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Thanks</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Joseph</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></blockquote>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div></div>