March 2018 - Idpy-discuss - lists3.sunet.se

Agenda: idpy developers meeting, 3 April 2017

by hlflanagan＠sphericalcowgroup.com

Date: Tuesday, 3 April 2018 Time: 06:00 PT | 09:00 ET | 15:00 GMT https://bluejeans.com/655841213 Agenda: 0. Agenda bash 1. pySAML2 PRs - https://github.com/IdentityPython/pysaml2/pulls 2. Satosa PRs - https://github.com/IdentityPython/SATOSA/pulls 3. Governance update 4. AOB

6 years

1
1
0 0

Notes: idpy governance call, 27 March 2017

by hlflanagan＠sphericalcowgroup.com

Attendees: Heather, Scott, Benn, Ivan, Leif https://docs.google.com/spreadsheets/d/1dNR8clA_wKouhwonD8bIiyA5N2wMsorS8Uz… 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 the project. * Organizations may want to have their lawyers look at the application process. 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) Action item: * 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

6 years

3
5
0 0

Canceled: Invitation: idpy developers call (biweekly) @ Every 2 weeks from 6am to 7am on Tuesday 24 times (PST) (discuss@idpy.org)

by bas.zoetekouw＠surfnet.nl

more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWtrOGRldGlsamQxbW5ld…> idpy developers call (biweekly) When Every 2 weeks from 6am to 7am on Tuesday 24 times Pacific Time Where https://bluejeans.com/655841213 (map<https://www.google.com/url?q=https%3A%2F%2Fbluejeans.com%2F655841213&sa=D&u…>) Calendar discuss at idpy.org Who • hlflanagan at sphericalcowgroup.com - organizer • discuss at idpy.org Going? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWtrOGRldGlsamQxbW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWtrOGRldGlsamQxbW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWtrOGRldGlsamQxbW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWtrOGRldGlsamQxbW5ld…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account discuss at idpy.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

6 years

1
0
0 0

Reminder: idpy governance call tomorrow, 27 March 2018

by hlflanagan＠sphericalcowgroup.com

Hello all, 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: https://docs.google.com/spreadsheets/d/1dNR8clA_wKouhwonD8bIiyA5N2wMsorS8Uz… 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. Thanks!

6 years, 1 month

1
0
0 0

Doodle poll: idpy governance call (second attempt)

by hlflanagan＠sphericalcowgroup.com

Hi all, 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! https://doodle.com/poll/33gu594nmn4q7p85 If you would, please fill out the poll by Wednesday, 21 March 2018. Thanks! Heather

6 years, 1 month

3
3
0 0

lxml 4.2.0 problems in pyFF

by martin＠surfnet.nl

Hi, 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 our problems. As for adopting CMService in idPy: Niels will make an official statement about that. Best regards, Martin

6 years, 1 month

2
1
0 0

idpy call next week CANCELLED (20 March)

by hlflanagan＠sphericalcowgroup.com

Hi all, 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! -Heather

6 years, 1 month

1
0
0 0

Updated invitation: Biweekly idpy Developers call @ Every 2 weeks from 6am to 7am on Tuesday from Tue Feb 20 to Tue Mar 20 (PST) (discuss@idpy.org)

by hlflanagan＠sphericalcowgroup.com

This event has been changed. Title: Biweekly idpy Developers call When: Every 2 weeks from 6am to 7am on Tuesday from Tue Feb 20 to Tue Mar 20 Pacific Time (changed) Video call: https://plus.google.com/hangouts/_/sphericalcowgroup.com/discuss-hlflana <https://plus.google.com/hangouts/_/sphericalcowgroup.com/discuss-hlflana?hc…> Calendar: discuss at idpy.org Who: * hlflanagan at sphericalcowgroup.com - organizer * discuss at idpy.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=Xzg4cTQ0ZDIyNzEwa2FiO… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account discuss at idpy.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

6 years, 1 month

1
0
0 0

Notes: idpy developers call, 6 March 2018

by hlflanagan＠sphericalcowgroup.com

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

6 years, 1 month

3
4
0 0

Agenda: idpy developers meeting, 6 March 2018

by hlflanagan＠sphericalcowgroup.com

Date: Tuesday, 6 March 2018 Time: 06:00 PT | 09:00 ET | 15:00 GMT https://bluejeans.com/655841213 Agenda: 0. Agenda bash 1. SAML / XML bug 2. pySAML2 PRs - https://github.com/IdentityPython/pysaml2/pulls 3. Governance update 4. AOB Sent from my iPad

6 years, 1 month

3
3
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Idpy-discuss March 2018