Hello everyone, I will try to describe how development has evolved and where we are now, try to clarify a few points and give my perspective on the matter. Please, correct me if I'm wrong or if I've skipped any important events. Before going further, a brief summary of the list of libraries and software involved: - pyoidc - aka oic; under OpenIDC - pyop - under IdPy; no active development - forwarding users to the newer oidc-libs (below) - oidcendpoint - under IdPy; deprecated - oidc-op - under IdPy; deprecated - idpy-oidc - under IdPy; active development - satosa-oidcop - oidc-op based frontend under Università della Calabria, developed by Giuseppe Satosa is an auth-proxy that works mainly with SAML and OIDC translating between the two as needed in a configurable manner. Satosa is built in a way that separates the core from protocol adapters that essentially translate to/from an internal structure imposed by the core, from/to a protocol specific representation. The point of this separation is to facilitate extensibility of supported protocols, choice of implementation and features, independent evolution of the core and the adapters (internal and external), and separation of concerns (maintain focus). We have discussed within IdPy about going further and enforcing this by separating satosa to a -core repo and managing each plugin (micro-service, backend and frontend) separately on their own repos, with their own dependencies, lifecycles and releases. This promotes others to do the same; use the software, but develop their own plugins to help implement their needs, instead of centralizing the development and responsibility (code review, quality assurance, maintenance) on the current satosa repo. In this regard we have a dedicated section on our docs about external resources and contributions by members and users of IdPy (https://github.com/IdentityPython/SATOSA/blob/master/doc/README.md#external…) The work that Giuseppe has done, including the satosa-oidcop frontend, is there. From the point of satosa, there should be no "exclusive" or "official" adapter, but we should be talking about choice, preference and flexibility as a feature of the software, in-line with open source development. This is why we have that section in the docs and I want to do more to make this even more visible. At the moment, the satosa repo is bundled with OIDC/OAuth backends based on pyoidc and an OIDC frontend based on pyop. Pyop is a library under IdPy that itself is based on pyoidc. Satosa has always used pyoidc on the OAuth and OIDC backends to implement RPs. It also used pyop and pyoidc to implement the OIDC frontend for the OP side of the proxy. This is not because of preference or to support those projects, but due to the organic evolution of the codebase. At some point in the past, we decided to adopt the JWTConnect libraries. From this set of libraries oidcendpoint was the library that could be used to implement an OP. At the same time, eduTEAMS (that is heavily based on satosa) was looking into developing a new OIDC frontend with the goal of supporting multiple new flows/grants and features that were not available on the existing pyop-based frontend. Given the activity and support of pyoidc, but also considering the relationship and wish to support IdPy, it was decided not to invest in pyoidc but use oidcendpoint as the basis for this work. This is not a secret; every community supported by eduTEAMS knows that behind the scenes is IdPy magic. Work started on oidcendpoint, we had the first big PR introducing a new way to handle sessions, and then reworked the persistent layer. At that point it was decided to merge the work with oidc-op to ease the handling of releases of multiple layers of libraries and shorten the path between the app (the coordinator that implements the real storage mechanisms) and the libraries (tooling) that provide the interfaces and the data to be stored/serialized/packaged (as needed) by the app. Later, the subject of supporting CIBA came into the requirements and that resulted into integrating RP-features under the OP-library; thus it was decided to move the work under a new library, namely idpy-oidc. This is the supported library we are focusing on within IdPy, and has support for both RPs and OPs. At the moment, there is an open PR changing internals of the library to ease out the management of sessions in relation to grants. And I think this is where we stand today. When we first decided to take in and work on the new oidc libs, we agreed to (and in practice we do) redirect people to the new oidc-libs when an issue or ticket is filled for pyop. This happens even when somebody is looking for an oidc-frontend; we redirect them to the satosa-oidcop repo. The same thing happens when somebody is looking for a new micro-service that doesn't come bundled with satosa, we point out repos outside of IdPy but that may be helpful to the user. eduTEAMS has supported the evolution of the OIDC libraries throughout this process and is still doing so. @angelakis, @nsklikas and @ctriant have been working on those libraries, improving the code, adding features, extending the configuration and extensively testing especially the bigger changes and transitions. This was done within the scope of developing a new OIDC frontend for satosa. The goal has always been to stabilize a set of features and capabilities before releasing this frontend to the public. This has not changed; the team wants to release a stable codebase, sufficiently tested with a guide on how to get started. Changing libraries, rewiring the code, ensuring the impact of big changes and re-establishing trust in the implementation is time consuming and hard to manage. Given the team size and available resources, I think eduTEAMS is doing its best to be up to date and to test and verify new releases and PRs. At this point, the work on the frontend is focused on integrating with idpy-oidc (incorporating the Grant manager 2 changes, which are pending as a PR), supporting a basic but extensible form of token revocation (draft PR) and supporting the resource-indicators specification (draft PR). Internally, there is already an initial release of the frontend based on idpy-oidc that is being actively tested. These are the last features that are planned (along with polishing the docs) before opening a much larger task - which is OIDC Federations. I think this work should be open-sourced before getting into OIDC Federations. eduTEAMS is lacking the resources and deeper knowledge for this spec to do this alone. I think that it would be great to have more people working on this frontend and as Christos said interested parties are welcome to join and help out at any point. When this work is open, where that repository will be hosted is up to Geant and Christos to decide. Bringing it into IdPy would probably be welcome, but it will have to have a maintainer and has to go through our usual process to be accepted. Hosting the work is a separate concern from open-sourcing it. Having people supporting that work would be wonderful and starting now would accelerate the whole process, whether it is moving forward with the PRs or working directly with the frontend even if it is now under Geant. Cheers, On Mon, 24 Oct 2022 at 15:56, Christos Kanellopoulos <christos.kanellopoulos(a)geant.org> wrote: -- Ivan Kanakarakis - sunet.se