<div dir="ltr"><div># OpenID Connect AB<br><br>Date: 2025-01-16<br><br>## Attendees<br><br>* Niels van Dijk<br>* Aaron Parecki<br>* Mike Jones<br>* Vladimir Dzhuvinov<br>* Elizabeth Garber<br>* Dick Hardt<br>* Brian Campbell<br>* Jan Vereecken<br>* Lukasz Jaromin<br>* Eruardo Perottoni<br>* Bjorn Help<br><br>## Minutes<br><br>* Intros from Jan, Niels, Eduardo<br><br>Upcoming Events<br><br>There are a set of OAuth interim working group meetings in progress. Next topic: one-time tokens, then Private Key JWT<br><br>*   OAuth Interim Meetings on Mondays <<a href="https://events.oauth.net/tag/ietf">https://events.oauth.net/tag/ietf</a>><br>*   FIDO Plenary, Feb 4-6, Melbourne, Australia<br>*   OAuth Security Workshop <<a href="https://oauth.secworkshop.events/osw2025">https://oauth.secworkshop.events/osw2025</a>>, Feb 26-28, Reykjavik, Iceland<br>*   IETF 122 <<a href="https://www.ietf.org/meeting/122/">https://www.ietf.org/meeting/122/</a>>, Mar 15-21, Bangkok, Thailand<br>*   OpenID Workshop and IIW <<a href="https://internetidentityworkshop.com/">https://internetidentityworkshop.com/</a>>, Apr 7-10, Mountain View, California<br><br><br>Reminder about new call schedule. Every Thursday and every other Monday. Next call on Monday the 20th.<br><br>Reminder of Active Specifications <<a href="https://openid.net/wg/connect/specifications/">https://openid.net/wg/connect/specifications/</a>><br><br>### OpenID Provider Commands<br><br><a href="https://github.com/dickhardt/openid-provider-commands">https://github.com/dickhardt/openid-provider-commands</a><br><br>* Dick: This new draft from Karl (formerly Okta) pulls together a number of things we've talked about over the last year<br>* OIDC Backchannel Logout explicitly says not to revoke refresh tokens issued with offline access. But if you think an account has been taken over, you want to kill those too, so there is a need for a command for this. The "unauthorize" command in this draft does this.<br>* There are commands around account lifecycles, creating, suspending, deleting, etc<br>* The metadata command enables the OP to send metadata and get back metadata to the RP<br>* Most use cases fall into the enterprise SaaS b2b world where the OP is managing identities for an enterprise and managing resources at the RP, as opposed to a consumer use case<br>* Mike: There has been discussion among Vladimir and Aaron on the list<br>* Vladimir: When you say commands, is there any expectation about the delivery, is it supposed to be guaranteed delivery or just try to send out the token<br>* Dick: It is expected to be synchronous and if you don't get a response back you assume it didn't work. Think of it more as RPC than signals. OP Commands is "I want you to do something". The OP may not even send an ID token to the RP unless it knows the RP will support certain commands. <br>* Vladimir: Is this only at registration<br>* Dick: The metadata command can happen at any time, so the OP might send metadata before an initial login. There is also a tenant concept. OP says "which commands will you support for this tenant", the RP replies, then the OP can determine whether it will even send an ID token. Group management is also part of OP commands.<br>* Dick: For RP SaaS apps that don't need all the functionality of SCIM, they could use OIDC and OP Commands to provide SSO and provisioning/deprovisioning instead of SAML and SCIM.<br>* Dick: We want to minimize the effort required by the RP to support this. In SCIM, how the client authenticates is out of scope. In OP Commands it's in scope, signed by the OP with the same key that signs the ID tokens, and the schema of the commands builds on the schema of ID tokens. To ensure a command can't be used as an ID token, it follows similar specs and prevents a nonce from being in the ID token.<br>* Mike: does it also require a type value<br>* Dick: Yes, that changed to a MUST<br>* Brian: There was some interesting language when it was a SHOULD with compatibility with existing deployments of commands. Was that a copy paste mistake from another specification, or is that a hint that there is an existing deployment that is now being considered as an actual specification<br>* Dick: It was unintentional, built upon the OpenID Backchannel Logout spec.<br>* Brian: The Backchannel Logout also profiles Security Event Tokens. It looks like you didn't follow that construct?<br>* Dick: Yes, mainly because secevents focuses on it being an event, we want to be clear this is a command not an event<br>* Brian: That makes sense. The use of "schema" in these things is maybe not great, can be confusing to different audiences.<br>* Dick: The claims build on the same claims as in an ID token.<br>* Mike: I'd like to let this get discussed for a week then talk about it on a call in a week<br><br>### Native SSO<br><br>There is one PR outstanding, George isn't here<br><br><a href="https://bitbucket.org/openid/connect/pull-requests/744">https://bitbucket.org/openid/connect/pull-requests/744</a><br><br>Mike: This has two approvals and is largely editorial. I suggest it's time to merge this unless there's any objections, then George will publish another draft.<br><br>### OpenID Federation<br><br><a href="https://github.com/openid/federation/pull/177">https://github.com/openid/federation/pull/177</a><br><br>Vladimir: Don't look at it yet, I might retract it. We think there is an opportunity to simplify the combinations further. There are 3 conditional combinations currently defined, something Roland implemented years ago is to stop processing early. We could devise a rule if there is a value operator then ignore other operators that might be present, so we could drop the conditional checks for the default operator.<br>Mike: I assume the value still has to be consistent with the restrictions of the other operators. For example if you have "must be A or B" and a value operator of "C" it should throw an error right?<br>Vladimir: Value has the top priority, when a trust anchor says this operator, the logic is nobody else should be able to override it. If an entity down the trust chain adds another operator, this should be disregarded because the value operator has precedence over the others.<br>Mike: That goes against the principle of equal opportunity<br>Vladimir: In principle we allow every authority to contribute to policy. However if the superior authority has made the choice to fix a certain parameter then the subordinates should not be able to override it.<br>Mike: It should be an error if the subordinate attempts to<br>Vladimir: Yes. The overall objective of #177 is to make it possible to have multiple trust anchors in federations and devise policies that would work even when you can't satisfy all policies. However the metadata published by the leaf entities could still satisfy these conditions. I tried to argue this in the PR. Say we have a situation where we have a single trust anchor and you're an authority somewhere down the trust chain. You would look up the policy the trust anchor set and not try to add an operator or policy that would conflict. However if you have multiople trust anchors and have to consider multiple superior policies having this allowance would make it possible for a given trust anchor policy to work without combination or merge errors. It makes an allowance to let policies work in a wider set of scenarios without breaking the hierarchy principle. The hierarchy principle is whatever policy set by a trust anchor shouldn't be made more permissive by an intermediate.<br>Mike: Sure but if the intermediate expresses something in conflict with superiors that's inconsistent and should be flagged as an error not permitted.<br>Vladimir: Yes that's one way to look at it <br>Niels: I think the point is to not permit it but to overrule it. By having a value set at a trust anchor level it will disallow an intermiediate to be more permissive. On one hand I would agree, on the other hand I dont think you can assume you can always step in greenfield and build something consistent. In the real world you will run in to inconsistent federation topologies.<br>Mike: My point is if you try to apply an inconsistent policy it should result in an error. Providing incentive to fix inconsistent policies.<br>Niels: There might be an inability to fix inconsistencies, that might exist because there is a requirement within their local federation.<br>Mike: I'm being strident about this because we wrote down a clear set of principles. All the parties in a trust chain have equal authority. Whether the value came from an intermediate or a trust anchor the value has the same weight.<br>Vladimir: It would be good to look at concrete examples, we haven't tested this yet.<br>Mike: I don't want to take all of our time on this, is this written down? <br>Vladimir: No this is just an idea.<br>Mike: Can you write this as a comment in the PR or create a new issue, it sounds like this will allow things that would previously have been errors to not be errors, so this deserves discussion before moving forward.<br>Vladimir: Don't consider #177 yet<br><br>### Issue 178<br><br><a href="https://github.com/openid/federation/issues/178">https://github.com/openid/federation/issues/178</a><br><br>Mike: There were places where the language suggested using other forms of registration rather than static registration like is usually done. Vladimir also wrote a PR, 179<br>Vladimir: This is editorial, clarifies that federations that have OIDC or OAuth entities can utilize other methods to register clients that use the openid federation trust chain. They aren't limited to explicit and automatic methods specified.<br>Mike: People should review this<br><br>Mike: Any other OpenID Federation topics? None<br><br>### Federation Wallet Architecture<br><br><a href="https://github.com/orgs/openid/projects/1/views/1">https://github.com/orgs/openid/projects/1/views/1</a><br><br>Mike: The github feature "projects" can be used as a status board to drive discussion around issues and pull requests. Giuseppe put in the time to characterize his view of the outstanding issues for this spec. Unfortunately he has a conflict right now otherwise would have been here.<br>Mike: Issue 19 <a href="https://github.com/openid/federation-wallet/issues/19">https://github.com/openid/federation-wallet/issues/19</a> says endpoint randomization should be closed. There was a lot of pushback in the discussion prior to adoption. Therefore unless anyone has an objection I'm going to close it on the call. Closed.<br>Mike: Issue 39 <a href="https://github.com/openid/federation-wallet/issues/39">https://github.com/openid/federation-wallet/issues/39</a> will assign Giuseppe<br>Mike: Issue 42, trust mark with intended usage. <a href="https://github.com/openid/federation-wallet/issues/42">https://github.com/openid/federation-wallet/issues/42</a> I think this is ready for a PR to do this. <br>Mike: Anyone can speak up if you want to talk about something in particular.<br>Mike: 41 complex trust mark examples. I don't think this is controversial, but I would want to see the text to see what people should gain from this. Will mark as ready for a PR.<br>Niels: Looking at 41, these are some of the examples discussed in figuring out what we would want in R&E. I wasn't aware he had taken it so far which is good.<br>Mike: Niels would like to talk about the SURF architecture next week.<br>Mike: Issue 22. <a href="https://github.com/openid/federation-wallet/issues/22">https://github.com/openid/federation-wallet/issues/22</a> In order to make this actionable, we should file separate issues for each. We should consider whether to do each of the things in the list separately in their own issues.<br>Mike: Issue 37. <a href="https://github.com/openid/federation-wallet/issues/37">https://github.com/openid/federation-wallet/issues/37</a> Status list for trust mark status checks.<br>Niels: I hadn't considered hooking trust marks into status lists. We are mostly using short lived trust marks. It looks like there was more discussion than what is written here.<br>Mike: Please note that in the issue.<br><br>Call closed.<br><br></div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>---</div>Aaron Parecki<div><br></div></div></div></div></div>