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

May Day holiday and ipdy - call cancelled

by hlflanagan＠sphericalcowgroup.com

Hello all, Ivan reminds me that most of the rest of the world has a holiday today and tomorrow to celebrate May Day, which means very few people will be available for the idpy call. There are several things in progress right now--Ivan's contract to become our Benevolent Dictator, my work to draft up governance documents, handling of various pull requests--which means those of us who don't have a holiday this week can use the time to get stuff done, and everyone else can focus on having items done in time for our next call on 15 May. Talk to you all later in May! -Heather

6 years, 2 months

1
0
0 0

Unsolicited SSO front end for SATOSA

by xenophon＠irtnog.org

Dear all, I wrote a front end that implements unsolicited SSO: https://github.com/irtnog/salt-states/blob/development/satosa/files/lib/ satosa/unsolicited.py I am implementing the same interface as Shibboleth, documented here: https://wiki.shibboleth.net/confluence/display/IDP30/UnsolicitedSSOConfi guration#UnsolicitedSSOConfiguration-SAML2.0 Is this the right approach? How do I go about contributing this to the SATOSA or satosa_microservices project? The web site (http://idpy.org/contribute/) doesn't say. I don't know where to find a copy of the CLA, for starters. I did see the pull request templates, which ask for unit tests and PEP8 style, so I'll work on those next. I'd love to get your feedback. Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

6 years, 2 months

1
0
0 0

Canceled event: idpy developers call (biweekly) @ Every 2 weeks from 6am to 7am on Tuesday 20 times (PDT) (discuss@idpy.org)

by hlflanagan＠sphericalcowgroup.com

This event has been canceled. Title: idpy developers call (biweekly) When: Every 2 weeks from 6am to 7am on Tuesday 20 times Pacific Time Where: https://bluejeans.com/655841213 Calendar: discuss at idpy.org Who: * hlflanagan at sphericalcowgroup.com - organizer 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, 3 months

1
0
0 0

No idpy developers call this week (17 April 2018)

by hlflanagan＠sphericalcowgroup.com

Hi all, We're cancelling the call for this week. I encourage you to use the time to work on making sure the use cases are clear and the tests are available and run for any PRs you've submitted. Our next call is scheduled for 1 May 2018. -Heather

6 years, 3 months

1
0
0 0

CLA/CCLA message sent

by hlflanagan＠sphericalcowgroup.com

Hi all, The email went out giving code contributors a heads' up re: the need for a CLA or CCLA for code committed to Identity Python projects. As expected, we have some bounces, and some addresses were never valid to begin with. Bounces: <Andy.Richter at brige-way.com> <hans.horberg at umu.se> <hossain at newscred.com> <ikakavas at noc.grnet.gr> <matt at netki.com> <rebecka.gulliksson at umu.se> <yo at launchkey.com> Invalid addresses: <DasAllFolks at users.noreply.github.com> <haho0032 at its-admins-MacBook-Pro.local> <ludwigkraatz at users.noreply.github.com> <rebeckag at users.noreply.github.com> <rhoerbe at users.noreply.github.com> <z38 at z38.invalid> I'm not too worried about the uma.se ones, as we we have other contacts there. I'm also not worried about rhoerbe - we know where to find Rainer. Thoughts on how to contact or verify what code was submitted for those people and/or organizations I can't reach? -Heather

6 years, 3 months

6
10
0 0

Notes: Chatting with the Commons Conservancy, 11 April 2018

by hlflanagan＠sphericalcowgroup.com

hi all, A few of us met with Michiel Leenaars from the Commons Conservancy today to talk about CC as a potential IPR home for idpy. I still have to get a call with Apereo on the calendar. For those of you that are interested but were unable to attend the call today with CC, notes are below. ---- Attendees: Benn, Roland, Ivan, Michiel, Heather, Leif Handling money: 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? What kind of volume are we talking about? Right now, none at all. CC has a few mechanisms. Anyone that has a tax treaty with NL (which is most of the world). Will be setting up a 501(c) in Delaware in the next few months, which will help folks in the US. If entities can’t donate, but can receive invoices, have a separate company for that (Commons Caretakers). This is called a fiscal fundraising entity, meant specifically for charities. This is working well for the Filesender project. The idea is to de-couple the keeping the money from the place where it is (e.g., keeping the money in Japan to avoid Japanese issues, but still accepting donations). There is a universal regime in Europe - anything tax deductible in one country is tax deductible in another country. If you want to do grants, then that will work as well: NLnet can help deal with that. We do want to separate governance from funds handling. Idpy doesn’t know what the funding model will look like exactly, but it will probably be a similar model to current projects - a relatively small number of international, organizational contributors. We won’t have use case in the near future that require multinational stashing of funds. CLA: CC has no fixed model. The default model is from contributorlicenseagreement.org. That is considered a best practice, but the can also use the FLA (fiduciary license agreement). CC has a generic foundation, and bootstrap underneath that a set of VO (not confined to traditional foundation model). The VOs can organize themselves, and can put their own restrictions on what people can do - you can fork the organization, or never. You can dictate where the code can go, etc. Conditions enforced at the foundation level; will enforce even after the VO evaporates. This will allow you to do things like mix licenses (e.g., MIT and GDPL), if needed. Current use case: we’ve reached consensus on Apache2. Still discussing governance models. Open questions: Handling of the IPR, code ownership, CCLAs. The sample license agreements sent to us to review came from contributorlicenseagreement.org. The default selection that CC has made was drafted by the legal advisor of the Free Software Foundation of Europe, so very much vetted towards international usage. US centric questions: The concern is more about the CCLA than the CLA. Need a package that explains what is is, why it’s important, why you can’t mark it up. We have such a thing for Apache2, but if we wanted to use the defaults from CC we’d need a similar FAQ-style thing. (Michiel agrees). Choice of law: assume we’re staying with Dutch law, but that does make another hurdle on the US side. Many institutions in the US may not have international law resources available to them. So, having that FAQ thing mentioned above that would also include “how does Dutch law differ from US law” etc would also be helpful. (Michiel points out that the FSF people primarily worked from US-based CLAs, so this should be easy to address as well) One more edge case: in the US, government agencies cannot sign agreements outside their home jurisdiction. This will impact state universities and institutions. They can’t accept the jurisdiction of another state. Right now, we don’t have that situation, but that’s something to think about down the road. Mentioning this in response to the 501(c) set up in Delaware. In Europe, some countries are like that. This should scale to the US state-by-state level. What other things should we be asking about? CC is a self-service shop. Just try to give a safe home for the code, and mechanisms to deal with things. Don’t have much in the way of IT infrastructure: you’ll run your own website, lists, etc. Just try to be a safe legal home and a decision infrastructure. You should ask “can you leave?” For example, if you give your code to the FSF, you can’t get the code back. CC wants an easy, low weight to start and which can scale up, but there is no mandate to stay. You can copy the entire framework if you want to, as all the framework documents are Creative Commons. The CC is completely free. If you go with one of the payment infrastructure, there is no mandatory payment structure. People pay what they can contribute. Most intermediaries ask for 10%, which CC thinks is high, but they appreciate people donate what they can. What is the common level of contribution that most projects? Between 5-8%, but it’s voluntary. How many projects are in the program? 6 on board, and about 15 that are in various stages of onboarding * Filesender * eduVPN * Internet of Coins (cryptocurrency effort) * Red Wax * Fashion Freedom Initiative

6 years, 3 months

1
0
0 0

Doodle poll: idpy IPR home and the Commons Conservancy

by hlflanagan＠sphericalcowgroup.com

Hello all, As mentioned on the developers call this morning, I'm setting up a call with Michiel Leenaars at Commons Conservancy to discuss the possibility of working with them as an IPR home for the idpy projects. I've set up a doodle poll (link below). Please fill out the poll by this Friday. I know not everyone will be ready, willing, and/or able to attend the call, so if I don't see your response by this Friday, I'll assume you are willing to catch up via the notes from the call. https://doodle.com/poll/dugz5cadrd9r2q23 Thanks for your time, Heather

6 years, 3 months

1
0
0 0

Notes: idpy developers call, 3 April 2018

by hlflanagan＠sphericalcowgroup.com

Attendees: Jonas, Ivan, Roland, Heather, Rainer 0. Agenda bash 1. pySAML2 PRs - https://github.com/IdentityPython/pysaml2/pulls Ivan spoke with Leif yesterday; may be coming up to Sweden soon for a meeting (and maybe more). Ivan has 493 and 495 assigned; 493 is still being examined. 495 will be resolved soon. Will start looking at 499; Ivan has an idea on how to simplify. When that’s done, it can be merged as well. 498 will be assigned to Ivan; it can be merged, but he has some ideas on how to make it better. 485 and 483 are waiting on Scott to add tests. 468 to the bottom of the list - haven’t looked at those in detail yet. 468 will be rejected. Team is considering adding labels. Ivan will look into what might be appropriate; he has used these in previous repositories. 2. Satosa PRs - https://github.com/IdentityPython/SATOSA/pulls Ivan is currently looking at 137 and 160, and expects to close those tomorrow. They won’t be accepted, but he will take parts of them. When that’s done, he’ll go to 166 (related to issue 165). He has downloaded a Windows virtual machine to try and reproduce. 171 is a fairly big one. 172 can be merge, but waiting on Scott adding some tests. 176 has some fixes, but one of the fixes changes the behavior of Satosa. Ivan would like to go over that with them. Ivan will look at the issues after the PRs. Note that Martin opened an issue in the micro services repository today; will need to review that as well. The question is how to handle the split repo. This has been discussed a bit on the mailing list, but Ivan will ping the list to remind people that input is needed so we can bring this a conclusion. 3. Governance update Heather will be sending a note to committers re: (C)CLA. Expect a set of doodle polls for calls with Commons Conservancy and Apereo so we can discuss their organizations as possible IPR homes for idpy. The call with CC will happen first (Heather hasn't heard back from Apereo yet). 4. AOB pyFF - not sure if Leif has a more permanent workaround for the segfault issue. Also not sure if this has been refactored to be a flask project.

6 years, 3 months

1
0
0 0

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, 3 months

1
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Idpy-discuss April 2018