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

[Brian Campbell]

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._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250404/7267e85d/attachment.htm>