[Openid-specs-ab] Call for Working Group Adoption of OpenID Federation Wallet Architectures 1.0
torsten at lodderstedt.net
torsten at lodderstedt.net
Tue Aug 13 16:18:28 UTC 2024
Hi,
Am 10. Aug. 2024, 23:47 +0200 schrieb Michael Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net>:
Hi all,
I don’t support adoption of this document in the Connect WG.
<cut>
The gist of the discussion then was that the spec records what the Italian wallet deployment is actually doing and so it is useful to have these things written down now to enable interoperable implementations of them (which did make it into the notes).
Having a write up is very useful. However, I think a whitepaper or blog post would be the appropriate format for that.
Writing a spec to allow for interoperability is something different. It requires discussions with other implementers to find a common ground, which brings me to my next point.
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.
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.
best regards,
Torsten.
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 before the Thursday, August 8th call. We discussed that additional feedback on that call, as recorded in the notes. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20240813/977b0a3d/attachment.html>
More information about the Openid-specs-ab
mailing list