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