This is (to me) both simple and a bit more complicated. Regarding the ownership of the JWTConnect-Python-* libraries I think the only viable solution is that IndentityPython takes over the ownership. I think they fit into our palette of libraries. They are the bases of the OIDC federation implementation and once they are incorporated into the SATOA framework it will give that framework a lot of new useful functionality. Which brings me to the slightly more complicated side of this. Right now, OIDC in SATOSA is represented by pyoidc and pyop. Neither of which is under our control. They both have active maintainers but I get the feeling that there isn’t a lot of development of new functionality just keeping things running. The last example of new functionality was me adding session and logout functionality :-/ Probably the last thing I will do on that library. For future work then, I’d like us to not just take the JWTConnect-Python-* libraries under our wings but also concentrate our future OIDC development efforts on those and the oidcendpoint/oidcop/fedservice libraries. Then there is the issue about the names. :-/ Having JWTConnect-Python- being part of the name was all good and well when the Python libraries where part of a group of 3 sets of similar libraries (Python, Java ´and JavaScript). Now, when the only set that seems to have a life is the Python one then we might want to rethink the name issue. And lastly, way back there was some discussion about whether we should take on not just the Python libraries but also the Java and JavaScript. Now the Java library was finalised (to some definition of final) while the JavaScript was not. So JavaScript is out. Regarding the Java libraries no-one to my knowledge is contemplating taking on the ownership of them, so if we want them I don’t think anyone will complain. — Roland Can anything be sadder than work left unfinished? Yes, work never begun. -Christina Rossetti, poet (5 Dec 1830-1894)