<div dir="ltr"><div>Below are my notes from today's meeting. Please feel free to respond with corrections or additions if I have misunderstood or left out anything.</div><div><br></div><div>-Joe</div><div><br></div><div><br></div><div># Connect/AB Minutes for April 17, 2025<br><br>## Attendees<br>Mike Jones, Chair<br>Nat Sakimura, Chair<br>Joe DeCock, Notetaker<br>Aaron Parecki<br>Andy Barlow<br>Dick Hardt<br>Filip Skokan<br>George Fletcher<br>Marcus Almgren<br>Samuel Rinnetmäki<br><br>## Upcoming Events<br>### OpenID Federation Interop, April 28-30, hosted by SUNET in Stockholm<br>- Sign up in the attendee spreadsheet<br>- Run the Federation Certification Tests<br><br>## OpenID Connect Claims Aggregation<br>### <a href="https://bitbucket.org/openid/connect/pull-requests/745">https://bitbucket.org/openid/connect/pull-requests/745</a> Simplified rewrite of Claims Aggregation<br>Nat: This pulls out the VP specific things, making the core simpler.<br>Mike: Will read and either provide feedback or merge quickly.<br>    <br>## OpenID Connect Relying Party Metadata Choices<br>### <a href="https://github.com/openid/rp-metadata-choices/issues/4">https://github.com/openid/rp-metadata-choices/issues/4</a> Missing choice parameters<br>Filip: Did an implementation, noticed that there are parameters that could be added.<br>Mike: Working on a PR for this. Should be done today.<br><br>### <a href="https://github.com/openid/rp-metadata-choices/issues/2">https://github.com/openid/rp-metadata-choices/issues/2</a> Interoperability concerns with older deployments<br>Mike: The issue is that older deployments wouldn't understand the multiple values, so suggestion is to add guidance (not a MUST) to include a single value. <br>Filip: If this is done, guidance is then also needed to ignore the single value for conforming deployments.<br>Mike: Intends to raise a PR for this soon.<br><br>## OpenID Provider Commands<br><a href="https://github.com/openid/openid-provider-commands/issues">https://github.com/openid/openid-provider-commands/issues</a><br></div><div><br></div><div>### Update from Dick<br>    - Did a PR for roles, pushed this morning.<br>    - Did another PR based on Aaron's feedback from old issues.<br>    - Asked about the action item from the last call to email the security team. Contact info for the University of Stuttgart researchers was shared and Dick later sent the email during this call.<br>    - Posted to list ideas around notifications: RP needs a way to notify OP that long-running operations complete asynchronously, and that its metadata has changed, synchronously. New idea is to split notifications: sync vs async.<br>    <br>### Sync vs Async Notifications Discussion<br>George: Raised the concern that async looks similar to and perhaps overlaps with SSF. He suggested that perhaps an SSF profile could describe commands, or perhaps the OP Commands spec could add guidance to describe how to use SSF as the transport. Raised the idea of trying to map commands onto an SSF set.<br>Dick: Responds that the goal is to align commands with an ID Token rather than an SSF set.<br>Aaron: Makes the point that the value of OP commands is that it is lightweight and leverages the existing relationship between OP and RP. He cautions against adding complexity, such as async notifications. Broadening the scope could undermine the value of commands. <br>Dick: Responds that the feedback from implementers has been that they need this. Agrees on the overall goal of simplicity.<br>Aaron: Returns to the larger point, that we need to avoid adding new trust relationships or authentication mechanisms.<br>George and Aaron: Suggest the use of the existing client id and secret.<br>Dick: Notes that some clients aren't confidential. Note requiring a secret can be valuable for ease of use/getting started.<br>George: Suggests that in the interest of simplicity of OP Commands, requiring a confidential client might be the right tradeoff.<br>Mike: Asks that we continue the discussion on the list.<br><br>## OpenID Federation Wallet Architectures<br>### <a href="https://github.com/openid/federation-extended-listing/pull/10">https://github.com/openid/federation-extended-listing/pull/10</a> Editorial pass<br>Mike: Reviews requested. (Mostly editorial, but much text changed.)<br><br>## OpenID Federation<br>### <a href="https://github.com/openid/federation/pull/197">https://github.com/openid/federation/pull/197</a> All claims we list as possible in an Entity Statement should be listed in section 3<br>Mike: Reviews requested, appears to be editorial.<br><br>### <a href="https://github.com/openid/federation/pull/198">https://github.com/openid/federation/pull/198</a> It is specifically the trust_mark_id claims that matters<br>Mike: Reviews requested.<br><br>### <a href="https://github.com/openid/federation/pull/200">https://github.com/openid/federation/pull/200</a> Clarify requirement for exp time in Trust Anchor Entity Configuration<br>Mike: Reviews requested.<br><br>### <a href="https://github.com/openid/federation/issues/194">https://github.com/openid/federation/issues/194</a> Suggest renaming trust_mark_id to better reflect its meaning<br>Mike: Discuss this in person at interop event.<br><br>### <a href="https://github.com/openid/federation/issues/196">https://github.com/openid/federation/issues/196</a> [policy operators] subset_of and essential example table wrong<br>Mike: Asks for Vladimir's input on this issue.<br><br>### <a href="https://github.com/openid/federation/issues/192">https://github.com/openid/federation/issues/192</a> Trust Chain for Trust Anchor?<br>Marcus: Will add clarifying remarks to the conformance test suite.<br><br>### <a href="https://github.com/openid/federation/issues/193">https://github.com/openid/federation/issues/193</a> Concerns around the practicality of the requirement for an empty json object on present entity type identifiers<br>Mike: Discuss this in person at interop event.<br><br></div></div>