Hi guys,
OIDF has agreed to host the OIDC libraries that I helped Google build.
They also understand that they must fund the maintenance of the libraries.
To make it more concrete they want the Python packages (which are the only one that are done) to be moved to the
OIDF GitHub site within the next couple of weeks.
This means that the cryptojwt, oidcmsg, oidcservice and oidcrp repos will be moved away from IdentityPython.
I people don’t disagree I’d like to keep the OP side repo oidcendpoint and oidc-op (not there yet) at IdentityPython.
And of course all the repos that has to do with OIDC identity federations.
— Roland
The higher up you go, the more mistakes you are allowed. Right at the top, if you make enough of them, it's considered to be your style.
-Fred Astaire, dancer, actor, singer, musician, and choreographer (10 May 1899-1987)
Hi all,
As part of operationalization the InAcademia service I have had to look
into the software licences and IPR of SaToSa, and its underlying
dependencies. Please find an overview below. The ones marked with a *
are included into idpy universe if I am correct, the others are
external. If you feel something is missing, or should not be in this
list, please let me know.
Based on that I have a few questions and observations:
*Licenses*
* It was not trivial for all components to find out the actual license,
especially for some of the dependencies, as licenses are not always
included. In several cases a license statement is included in the
meta-data of the pip package, but the actual license conditions are not
met. (like e.g. in the case of Apache2, a license file needs to be
delivered as part of the code). From a very puristic point of view that
would mean the software is actually not open source, and hence cannot be
used without a legal risk.
* For the software marked with * we do provide licenses and we do live
up to the conditions of the license :)
* License compatibility wise, we are doing well: all idpy related
software is apache2 licensed, and we do not seem to have dependencies
that outright conflict that license, apart from "chardet" which is LGPL
licenced. (I used this a a baseline:
https://www.apache.org/legal/resolved.html) While I do not think any of
us have the ambition to sell SaToSa as a product directly, I was
wondering if we should replace this with an alternative with a more
suitable license.
* Given the long list of dependencies, I must say I was wondering if we
do not have a little cleaning up to do.
*Copyright & IPR*
* For the idpy related software I note the copyright statements seem to
be missing or incomplete: I know for sure Roland has been working on
several components, but I suspect he has been doing so with multiple
hats on. However I e.g. do not see either GEANT project, UMEA or
NORDUnet copyright reflected, while I do see commits from GEANT project
members in the git history. I am wondering if we should rectify this,
especially in the light of the EU's sensitivity to being able to see
what their money was used for (we have had questions on that in previous
EC reviews of the GEANT project). I could also image a similar sentiment
with some of the NRENs and companies that contributed?
Comments and though are much appreciated!
Best,
Niels
python_editor Apache 2.0
alservice Apache 2.0 *
cmservice Apache 2.0 *
oic Apache 2.0 ?
pyjwkest Apache 2.0 *
pyop Apache 2.0 *
pysaml2 Apache 2.0 *
requests Apache 2.0
satosa Apache 2.0 *
vopaas Apache License 2.0 *
vopaas_statistics Apache License 2.0 *
pymongo Apache License, Version 2.0
pyopenssl Apache License, Version 2.0
babel BSD
beaker BSD
flask BSD
flask_babel BSD
flask_mako BSD
jinja2 BSD
markupsafe BSD
pycparser BSD
werkzeug BSD
alabaster BSD License
click BSD License
pycryptodomex BSD License
cryptography BSD or Apache License, Version 2.0
repoze.who BSD-derived (http://www.repoze.org/LICENSE.txt)
idna BSD-like
python_dateutil Apache License, Version 2.0
chardet LGPL
alembic MIT
asn1crypto MIT
banal MIT
cffi MIT
dataset MIT
future MIT
gunicorn MIT
mako MIT
normality MIT
paste MIT
pip MIT
pystache MIT
pytz MIT
pyyaml MIT
six MIT
urllib3 MIT
webob MIT
wheel MIT
setuptools MIT License
sqlalchemy MIT License
certifi MPL-2.0
decorator new BSD License
defusedxml PSFL
bson Apache License, Version 2.0
cryptodome BSD or Apache License, Version 2.0
gridfs Apache License, Version 2.0
itsdangerous BSD License
jwkest Apache License, Version 2.0
openssl OpenSSL License
past MIT License
pkg_resources BSD or Apache License, Version 2.0
saml2 Apache License, Version 2.0
yaml MIT License
zope.interface ZPL 2.1
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nlwww.openconext.org
Attendees: Martin, Heather
No word from Ivan, so not sure about the status of today’s call
https://github.com/IdentityPython/satosa_microservices/pull/11
Martin made a minor pull request around consent service (microservice). To really fix the problem Satosa has to be changed to accept HTTPS POST requests. Not sure if/how this is handled by idpy.
If you update this microservice without Satosa being changed, then Satosa will break. This is not a backwards compatible change.
Any issues with the template for the PR? It was a bit heavier weight than was necessary for such a small change, a bug fix. This was also already fixed in SURF’s own branch, so they’ve already got it running.
Sent from my iPad
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
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."
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
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
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
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
