3:46 p.m.
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.