Attendees: Ivan, Roland, Scott, Rainer, Heather Notes: pySAML2 release * New release is done (yay!) * Some problems with the new packaging software - tools didn’t have a way to specify certain minimum versions. There is a new PEP that can solve this (there is a PR about this - https://github.com/IdentityPython/pysaml2/pull/542) * See the change log for more details ( https://github.com/IdentityPython/pysaml2/releases/tag/v4.6.0) * Expect a minor release soon to fix the packaging stuff Satosa * Ivan has been thinking about how to structure the micro services. Wants to do the same thing with both front end and backend modules. Has written a small part of the proposal on how this should be done and will be sharing that later this week on the list. Expect this to work like a plugin system. * The changes will definitely impact the configuration file, and relies on the use of entry points. * Also interested in introducing asynchronous services, but that’s a bit farther down the road. * Question: how to handle version control when each micro service is its own package? Each micro service will have its own repository and have its own version * Scott is seeing use cases where Satosa needs to make intelligent decisions on which discovery service to use. This may be similar to something Christos needs. Scott will bring up the use case in detail on the next call. * Roland was contacted by Peter Gietz; he has several companies approaching him about proxy services, and he will be using Satosa. He would like to become a member of the idpy community (of course) and will be contributing in the future. * In the GEANT project, where proxying between protocols is common, they are looking at the OIDC front ends being based on the best code and there is are people interested in writing front end code. Roland wrote a flask-based RP and OP, so there is some code that we could use as a POC if we want to be at the front of this. Leif suggested using Blueprints for this, which Roland isn’t familiar with but may be of more general interest. * If you use the SAML front end, you MUST use the SAML back end. Can that assumption be changed at some point, so that you could use an OP? This should be doable. Suggest that Scott open an issue as a placeholder for future discussion. * Some IdPs are not even asserting nameID (see https://github.com/IdentityPython/SATOSA/pull/190) - there is an assumption that there will always be a nameID returned. This PR has a dependency on the pySAML2 code also being updated, and a test won’t be successful unless pySAML2 is updated. Governance * Who is going to maintain the code Roland has been working on? Google is giving that code to the OIDC; Roland has moved that code to OIDC and created a fork in IdentityPython. Maintenance of the Google code: OIDC would assign maintainers of the code and pay them for doing that. Not sure if this is a full or part time thing, or how much they would pay. OIDC is unlikely to hand that money to idpy and ask us to find a person(s). They probably have people in mind for the python and java implementations, but no one at this time for the javascript. * Roland has written an extension to the RP library to cover the OP, and extensions to be able to work in a federation as described by the OpenID federation draft. Would like those extensions to be owned by idpy. * Andreas (Uninett) has developed his own proposal as to how to do an OpenID federation. Roland and Andreas will be discussing if the two proposals (Roland's and Andreas’s) can be merged. Roland to send a link to the list pointing to the two proposals. * The work to get the OIDC federation draft accepted as a draft should be a poster-child for getting people to understand they have to be involved to get standards relevant to them created. * For idpy governance, please review what’s available in https://github.com/IdentityPython/Governance and comment as appropriate.