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

[Joe DeCock]

# 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250403/9ee465a9/attachment.htm>