<div dir="ltr"><div>
<p class="MsoNormal"></p><p class="MsoNormal"># Connect/AB Minutes for April 3, 2025</p>
</div>
<p class="MsoNormal"><span class="gmail-im"><br>
## Attendees<br>
Michael Jones, Chair<br></span>
Nat Sakimura, Chair<span class="gmail-im"><br>
Joe DeCock, Notetaker<br>
Aaron Parecki<br>
Andy Barlow<br>
Brian Campbell<br>
Chris Phillips<br>
Daniel Fett<br>
Dick Hardt<br>
Filip Skokan<br>
Joseph Heenan<u></u><u></u></span></p>
<p class="MsoNormal">Łukasz Jaromin<u></u><u></u></p>
<p class="MsoNormal">Marcus Almgren<br>
Samuel Rinnetmäki<u></u><u></u></p>
<p class="MsoNormal"><span class="gmail-im">Stefan Santesson<br>
Tim Cappalli<br>
<br>
## Events<br>
### OpenID Workshop and IIW, Apr 7-10, Mountain View, California<br>
- <a href="https://internetidentityworkshop.com/" target="_blank">https://internetidentityworkshop.com/</a><br>
- <a href="https://openid.net/attend-the-oidf-workshop-prior-to-iiw-spring-2025-on-7th-april-2025/" target="_blank">
https://openid.net/attend-the-oidf-workshop-prior-to-iiw-spring-2025-on-7th-april-2025/</a><br>
### OpenID Federation Interop, April 28-30, hosted by SUNET in Stockholm<br>
- Sign up in the attendee spreadsheet: <a href="https://docs.google.com/spreadsheets/d/1zYl-wdzgyol9u3ho342GZhSsg0hhqqneJHlMXWJSIw0/edit?gid=25633585#gid=25633585" target="_blank">
https://docs.google.com/spreadsheets/d/1zYl-wdzgyol9u3ho342GZhSsg0hhqqneJHlMXWJSIw0/edit?gid=25633585#gid=25633585</a><br>
- Run the Federation Certification Tests: <a href="https://openid.net/certification/federation_testing/" target="_blank">
https://openid.net/certification/federation_testing/</a><br>
<br>
## Coordination between DCP and Connect WGs on Client ID Values<br>
### Background<br>
- OpenID4VP's Client IDs and OpenID Federation's Client IDs are currently compatible<br>
- An OpenID4VP PR has proposed prefixing OpenID Federation Client ID
values, which would be a breaking change to OpenID Federation<br>
- An OpenID4VP PR-on-that-PR has proposed making the prefix optional, which would make it a non-breaking change<br>
- Joseph Heenan filed an OpenID Federation issue discussing the situation and possible choices<br>
- Chairs wanted to coordinate across the working groups to prevent incompatibility<br>
### Discussion<br>
- Brian: Original PR is aiming for consistency within OpenID4VP, and has
exceptions for this use case. He raises process concerns.<br></span>
- Joseph: Goal is consistency across OpenID's various specifications.<br>
- Aaron: Asks a layering question: What are the dependencies between
Connect, Federation, and OpenID4VP? Is it the case that VP has the most
dependencies?<span class="gmail-im"><br>
- Daniel: VP and Federation are siblings.<br>
- Brian: That's true, but there is a complex relationship between VP and Federation.<br></span>
- 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.<br>
- Daniel: Agree, other specs might run into the same thing, specs should be internally consistent.<span class="gmail-im"><br>
- 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.
<br></span>
- 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.<br>
- Daniel Fett: Problem comes from multiple specs having different needs, and this will be a recurring problem.<br>
- 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.<br>
- Brian: https is unambiguous only within Federation. In real deployments, it is not.<br>
- Łukasz: We should avoid making client identifiers deployment-specific. Aaron's PR helps with that.
<br>
- Dick: Client IDs having implied meaning is contrary to the original OAuth spec.<br>
- Aaron: OAuth 2.1 updates the Client ID definition.<br>
- 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.<br>
- 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.<br>
- 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.<br>
- 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.<br>
- Joseph: What should Federation do? Do we want to change to make Federation's Client IDs unambiguous?<br>
- Mike: They already are unambiguous. The problem is that differing
syntax between the workgroups would mean that the Client ID is
confusing.<br>
- Aaron: Wallets and Federation are very separate, users of the two specs are separate, so there's not much risk of confusion.<br>
- Mike: No, you can use Federation for trust establishment, e.g., the Italian deployment uses them together.<br>
- Dick: Reiterates that Client IDs were originally opaque.<br>
- 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 ...<br>
<br>
Here the meeting's Zoom call ended abruptly for unknown reasons.</p><br></div>