Attendees: Matthew, Roland, Johan, Ivan, Heather, Giuseppe Note: 0 - Agenda bash • py11 - who is maintaining this? 1 - Administrivia     a. Board slate for 2023 • Heather Flanagan (Spherical Cow Group) • Leif Johansson (SUNET) • Christos Kanellopoulos (GÉANT) 2 - Project review     a. General • python minimal version update; first with pySAML2 (see notes below) and later to Satosa and other libraries   b. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc) • Roland's video is now on YouTube. While creating the session, found things to change in the code to be more consistent. That's been complete and the OIDC federation implementation has been updated as well. Question now is what to do with the older PRs from eduTEAMS. Should those PRs be applied first, then Roland's changes, or vice versa? When the work is complete, then Roland will not do any new development (bug fixes only) unless new functionality is absolutely required. Instead will focus on writing documentation for other core developers (not users) • PR for client credentials - nice to have, not necessary • PR for revocation endpoint - that is deployed and running in eduTEAMS; it should come with tests and ok to merge • PR for various changes - fixing or changing some things that came when eduTEAMS migrated to idpy oidc; changes that were never merged on oidc op.     c. Satosa - https://github.com/IdentityPython/SATOSA One new issue reported - desire for support for more client authentication methods. Don't want to do this on pyop; should try to push them to use the new front ends. Still wants to move Satosa to using poetry, but hasn't had time yet.     d. pySAML2 - https://github.com/IdentityPython/pysaml2 • bumping the minimum supported python version to 3.9 (as supported by latest stable Debian) - some of the updates to various libraries would be much nicer if we stick with a more recent version of python; would be able to use types (among other things). Primary cause for using types is support for better documentation. There are tools that will allow types to be stripped from the code if people in older environments need that. idpy 3.7 is the oldest supported python release, but support for that ends in June. • Ivan to send a note to the mailing list letting people know about this change. Bumping the python version will be its own release for pySAML2, then another release adding support for mypy, then a separate release adding support for types. • start adding typing support (and use mypy) - see python 3.9 discussion. Once you have enough info through the types, it is easier to refactor the code because you know what's there, what cases need to be covered. • this is done in the context of Johan and Fredrik working on adding support for the Anonymous/Pseudonymous/Personalized entity categories     e. Any other project (pyFF, djangosaml2, etc) djangosaml2 - new release out; there was a regression from the previous release. pyFF - Matthew is planning to develop a docker official image for pyFF sometime this spring, similar to what he's developed for Satosa. What's on dockerhub now is old and not obviously maintained. Nicole Roy will also be part of this work. • eduTEAMS uses pyFF; they have forked the image and updated it with minor modifications. The problem with pyFF is that the bigger the metadata you give it, the more memory it requires. Could look into breaking the operation into chunks. The only reason the whole payload is required is to calculate the final signature, but that can be done incrementally. Unclear if this change would break anything. eduTEAMS (Ivan) has investigating this on the list, but it's not a high priority. This would be an internal change. • SUNET has also requested some changes and have created a branch with improvements. Need to ask Leif about this. py11 - ok for Johan to be the maintainer and merge his PR? Yes. 3 - Documentation Doc writing guidance: • https://www.writethedocs.org/videos/eu/2017/the-four-kinds-of-documentation… • https://developers.google.com/tech-writing • https://www.technical-communication.org/technical-communication/software-do… • https://ieeexplore.ieee.org/document/625327 (pay walled) Should we post a survey to collect information on the developer's experience to help prioritize/guide our documentation? When a developer lands on the idpy pages, do they have enough information to start contributing and engaging with the community? There are different types of developers - developers who are trying to deploy it, developers who want to add functionality, developers who are trying to find an answer to a specific question. • Roland is focusing on writing documentation for developers who have a specific problem with the current OIDC libraries • Heather and Ivan to review https://github.com/IdentityPython/Governance/blob/master/idpy-projects.md to see if it needs to be updated (see section on Technical quality) Thanks! Heather