<div dir="ltr"><ul>
<li>Meeting attendees: Mike Jones, Frederik Krogsdal Jacobsen, Chris Phillips, Joe DeCock, Roland Hedberg, John O’Leary, Filip Skokan, Pam Dingle, Łukasz Jaromin, Aaron Parecki, George Fletcher, Samuel Rinnetmäki, Stefan Santesson, Rachel O’Connell</li>
<li>John O’Leary is new to the group. He is interested in AuthZEN and is sitting in to get acquainted with OpenID specs and work in general.</li>
<li>Date and time of meeting: November 20th, 2025</li>
<li>Agenda: The agenda sent by Mike before the meeting was accepted with no changes.</li>
<li>Events:
<ul>
<li>W3C TPAC was last week. WebAuthn level 3 will probably be published soon. FedCM developed a bit. There is an idea there about putting unmodified Connect flows into FedCM.</li>
<li>OSW: Are there any updates about it? No.</li>
<li>TIIME will have an OpenID Federation workshop (<a href="https://tiime-unconference.eu/">https://tiime-unconference.eu/</a>). They will host an interop event on their testbed during this. Time and location: February 9-13 2026, Amsterdam. Niels van Dijk reports that he is co-chairing the Federation Interop at TIIME with Davide Vaghetti from GARR</li>
</ul>
</li>
<li>OpenID Federation
<ul>
<li>Almost ready for 1.0.</li>
<li>Almost all issues and PRs are now done.</li>
<li>Choice of trust anchors:
<ul>
<li>Stefan: Is there normative language that requires anyone to take action?</li>
<li>Mike: There is normative language defining the mechanism. The RP MAY choose at registration time to pass along the trust chains. It is optional for the RP to do so. The OP MAY ignore the trust chains.</li>
<li>Stefan: The main thing is that we don’t impose any requirements that someone trust someone else. Everyone should be able to make their own trust decisions.</li>
<li>Mike: That is still the case. See <a href="https://openid.github.io/federation/main.html#section-4.4">https://openid.github.io/federation/main.html#section-4.4</a></li>
<li>Roland: The mechanism here is that the RP says: “I would like to use this trust anchor”. The OP is free to not do so if it does not trust that anchor for some reason.</li>
</ul>
</li>
<li>Mike: The editors now believe that it is time to start the 2 week working group last call to move Federation 1.0 to Final. Nobody was opposed to this at the meeting.</li>
<li>Mike will try to fix any spelling and grammar errors etc. then start the working group last call on the new draft.</li>
<li>Issue 290:
<ul>
<li><a href="https://github.com/openid/federation/issues/290">https://github.com/openid/federation/issues/290</a></li>
<li>Mike: I am in favor of defining a small number of reasons for trust mark revocation in the spec, to mirror the historical keys revocation reasons.</li>
<li>Stefan: In X509, this was over-engineered. I’m not aware of any good reasons to be too granular about this. It is unlikely to be used a lot, so don’t put too much effort into defining too many reasons.</li></ul></li>
<li>PR 289:
<ul>
<li><a href="https://github.com/openid/federation/pull/289">https://github.com/openid/federation/pull/289</a></li>
<li>Mike: This is a mix of good editorial changes and model changes. I have asked the author to remove the model changes.</li>
</ul>
</li>
<li>Issue 288:
<ul>
<li><a href="https://github.com/openid/federation/issues/288">https://github.com/openid/federation/issues/288</a></li>
<li>There are multiple very long comments on the issue.</li>
<li>This was a very long discussion with many technical opinions. The notes below are a brief summary.</li>
<li>Mike: Can we have a unified client ID syntax model across OAuth and OpenID? No, because other specs have defined things in a way that makes client ID prefixes not necessarily compatible. But Federation and VP actually happen to be compatible.</li>
<li>Łukasz: I don’t think it’s the right time to make this change now.</li>
<li>Pam: If we need two levels of discovery, we have a problem. How is an AS supposed to know what they’re using? We need to fix the problem now if there is one. The issue is that the client ID needs to be resolvable.</li>
<li>Mike: There is not a problem necessarily.</li>
<li>Stefan: Since the entity can also be resolved in other ways, I am not too scared. I am writing a draft with the missing piece, which is a way to discover subordinate entity statements using a top-down approach.</li>
<li>Łukasz: The tendency is that ecosystems decide in a non-machine-readable way. In the future, this will create interoperability problems.</li>
</ul>
</li>
</ul>
</li>
<li>Native SSO for Mobile Apps
<ul>
<li>Mike: Vladimir requested a particular set of changes in an email title “Re: [Openid-specs-ab] Next steps for the Native SSO for Mobile Apps specification” on November 11.</li>
<li>George: I did not see it yet, but I will respond to his email.</li>
</ul>
</li>
</ul></div>