<div dir="ltr"><div><div style="color:rgb(59,59,59);font-size:12px;line-height:18px;white-space:pre"><div style=""><font face="arial, sans-serif">Attendees:</font></div><div style=""><font face="arial, sans-serif">Mike Jones, Avalur Venkata Monika, Frederik Krogsdal Jacobsen, Chris Phillips, Brian Campbell, Joseph Heenan</font></div><font face="arial, sans-serif"><br></font><div style=""><font face="arial, sans-serif">External events:</font></div><div style=""><ul><li><font face="arial, sans-serif">IETF 123 in Madrid, July 19-25, 2025</font></li><ul><li>Submission deadline is July 7th</li></ul></ul></div><font face="arial, sans-serif"><br></font><div style=""><font face="arial, sans-serif">New working group specification:</font></div><div style=""><ul><li><span style="font-family:arial,sans-serif">OpenID Connect Enterprise Extensions</span></li></ul></div><font face="arial, sans-serif"><br></font><div style=""><font face="arial, sans-serif">RP Metadata Choices:</font></div><div style=""><ul><li><span style="font-family:arial,sans-serif">Review to become an implementer's draft ends in 8 days</span></li><li>Voting will start soon</li></ul></div><font face="arial, sans-serif"><br></font><div style=""><font face="arial, sans-serif">EAP ACR values:</font></div><div style=""><ul><li><span style="font-family:arial,sans-serif">Passed the vote and is now a final specification</span></li><li>It defines two new acr_values for phishing-resistant authentication</li><li>It also defines a new authentication method value indicating that proof-of-possession was used</li></ul></div><font face="arial, sans-serif"><br></font><div style=""><font face="arial, sans-serif">Connect Claims Aggregation:</font></div><div style=""><ul><li><span style="font-family:arial,sans-serif">Was republished, but unclear what next steps are (authors were not present)</span></li></ul></div><font face="arial, sans-serif"><br></font><div style=""><font face="arial, sans-serif">Enterprise Extensions:</font></div><div style=""><ul><li><span style="font-family:arial,sans-serif">Published</span></li><li>Defines "tenant" claim, which is relevant for IPSIE and OP commands</li><li>Next steps might involve integration into OP commands</li></ul></div><font face="arial, sans-serif"><br></font><div style=""><font face="arial, sans-serif">Ephemeral Subject Identifier:</font></div><div style=""><ul><li><span style="font-family:arial,sans-serif">Call for adoption ended today</span></li><li>Nat added some information about motivation and the relation to SAML on the mailing list</li><li>There is a proof in an ISO specification that ephemeral subject identifiers guarantee certain properties</li><li>Nat will add motivation to the spec after adoption</li><li>There was only positive feedback, so it will be adopted</li></ul></div><font face="arial, sans-serif"><br></font><div style=""><font face="arial, sans-serif">Deferred Token Response:</font></div><div style=""><ul><li><span style="font-family:arial,sans-serif">Can be taken off as an active discussion point until further motivation appears on the list</span></li><li>There is ongoing discussion about use cases - let Frederik know if you are interested in participating</li><li>DCP group has stabilized the Deferred Credential Response flow, so it can be used as inspiration</li></ul></div><font face="arial, sans-serif"><br></font><div style=""><font face="arial, sans-serif">OpenID Federation:</font></div><div style=""><ul><li><span style="font-family:arial,sans-serif">Open issues and proposed resolutions were discussed after interop event</span></li></ul></div><font face="arial, sans-serif"><br></font><div style=""><font face="arial, sans-serif">Other business:</font></div><div style=""><ul><li><span style="font-family:arial,sans-serif">Congrats to Aaron for getting some OAuth/OIDC into the new MCP specification.</span></li><ul><li>Link: <a href="https://www.linkedin.com/posts/aaronparecki_modelcontextprotocol-mcp-oauth-activity-7341285511312887808-mRYo">https://www.linkedin.com/posts/aaronparecki_modelcontextprotocol-mcp-oauth-activity-7341285511312887808-mRYo</a></li></ul><li>Question on OpenID Federation: what is issue #100 about?</li><ul><li>Researchers at University of Stuttgart have identified that if you do a federation flow where the RP and OP choose different trust anchors, you don't get federation integrity, i.e. you don't share a common trust infrastructure.</li><li>This is only possible because inter-federation and membership in multiple federations is allowed.</li><li>There is a proposal to add a trust path, i.e. a sequence of entity IDs, in a call such that you can verify that you use a common trust anchor.</li><li>There is a discussion with the researchers about redoing the security analysis. The editors of the spec intend to address all security-relevant PRs and new features before redoing the analysis. Gail is managing the scope of this.</li><li>Chris: It is similar to proxying: how do I know which rule set to follow? The "standard" solution is to use the union of both rule sets. But how do you know that the policy of the two trust anchors is compatible?</li><li>Where should the issue be discussed? It can happen in the WG call, in the GitHub issues, etc.</li></ul><li>Another interoperability event is planned - either in person or online</li></ul></div></div></div><div><br></div><div>Best regards,</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><font color="#000000" face="Menlo"><span style="font-size:12px"><b>Frederik Krogsdal Jacobsen</b></span></font><br></div></div></div></div>