Attendees: Ivan, Giuseppe, Roland, Scott, Heather, JohnP 1 - Governance policy updates • no comment on the PR; next step to send these to the Board for approval • djangosaml2 status - need to make sure the maintainers are good with the revised governance policies 2 - GitHub review    a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc) Roland and team are still working on the session management system. Particular thanks to Nikos for the hours he's put into this. Roland is looking at dpop (https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/) which is a way to bind tokens to clients so a resource server can check that the token came from the client that received the token. It uses http headers and puts a signed json web token in it. The source code can't do much with http headers, so some additional functionality is required. Will there be a signature on the header? It's using Proof of Possession. The json web token has as the payload a representation fo the public key that the token was signed with.    b. Satosa - https://github.com/IdentityPython/SATOSA Travis-ci (https://www.travis-ci.com/, a hosted service used during integration testing) is still not working properly. Ivan has reached out to the platform maintainers, but has not heard back. Doing work in eduTEAMS, including different errors for users. Goal is to catch the errors (since we know about them) and exposing new exception types so we can handle the errors better. Will introduce a handler for the errors (a module that the admins can write to make explicit what they want to have happen with a given defined error). This will also result in better logging.    c. pySAML2 - https://github.com/IdentityPython/pysaml2 See discussions on idpy #saml slack channel. Ivan is working on the encryption and signature parts. This is the priority for pySAML2 for now.    d. pyFF - https://github.com/IdentityPython/pyFF 3 - AOB • Python version support - Roland received a PR from a developer of cryptJWT, and in that included deprecating Python 3.6 because there is an EOL on 3.6 coming up at the end of this year. When we know of an official EOL for any components in our project, when should we deprecate it out of our projects? Before it reaches EOL, or shortly after? • Scott suggests we try to wait on the timeline to transition of 3.6 until 4Q 2021; some active platforms (NIAID/NIH) out there depend heavily on Centos7, and they can get python 3.6 from that associated repository. Getting python 3.7, however, is harder. They are in process to transitioning to a docker-based architecture, but it will take them several months to get there. • Why do we need to deprecate 3.6? Are we blocked on functionality in the language? Deprecating means we're not going to test it or patch against that version. We've also talked about basing our code on what's in Debian stable, and that Debian comes with python 3.7. We should have a plan on the transition and be prepared to notify users (announcing on Slack and the mailing list). • Next steps: we will start the communications process in September/October to let people know this is going to happen, announce in a couple of releases, then make it official Thanks! Heather