<div dir="ltr"><div>OpenID Connect A/B<br><br>2025-09-04<br><br>* Mike Jones<br>* Aaron Parecki<br>* Ethan Hellman<br>* Frederik Krogsdal Jacobsen<br>* Brian Campbell<br>* Dick Hardt<br>* Andii Deinega<br>* Chris Phillips</div><div>* Tom Jones<br><br>Notetaker: Aaron Parecki<br><br>## Notes<br><br><a href="https://bitbucket.org/openid/connect/pull-requests/">https://bitbucket.org/openid/connect/pull-requests/</a><br><br>### Removing reference to discontinued browser API<br>* <a href="https://bitbucket.org/openid/connect/pull-requests/753">https://bitbucket.org/openid/connect/pull-requests/753</a><br>* Mike will mark approved, once we have 3 approvals will merge after a week<br><br><a href="https://bitbucket.org/openid/connect/issues?status=new&status=open">https://bitbucket.org/openid/connect/issues?status=new&status=open</a><br><br>### Issue 2184 <a href="https://bitbucket.org/openid/connect/issues/2184/openid-connect-and-user-session-quotas-at">https://bitbucket.org/openid/connect/issues/2184/openid-connect-and-user-session-quotas-at</a><br><br>* Andrii: An RP can indicate to an OP a max number of sessions on the OP side. <br>* Mike: It's not clear why the OP needs to know. The RP could decide to just not allow the login.<br>* Andrii: The reason to manage at the OP is to let the user and OP manage this at the OP side. <br>* Mike: You're asking the OP to do something for the RP that tightly couples them. This would impose an accounting burden at an OP that there is no code for right now.<br>* Chris: Is this more about logout or more about QOS about certain plans get certain concurrent access?<br>* Andrii: This is about where we manage session quotas.<br>* Aaron: Why is there a quota in the first place?<br>* Andrii: Because some customers want quotas. The customer wants to have only one session on the RP side. It is about licensing.<br>* Mike: It's simple to describe, but not simple to get OPs to do it.<br>* Andrii: There is already `sid`, so the RP understands how many sessions are at the OP. <br>* Frederik: Why isn't this just a configuration thing in the OP dashboard, why does this need to be per request?<br>* Andrii: I don't own the OP side, I represent the RP. <br>* Mike: I'm going to call time on this, request that people make comments on the issue.<br><br>### OpenID Connect for Native SSO for Mobile Apps<br><br>* George not on the call to discuss next steps<br><br>### Metadata Choices<br><br>* Mike: PAR explicitly says to use token endpoint authentication methods supported, and didn't create its own parameter. There seemed to be consensus in past calls that this is right, we shouldn't add new metadata for introspection/revocation. <br>* Mike: New PR #8 that says that: <a href="https://github.com/openid/rp-metadata-choices/pull/8">https://github.com/openid/rp-metadata-choices/pull/8</a> Request to review. This let us merge a longstanding PR in Federation.<br>* Mike: Aaron to review<br><br>### Federation Issue #243<br><a href="https://github.com/openid/federation/issues/243">https://github.com/openid/federation/issues/243</a><br><br>* Chris: Since it's a trust issue, if you are not able to validate, you should fail closed.<br>* Mike: Can you add that to the issue. Will assign to Mike.<br>* Frederik: He's saying there are validation rules but can't find what to do if they don't pass.<br><br>### Federation Issue #244<br><a href="https://github.com/openid/federation/issues/244">https://github.com/openid/federation/issues/244</a><br><br>* Mike: This seems to be reopening a past issue<br>* Chris: There is conflation between being able to issue, and revoke. Are you allowed to issue? If you have the private key and can do, then you are allowed.<br>* Mike: Can you leave a comment on the issue.<br><br>### Federation Issue #245<br><a href="https://github.com/openid/federation/issues/245">https://github.com/openid/federation/issues/245</a><br><br>* Mike: Left a comment on the issue<br><br>### Key Binding<br><br>* Dick: I wrote a comparison and posted to the list<br>* Mike: What is the status of the draft you compared it to? <br>* Dick: It's in OpenID Connect, last published May 2023<br>* Mike: There is some duplication in functionality as Dick confirmed. This is a simpler approach, the other doesn't seem to have been deployed. The chairs need to decide whether to declare the other draft no longer active. There seems to be enough interest to run a call for adoption. Any disagreements with sending out a call for adoption?<br>* Brian: Seems like it might be a good idea to coordinate with the authors of the original work, to understand the rationale behind design decisions<br>* Mike: I have to assign myself homework as chair now. The WG has an interest in having a coherent set of specs that fit well together. I will ask the authors of the other spec what they think the right path forward is for their spec. For example this uses VC 1.1 which has been replaced by 2.0. We will reconsider the adoption decision in a week.<br>* Dick: Why not use the call for adoption to drive the discussion?<br>* Mike: I will ask the authors about the draft on list, the new proposal would substantively replace what their draft is doing<br><br>Closing call 5 minutes early<br><br><br><br></div></div>