Attendees Roland, Scott, Giuseppe, Heather, Johan, Matthew, Hannah, Ivan, John P, Leif Notes: 1 - GitHub review    a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc) Roland and Giuseppe started looking at abstract storage - a way to persist information that the OP/RP gather during their lifetime. Started a draft to describe this, and an implementation using SQL Alchemy. This changes the CryptoJWT API slightly. There is an abstract storage library now in GitHub, and Roland has a branch on CryptoJWT (abstorage) that uses what Giuseppe has. See PoC: https://github.com/peppelinux/pyAbstractStorage Ivan notes we probably want to avoid being tied into SQL Alchemy, but the design should allow for other possibilities (e.g., MongoDB) Please review and submit issues or PRs.    b. Satosa - https://github.com/IdentityPython/SATOSA Still working on the exception handling, designing a layered approach to how we handle errors. Instead of a single function, will try to propagate exceptions to other layers so they will handle them as they need. Also doing work on the loggers and have a few things ready. Before he pushes, want to make sure we have a compatible path for the new library and dependencies. This is based on structlog. Whenever the state of the proxy is saved in the cookie and when the user redirected to another service, we need to clean up the state of the cookie. We’re not near any limits wrt the cookie, but this will be a way to keep things clean. One use case: stopping a SAML flow with Satosa, and then allow the user to go through an entirely different SAML flow that still uses the same Satosa instance, then put the user back into the original SAML flow. An example of this is a step-up flow. Ivan has some code that does this. The consent microservice also does this. The routing mechanism, though, needs to be rewritten. This will one of the bigger refactoring we need to look into. https://github.com/IdentityPython/SATOSA/pull/322 - the flow that can start from the discovery service; this has been deferred for a while - is it ready to roll? Not yet; will review on next call https://urlproxy.sunet.se/canit/urlproxy.php?_q=aHR0cHM6Ly9mdW5jdGlvbnRyYWN… - allows you to get info from a running service. Ivan is trying to make this work with Satosa; it was originally designed to run around an executable, not in a flow like ours.    c. pySAML2 - https://github.com/IdentityPython/pysaml2 Someone reported an issue where building rpms was not working. Given the age of these systems, we’re not going to try and fix this. Even if we wanted to support this, it is more properly an issue for the Python maintainers. Another issue ( https://github.com/IdentityPython/pysaml2/issues/675) was about pylint errors - most of the issues were a result of not all libraries being installed. On the list: • https://github.com/IdentityPython/pysaml2/pull/662 - want to merge 662 (cleanup on the name of the id attribute used by xmlsec in order to encrypt/decrypt/sign XML documents, specifically SAML). • https://github.com/IdentityPython/pysaml2/pull/665 - Also want to merge a fix for the tmp file creation. Python gives you a way to create tmp files, but this only works for UNIX systems. This needs to be refactored in order to support Windows.    d. pyFF - https://github.com/IdentityPython/pyFF 2 - AOB FastFed - could the structure be useful to us? Maybe - the work started with a specific task to connect an OP with an SP. But this does not meet many of the needs of Higher Ed, and many in the higher ed sector have voted against it. The vote did pass, but they have asked for a representative of the group that voted against it to join and work with them on the spec. They had asked early on if they could use the OIDC federation work, and that would have covered many points but not the attribute mapping issues they also had. The proxy should do attribute mapping better as well; that’s on the list.