[Openid-specs-ab] OpenID Connect WG Call (Atlantic) Notes - 20/02/2025

[John Melati]

Participants:



    Aaron Parecki

    Andy Barlow

    Bjorn Hjelm

    Brian Campbell

    Dick Hardt

    Filip Skokan

    John Melati

    Lukasz Jaromin

    Karl McGuinness

    Michael Jones

    Niels van Dijk



Notes:



    SUNET OpenID Federation Interop Event: Niels, John, and Lukasz to define the initial use cases for testing in the interoperability event.  Sign up in the attendee spreadsheet<https://docs.google.com/spreadsheets/d/1zYl-wdzgyol9u3ho342GZhSsg0hhqqneJHlMXWJSIw0/edit?gid=25633585#gid=25633585>.



    OpenID Provider Commands Contribution:



        Karl McGuinness: The specification aims to accommodate developers seeking a simpler infrastructure to implement. Many implementers are behind in adopting the latest standards.



        Dick Hardt: ID Token issuance depends on the RP supporting the OP-required commands.



        Karl McGuinness: SCIM makes sense when the entire internal infrastructure is in place. Managing the infrastructure can be overwhelming for smaller businesses and average administrators.



        Niels van Dijk: Fully supports Karl’s statement. Managing roles and permissions is complex and a significant burden for developers. GDPR also presents a strong use case, as the specification enables active state updates, such as verifying whether a user is still a student.



        Brian Campbell: I believe we should not pursue this work, and I have not seen any objections to that. No feature request for this was made.



        Dick Hardt: Niels has made a feature request.



        Niels van Dijk: OP capabilities would be highly beneficial. RP capabilities would enhance them further, but at a minimum, OP capabilities should be included.



        Aaron Parecki: We should be developer friendly. SCIM and Shared Signals are resource-intensive for companies to implement, which results in weaker security. Companies could onboard customers more easily without the burden of adopting complex specifications like SCIM.



        Michael Jones (as chair): We will initiate a two-week call for adoption to determine support for pursuing this work within the working group.



(More conversation of the potential adoption occurred)



        Michael Jones (as chair): As background on the decision to issue a call for adoption, there’s a presumption in the OpenID processes that if there’s a group of contributors interested in pursing a body of work, that they will be empowered to do it within the OpenID Foundation.  For instance, per the IPR Process doc, the board intentionally *does not* have the power to stop new working groups with sufficient support from proposers from being chartered; it can only do so if they determine that the work would constitute an IPR risk to the Foundation.  Yes, this might result in work that not everyone adopts.  But the alternative failure mode would be having a small cabal of experts determining which work can and cannot proceed.  Rather than do that, the process defers to the judgement of working groups for adoption decisions.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250220/1ae41017/attachment.htm>