Attendees Heather, Ivan, Scott, Roland, Leif Regrets Rainer 0. Agenda bash 1. Use case discussion: SAMLVirtualCoFrontend (https://github.com/IdentityPython/SATOSA/wiki <https://github.com/IdentityPython/SATOSA/wiki>) No discussion needed; wiki has been updated. Ivan has to look at this further to see if this can actually be done in a microservice, or if it needs to be done somewhere else. Perhaps focus on that the virtual IdP needs to be handled in a uniform way to the other front ends 2. Discontinuing Python 3.4 There is consensus to do this. Would also be great to deprecate 3.5 and 3.6, but we can’t actually do that. Most platforms (e.g., Debian, CentOS) are still supporting 3.5. But if we can deprecate 3.4, we can start using the new type hint features. This cannot happen with just a PR, it needs to be in a release. Fortunately, Ivan is working on a release right now; will try to do that in this new version. 3. GitHub review a. pySAML2 - https://github.com/IdentityPython/pysaml2 <https://github.com/IdentityPython/pysaml2> There is a PR by Scott (https://github.com/IdentityPython/pysaml2/pull/621 <https://github.com/IdentityPython/pysaml2/pull/621>); Ivan will be reviewing. The need is to deal with ePTID as an attribute. There are downstream SPs that want to see the NameID element have an SP qualifier attribute and a name qualifier attribute. pySAML2 can’t do that currently. Rather than do lots of new code, will just work with an existing special case within the code. One thing to note: we don’t want to make decisions based on friendly names; this change will be a breaking release for pySAML2. The special case is there because the attribute does not have an actual value; it has a node as a value. Ivan proposes that when creating attributes, what we should be doing is to have a structure to specify the attribute or their values/properties. We should pass around the specifications and they will be converted to XML or internal objects. We should only be taking these specifications for attributes. Scott’s idea is fine for now, but we’ll be doing to the other direction in the future. https://github.com/IdentityPython/pysaml2/issues/586 <https://github.com/IdentityPython/pysaml2/issues/586> - a problem about how we load and check metadata. In pyFF, if you define them in a file, they will get reloaded. The trick for Satosa is to keep it minimal; you don’t want to build a full aggregator stack within Satosa. The way to think about this is that MDQ is the “last mile solution” for metadata. Only look at e-tag and HTTP headers, using something like request_cache. Backend that with whatever. Satosa should point to an MDQ service. Look at the fetch code inside the modern branch of pyFF and the request plugin. b. Satosa - https://github.com/IdentityPython/SATOSA <https://github.com/IdentityPython/SATOSA> New release expected to come out today; expect this to be version 4.0 and future work will follow the branch model discussed at TIIME. After this, will be working on the front end based on the newer endpoint libraries. c. pyFF - https://github.com/IdentityPython/pyFF <https://github.com/IdentityPython/pyFF> Three main things: first, the big split of pyFF into a more modular architecture, which involves splitting pyFF into three pieces: management (front end that you point the browser to), backend (API), discovery service. Two of those are done (management - MDQ browser, not in idpy because it’s not a python thing) and the discovery piece (committed code in thiss-js; a front end packaged with engineX, https://github.com/TheIdentitySelector/ <https://github.com/TheIdentitySelector/>). The third bit is the API refactor; this is mostly stable, but still working on some of the storage code. Hoping to have a new storage implementation in pyFF that has persistence and a better memory footprint. Goal is to have the merge done before TNC. Packaging pyFF, and the parts that are part of THISS. Is anyone working on that? Docker packaging is in the main repository of thiss-js. d. pyjwkest will also have an update shortly; Roland will be committing a patch. 4. AOB Documentation for the OP library needs to be expanded; Roland and Ivan will try to find time at TNC to work on that. Next meeting: 25 June 2019