Attending Martin, Heather, Scott, Rainer, Ivan Regrets Leif, Roland, Jonas, John, Benn Agenda: 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. 4. AOB * Consent manager service (Martin) - https://github.com/its-dirg/CMservice/blob/master/src/cmservice - 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. (https://github.com/IdentityPython/IdentityPython.github.io/wiki/Adding-and-…) * SURF fork of the software: https://github.com/its-dirg/CMservice/compare/master...SURFscz:master * 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 required. * 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. Next call: March 20 - Note that Heather is unavailable, but group will still have a discussion if needed