[Openid-specs-ab] Meeting Minutes for April 3rd

Sun Apr 6 15:21:47 UTC 2025

Yup. That was the case. I tried to reopen the bridge but that meant the
othe WG will be ended. Something to be looked at.

2025年4月5日(土) 2:10 Brian Campbell via Openid-specs-ab <
openid-specs-ab at lists.openid.net>:

> FWIW my understanding is that the meeting ended abruptly due to the start
> of a different WG's meeting and how the OIDF zoom account is set up.
>
> On Fri, Apr 4, 2025 at 11:05 AM Samuel Rinnetmäki via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>>
>>
>> Hi,
>>
>>
>>
>> IMHO, the discussion on Thursday’s meeting was great.
>>
>>
>>
>> I think all views were well reasoned and I found it easy to relate with
>> all viewpoints. Everyone was “right” and it’s understandable that the
>> discussion may end up being a little emotional. (I’m not encouraging ad
>> hominem attacks or unpolite behaviour, but I understand that it’s sometimes
>> hard to keep calm when you deeply care about the subject.)
>>
>>
>>
>> At the end of the meeting, I raised my hand, but the meeting ended before
>> I got a chance to speak. I would have liked to state that while I see value
>> in Mike’s wish to keep the same syntax of client identifiers across the
>> specs, having both prefixed and non-prefixed identifiers in OID4VP hurts
>> developer experience more than having identifiers prefixed in OID4VP and
>> non-prefixed in OpenID Federation. (OpenID Federation doesn’t need
>> prefixes, OID4VP does. If some identifiers are prefixed in a spec, they all
>> should be.)
>>
>>
>>
>> For that reason, I gave a thumbs-up to Aaron’s proposal scribed by
>> Kristina in the issue 401 of the OID4VP spec (
>> https://github.com/openid/OpenID4VP/pull/401#issuecomment-2776912290).
>>
>>
>>
>>                 Samuel
>>
>>
>>
>> *Samuel Rinnetmäki*
>>
>> CTO
>>
>> Findynet Cooperative
>>
>>
>>
>>
>>
>>
>>
>> *From: *Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on
>> behalf of Joe DeCock via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net>
>> *Date: *Thursday, 3. April 2025 at 19.30
>> *To: *openid-specs-ab at lists.openid.net <openid-specs-ab at lists.openid.net>
>> *Cc: *Joe DeCock <joe at duendesoftware.com>
>> *Subject: *[Openid-specs-ab] Meeting Minutes for April 3rd
>>
>> # Connect/AB Minutes for April 3, 2025
>>
>>
>> ## Attendees
>> Michael Jones, Chair
>> Nat Sakimura, Chair
>> Joe DeCock, Notetaker
>> Aaron Parecki
>> Andy Barlow
>> Brian Campbell
>> Chris Phillips
>> Daniel Fett
>> Dick Hardt
>> Filip Skokan
>> Joseph Heenan
>>
>> Łukasz Jaromin
>>
>> Marcus Almgren
>> Samuel Rinnetmäki
>>
>> Stefan Santesson
>> Tim Cappalli
>>
>> ## Events
>> ### OpenID Workshop and IIW, Apr 7-10, Mountain View, California
>>   - https://internetidentityworkshop.com/
>>   -
>> https://openid.net/attend-the-oidf-workshop-prior-to-iiw-spring-2025-on-7th-april-2025/
>> ### OpenID Federation Interop, April 28-30, hosted by SUNET in Stockholm
>>   - Sign up in the attendee spreadsheet:
>> https://docs.google.com/spreadsheets/d/1zYl-wdzgyol9u3ho342GZhSsg0hhqqneJHlMXWJSIw0/edit?gid=25633585#gid=25633585
>>   - Run the Federation Certification Tests:
>> https://openid.net/certification/federation_testing/
>>
>> ## Coordination between DCP and Connect WGs on Client ID Values
>> ### Background
>> - OpenID4VP's Client IDs and OpenID Federation's Client IDs are currently
>> compatible
>> - An OpenID4VP PR has proposed prefixing OpenID Federation Client ID
>> values, which would be a breaking change to OpenID Federation
>> - An OpenID4VP PR-on-that-PR has proposed making the prefix optional,
>> which would make it a non-breaking change
>> - Joseph Heenan filed an OpenID Federation issue discussing the situation
>> and possible choices
>> - Chairs wanted to coordinate across the working groups to prevent
>> incompatibility
>> ### Discussion
>> - Brian: Original PR is aiming for consistency within OpenID4VP, and has
>> exceptions for this use case. He raises process concerns.
>> - Joseph: Goal is consistency across OpenID's various specifications.
>> - Aaron: Asks a layering question: What are the dependencies between
>> Connect, Federation, and OpenID4VP? Is it the case that VP has the most
>> dependencies?
>> - Daniel: VP and Federation are siblings.
>> - Brian: That's true, but there is a complex relationship between VP and
>> Federation.
>> - Aaron: In that case, VP should be consistent within itself. Non-VP
>> usage shouldn't break if VP changes internally, and so he intends to
>> retract his PR.
>> - Daniel: Agree, other specs might run into the same thing, specs should
>> be internally consistent.
>> - Mike: Goal is that you should be able to use VP and Federation
>> together. Data structures are shared across working groups, so coordination
>> is warranted.
>> - Mike: Also very important to define Client IDs unambiguously. Brian's
>> PR makes the Client IDs ambiguous. Aaron's PR makes the Client IDs
>> unambiguous. Asks Aaron to not withdraw his PR.
>> - Daniel Fett: Problem comes from multiple specs having different needs,
>> and this will be a recurring problem.
>> - Joseph: In real world, https can mean different things. Https probably
>> is not going to be reserved by OAuth for Federation, so they're going to be
>> ambiguous.
>> - Brian: https is unambiguous only within Federation. In real
>> deployments, it is not.
>> - Łukasz: We should avoid making client identifiers deployment-specific.
>> Aaron's PR helps with that.
>> - Dick: Client IDs having implied meaning is contrary to the original
>> OAuth spec.
>> - Aaron: OAuth 2.1 updates the Client ID definition.
>> - Mike: "In the real world" should not constrain us. In fact it's the
>> other way around - our standards exist to constrain what people do. Things
>> should be unambiguous *when people use our standards*. That's the purpose
>> of standards. If you follow the specs, you get unambiguous Client IDs.
>> - Mike: OAuth leaves Client ID semantics up to profiles, and the profiles
>> can make some treatment of Client IDs and still be compatible. But
>> different Client ID syntax for different contexts will lead to developers
>> making mistakes and would be a failure on our part.
>> - Aaron: Has a proposal that doesn't agree with Mike's assessment:
>> Require prefix in VP, and define Client IDs in Federation as using https.
>> The inconsistency doesn't seem like a big deal, doesn't agree that it is a
>> failure that they are different.
>> - Stefan and Aaron: Root of the problem is, how do you find metadata?
>> Ambiguity means that there's more than 1 way to get the metadata.
>> - Joseph: What should Federation do? Do we want to change to make
>> Federation's Client IDs unambiguous?
>> - Mike: They already are unambiguous. The problem is that differing
>> syntax between the workgroups would mean that the Client ID is confusing.
>> - Aaron: Wallets and Federation are very separate, users of the two specs
>> are separate, so there's not much risk of confusion.
>> - Mike: No, you can use Federation for trust establishment, e.g., the
>> Italian deployment uses them together.
>> - Dick: Reiterates that Client IDs were originally opaque.
>> - Brian: Supports Aaron's proposal, and if we want consistency in
>> Federation, then Federation might need to change, but he has not suggested
>> that because ...
>>
>> Here the meeting's Zoom call ended abruptly for unknown reasons.
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> 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/20250407/89d04979/attachment.htm>