[Openid-specs-ab] Call for Working Group Adoption of OpenID Federation Wallet Architectures 1.0

Wed Aug 14 22:26:01 UTC 2024

Hi Torsten, below some points for clarity

Il giorno mar 13 ago 2024 alle ore 18:18 Torsten Lodderstedt via
Openid-specs-ab <openid-specs-ab at lists.openid.net> ha scritto:

>
> Having a write up is very useful. However, I think a whitepaper or blog
> post would be the appropriate format for that.
>

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:

https://github.com/italia/eudi-wallet-it-docs

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.

>
> Writing a spec to allow for interoperability is something different. It
> requires discussions with other implementers to find a common ground,
>

I fully agree with you, we're on the same page in this.

>
> 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.
>
>
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.

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

client metadata including redirect_uris and request_uris  sanification and
presentation_definition
https://github.com/openid/OpenID4VP/issues/17#issuecomment-1702545425

presentation_definitions_supported
https://github.com/openid/OpenID4VP/issues/189

openid4vci metadata jwks
<goog_1397075857>https://github.com/openid/OpenID4VCI/issues/324

openid federation generals in HAIP
https://github.com/openid/oid4vc-haip-sd-jwt-vc/issues?q=is%3Aissue+is%3Aopen+federation

but more specific its call to implementation in HAIP, here
<goog_1397075869>https://github.com/openid/oid4vc-haip-sd-jwt-vc/issues/88

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.

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.

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.

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.
>

We suppose that the wallet provider can only issues attestations of
complaince to the wallet instances belonging to it.
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.
This opportunity may arise from real-world market dynamics, extending
beyond the current and temporary limitations we might perceive.

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.

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.

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.

best regards,
> Torsten.
>

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.

See you in the DCP Call after the 28 August, I really hope to stop missing
dcp calls.

>
>
>
>
> 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.
>
>
>
> Joseph helpfully provided specifics on what metadata values he would
> suggest moving to other specifications and other clarifications that could
> be applied in his message
> <https://lists.openid.net/pipermail/openid-specs-ab/2024-August/010370.html>
> before the Thursday, August 8th call.  We discussed that additional
> feedback on that call, as recorded in the notes
> <https://lists.openid.net/pipermail/openid-specs-ab/2024-August/010371.html>.
> 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.
>
>
>
> 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.
>
>
>
> Kristina wrote: “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.”
> 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.
>
>
>
> 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.)
>
>
>
> Thanks all for your attention to these important topics!
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> *On
> Behalf Of* Joseph Heenan via Openid-specs-ab
> *Sent:* Friday, August 9, 2024 1:00 PM
> *To:* Artifact Binding/Connect Working Group <
> openid-specs-ab at lists.openid.net>
> *Cc:* Joseph Heenan <joseph at authlete.com>
> *Subject:* Re: [Openid-specs-ab] Call for Working Group Adoption of
> OpenID Federation Wallet Architectures 1.0
>
>
>
> Hi all
>
>
>
> Thanks Kristina!
>
>
>
> Just to reply to a specific point:
>
>
>
> On 9 Aug 2024, at 13:14, Kristina Yasuda via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>
>
> 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.
>
>
>
> 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
> https://lists.openid.net/pipermail/openid-specs-ab/2024-August/010371.html and
> I’m pleased to see that Giuseppe plans to look into them.
>
>
>
> Thanks
>
>
>
> Joseph
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240815/c319f14e/attachment-0001.html>