Attendees: Heather, Scott, Benn, Ivan, Leif
A few notes re: the spreadsheet:
* Items in yellow are things we should think about, but may not be
blockers in our particular circumstances.
* The phrase “more application than integration” applies to the idea
that a good home has a process for ensuring projects are sustainable,
and that the organization will not just become a dumping ground for
random projects. The process of vetting an inbound project (and bringing
it into conformance as needed) is generally referred to as incubation.
The incubation process is usually fairly complicated, and involves
active engagement with the potential home organization. An application
process is simpler, and basically consists of a few questions for the
potential home's board to consider in deciding whether or not to accept
* Organizations may want to have their lawyers look at the application
Leif: the project has to feel “at home” with the other projects in the
IPR home; we can’t be too different from what else is happening in that
organization. That makes Apereo perhaps a bit of a stretch. We want to
have a home where we can have a certain amount of self-governance.
* Apache Foundation has a lot of structure, and each project is
reasonably independent but expected to follow Apache Foundation’s rules.
Leif: a poor fit because of the focus on what their projects are about
(i.e., they don’t have much in the way of identity-related projects).
* SPI, SFC - Benn is not seeing a lot of support in SPI or any level of
community in SPI or SFC. Heather: if these were the last options
available, that would be something we would pursue further, but we have
other options so these aren’t worth pursuing
* Apereo - Leif is concerned about Apereo’s long term viability, though
Benn points out if we own the IPR we can always move the project.
* Commons Conservancy - GEANT already has something of an agreement that
would make this easier, and NLNet Foundation (the parent organization
for CC) has long term viability via their established DNS software (see
https://nlnet.nl/project/current.html for list of NLNet Foundation projects)
Channeling of funding
* some organizations want ability to collect money; Commons Conservancy
is not set up to route funds (that’s what they use NLNet Foundation or
GEANT for). Apereo is set up for that.
* This was by design for Commons Conservancy - indirect IPR
protection; it would be pointless to a takeover because the project does
not control its funds. If someone sues you for IPR infringement, there
is no money to be taken.
* There is definitely a possibility of future cash donations (not
just the current in-kind funding via FTE that we see today)
* Heather to set up calls with both Apereo and Commons Conservancy to
have them talk to us, introduce ourselves, etc.
* How do donations work? How do we handle money? How do tax
agreements get handled with multiple countries? Given that we’re giving
with contributors across national boundaries, where do the CCLAs fall in
terms of jurisdiction? What is the international suitability of their CCLA?
* Heather to reach out to the code authors to see if they have a hard
“no” (which include non-responses) re: signing a CCLA to turn over their
code to the project
This is a reminder that there is a call about idpy governance tomorrow,
27 March @ 16:00 UTC (9am PT | 12noon ET | 18:00 in Sweden). The goal of
the call is to settle on an IPR home for idpy; once we've done that, I
can start creating the necessary policies and procedures in accordance
with the requirements for $IPRHOME.
A comparison chart of possible IPR homes is available in a Google doc:
If you have not received an invitation and want to be on the call,
please reach out to skoranda at sphericalcowgroup.com and he'll get you
added to the BlueJeans meeting invitation.
There was no good time for folks with the first attempt at a call to
discuss finding an IPR home for idpy. I've put together another doodle
poll - hopefully there will be a time that works more easily for mst!
If you would, please fill out the poll by Wednesday, 21 March 2018.
We were experiencing severe pyFF restarting problems since our last
deployment. It turned out lxml was updated to 4.2.0 which introduced
segmentation faults on every metadata refresh. Downgrading to 4.1.1 resolved
As for adopting CMService in idPy: Niels will make an official statement about
The list has been quiet, and people with action items related to the PRs
still have some work to do. Please take the meeting hour to work on your
tests or flesh out your PRs to meet the new templates, and Ivan will do
his magic with regards to reviewing and writing code.
If you have any questions or discussion topics, please post to the list!
Martin, Heather, Scott, Rainer, Ivan
Leif, Roland, Jonas, John, Benn
0. Agenda bash
1. XML bug (Ivan)
It is primarily an XML issue. We are not effected because we are using
element three which by default strips comments (though that is
problematic in a different way). This means one of the standards for
signing is not included in the code base. This is still a theoretical
limitation (no one has complained (yet)).
Ivan has found some interesting tools that might be used to help
validate XML. There is a tool in pySAML2 to do this; it works, but it is
not maintained. Ivan is still investigating. Note that this might also
be of interest to pyFF.
2. pySAML2 PRs - https://github.com/IdentityPython/pysaml2/pulls
Scott’s PRs are waiting on him to write tests. No other blockers.
PR 471 is straightforward to merge.
Ivan is still reviewing the other PRs.
PR493 is failing tests but the fix might not be the right solution.
There are many places where pySAML is encoding things, so need to
understand where and how we can generalize this. Need a test.
PR495 is also assigned to Ivan. It seems fine; will probably just accept.
PR499 is new. Not sure what the use case is here. It ties back to Issue
412 from May of last year. It could still use a test; Ivan will write a
comment asking for that.
Action item: update the PR template to be more explicit in asking for
the use case
3. Governance update
Many thanks to the interested parties that filled this out, but alas, I
will need to extend the doodle poll as some of the key people are unable
to be in the same place at the same time. Look for an updated poll in
the next few days.
* Consent manager service (Martin) -
discovered code injection bugs while investigating the SAML bug. Roland
says the code has been abandoned. SURFnet is actively using the
CMservice, so the question is what else is being used in the consent
space in idpy? For the other deployments described on the call, consent
is not part of the workflow (e.g., platform participants are employees
or otherwise have already consented to using the service)
* Should it be included? Consent will become more of a thing in the
future for additional deployments. Scott is supportive. Request for
Martin to ask if SURFnet is willing to provide some resources for
ongoing maintenance. Martin to send a formal request to the list as per
our inclusion guidelines.
* SURF fork of the software:
* The its-dirg is a department that has since been disbanded as Umea
University. Need to reach out to Leif and Roland to see if they can
reach out to someone who still has access
* New functionality request that would require a new SAML front end -
The Satosa mirror front end exposes multiple IdPs by mirroring the IdPs
that are available from the back end. If you’re federating with eduGAIN,
it would take those IdPs and expose them at the front end as multiple,
logical IdPs. This bypasses the WAYF. Satosa still looks like a single
SP. For Scott’s use case, rather than having mirrored IdPs that are
based on the downstream authenticating IdPs, the goal is to have
multiple virtual IdPs on the front end of Satosa that correspond to VOs.
The idea is that using a CMP, you would have a VO and would be able to
provision into Satosa a logical IdP that represents that organization.
Example: A set of SPs want to federate with the IdP for the MWA
collaboration. So, when the user looks to the service, they pick their
VO and from their VO, they get a smaller list of associated IdPs. The SP
will still think the user has come from the MWA virtual IdP, not
whatever the actual downstream IdP authenticated was. This is intended
to be something dynamic.
* This seems to be a new use case, and new tool(s) will likely be
* Where should the information be stored? How does it consume the
information over time? Should this be functionality for Satosa as a
whole, or be a separate front end? Scott will pull together an initial
proposal and more specific questions for the group.
March 20 - Note that Heather is unavailable, but group will still have a
discussion if needed