Attendees: Christos, Scott, Stefen, Heather, Ivan, Leif, Rainer Notes: 0. Agenda bash Minor questions from Scott re: coding style in Satosa 1. Governance and nominations: what does that mean / how we move forward (e.g., with CLA and other CommonsConservancy) / etc) - See email from 11 September 2018 (Subject: [idpy-discuss] idpy governance and nominations for first Board of Directors) for initial set of candidates One concern: is there enough representation of downstream service providers, especially from the R&S sector. Most people are on the provider or federation side. If Heather is willing to hold up the mantle of service providers, then this would be ok. 2. New bugfix/minor pysaml2 release v4.6.2 A function has changed from the previous release which had introduced some breakage. Re-factoring that was fairly complicated, but is along the lines of the coding practices Ivan would like to see in pyXMLSecurity. pySAML did some things based on various inputs and lots of “diff/else” which it didn’t really need to do. Some of the information is already encoded in the URI - you don’t need to figure them out, you need to define them. So write in a more declarative way. 3. pyXMLSecurity refactor (see email from 14 September 2018 (Subject: Re: [Idpy-discuss] getting beyond RSA and PKCS1 v1.5 for pyXMLSecurity) Leif rewrote pyXMLSecurity based on diff/else (as opposed to a table driven way) because this is how the RFCs themselves are written. The URIs are grouped together based on similar behaviors. Leif is willing to do this another way if this isn’t going to work. The problem with parsing is you can make a mistake or accept something invalid, and yet you can’t figure out everything from the URI. So, a fairly complicated problem. Ivan is also thinking that this table could provide pointers to the library, that would make the library itself easier to swap out if needed in the future. Leif points out that the py11 implementation is awkward, however, it’s possible that the next crypto library will have such different API will require a lot of rewriting even if we try to separate the library out. Different crypto libraries provide different things, so the abstraction may not match in the future. This may be necessary for py11, but not sure it’s a fundamental requirement. Perhaps use pycryptograpy directly? Stefen suggests we’re giving out information on the crypto layer to the outside; there always has to be a shim layer that presents this information, so abstraction will not be 100% helpful. Ivan agrees, but suggests we should be in control of this (thus the utility of the abstraction layer for the crypto library). Leif suggests we need to look at what pySAML needs to do and go from there. Note: do not merge the existing PR - it still needs work. Continue conversation in the PR comments. 4. SATOSA: Hashing the user-id - is this necessary? * See email from Ivan, 17 September 2018 Need the ability to configure for all possible options (this could be done via micro services). 5. AOB Copyright and CLA - this needs to be decided. Heather notes that the board should be seated by the end of this month, and that’s one of the top things on their list to sort out.