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