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

[Andrii Deinega]

I couldn't join the call, but I wanted to express my support for these two
statements.

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


and

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


All the best,
Andrii


On Thu, Feb 20, 2025 at 11:49 AM John Melati via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> 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.
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250220/c1e19331/attachment-0001.htm>