Hi Leif,
I added 2 pipes to buildin.py:
- publish_html creates static HTML views of IDPs and SPs, using XSLT based on Peter Schober’s alternative to MET;
- publish_split: similar to store, but added validUntil and creates signed XML-file per EntityDescriptor. This can be consumed dynamically by ADFS in an IDP role.
I put it directly into buildin.py because it shares some code with the sign pipe. Is this viable from your PoV - if yes, I would make an PR.
Cheers, Rainer
Hi all,
being part of Commons Conservancy brought up yet another subject,
which is whether we should add a header with license information in
every file in the projects under idpy. This is not something done in
an abstract way, there is a specific format modelling this information
(see https://spdx.org/ and https://reuse.software/ - more specifically
https://reuse.software/practices/2.0/) Still, I find it problematic.
We want to open up the question to the wider community and consider
their thoughts on this. The forwarded message below is discussing this
subject. You can see the question we posed, the answer we got and my
comments. Feel free to tell us what you think on this.
---------- Forwarded message ---------
Date: Thu, 16 May 2019 at 09:56
> ---------- Forwarded message ----------
> Date: May 8, 2019, 8:15 AM -0700
>
> > Why does CC think having a single license file per project is
> > insufficient? Our thought is that if we can avoid adding a header to
> > every single file, that would be nice, esp. given we already have this
> > info in the license file and we have the Note Well.
>
>
> this is not just our opinion, but something that is an industry and
> community standard for legal compliance these days. When companies like
> Siemens, Samsung or Honeywell use some code in one of the hundreds or
> thousands of devices and systems in their product line, they need to be
> able to provide the correct license and a download of the exact version.
> This means machine readability too.
>
I've actually observed the opposite of that. Communities abandon the
"license in every file" model, and just use a single LICENSE file in
the root of the project. The LICENSE file contains license
information, that is, it is not a single license but it has exception
sections and so on.
> To quote from https://reuse.software/practices/2.0/ :
>
> Scroll to the section "2. Include a copyright notice and license in each
> file"...
>
> "Source code files are often reused across multiple projects, taken from
> their origin and repurposed, or otherwise end up in repositories where
> they are separate from its origin. You should therefore ensure that all
> files in your project have a comment header that convey that file’s
> copyright and license information: Who are the copyright holders and
> under which license(s) do they release the file?
>
Continuing from above, the standardization of package-management
formats and tools has helped exactly with that: to avoid distribution
of single files, and instead provide packages and modules. It is bad
practice and considered a hack to copy files. Nobody liked that model
and everyone is moving away; it is unstructured, it becomes
unmanageable and it will cause problems.
> It is highly recommended that you keep the format of these headers
> consistent across your files. It is important, however, that you do not
> remove any information from headers in files of which you are not the
> sole author.
>
> You must convey the license information of your source code file in a
> standardised way, so that computers can interpret it. You can do this
> with an SPDX-License-Identifier tag followed by an SPDX expression
> defined by the SPDX specifications."
>
> (the text goes on for a while after this, to clarify the point but this
> is the basic gist of it)
>
> There is a nice Python tool to check:
>
> https://github.com/fsfe/reuse-tool
>
> I hope this makes sense
>
Well, it does not make complete sense. We're talking about licensing a
project. A project is not just code; there are data files (html, xml,
yaml, json files), binary files (archives/zip, images, audio, video,
etc), text files (configs, ini-files, etc) all "not-code". How do you
mark those files? Does the LICENSE file need a license-header? The
json format does not define comments, how do you add a header there?
If a binary file does not get a license header, why should a file with
code get one?
I would expect there to be a way to have the needed information
unified. If the files themselves cannot provide this information it
has to be external; thus the LICENSE file. If someone is worried about
somebody else re-using single files that do not have license
information (a python file, a png image, etc) there is really nothing
you can do (the DRM industry has been trying to solve for a long time;
and still your best bet is "social DRM").
Since, we're developing on open source with a permissive license, even
if someone does that, should we be happy that someone is actually
using what we built or sad that the files they copied did not have a
license header? And if they include the license information of that
copied file in their project's LICENSE file, is this solved?
Having pointed these contradictions, I am thinking that the "license
in every file" model seems to be a step backwards. It is introducing
overhead and does not really solve the problem, while at the same time
it enables a culture of bad practice (copying files around).
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
Hi!
A discussion item for tomorrow's meeting.
pyop
Last release feb 2019.
Based on pyoic which doesn’t belong to our set of packages and is in fact a competitor to one of our own
packages.
I think we should mark it as archived and point people to the Flask based OP example in oidc-op.
In connection to this we might want to streamline installing and running the oidc-op example.
— Roland
“The first principel is that you must not fool yourself — and you are the easiest person to fool”
— Richard Feynman
Hello all,
(So much cross-posting. I can’t really even be sorry about doing it; the conversations are happening EVERYWHERE!)
The Federation & Browsers workshop this week was quite the experience!
tl;dr - a new W3C community group is forming to focus specifically on federated identity on the web. I am working on the charter with a handful of others, and hope to have our first call within the next 3-4 weeks.
The first day of the workshop was primarily presentations from browser vendors (Google, Microsoft, and Mozilla, with some short comments by Apple) and large IdPs (Google, Microsoft, Facebook). People were able to submit questions and vote on them to direct where we took day 2.
Day 2 was all about discussion, kicking of with a discussion on whether we all agreed to these two statements:
• Non-transparent, uncontrollable tracking of users across the web needs to be addressed and prevented.
• Federated login and tracking tools use the same primitives and are indistinguishable from non-transparent, uncontrollable tracking from the browser’s perspective; browser’s proposed mitigations for tracking will impact federated identity.
(Result: General agreement, but with significant uncertainty about the specifics.)
We wrapped up with a discussion about how to keep the conversation moving, and the group agreed to the formation of a W3C community group specifically focused on federated identity on the web. If and when a broader identity community group is formed (which would cover additional topics such as Decentralized Identifiers), then the federated identity CG would be considered a sub-group of the more general one.
I’m in the process of converting the notes to markdown format; their final location will be here:
https://github.com/WICG/WebID/tree/main/meetings/2021
You can already find some of the slides from presenters in that repository.
If you want an early look at the notes, they were taken in Google docs:
Day one: https://docs.google.com/document/d/16wj6UnlaePCE0sdVfkVSwoBMHuFphLuv2sptxdQ…
Day two: https://docs.google.com/document/d/1nZt-bU-9FeoaavSuB6KPC7d3vyKuOhnA5QAd8kT…
Thanks! Heather
Attendees
Johan, Heather, Giuseppe, Scott, Roland, Ivan, Hannah, John P, Peter Gietz
0 - Agenda bash
1 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
There are a number of packages in the OIDC space. Will be merging some of these to make for easier maintenance; nothing is being removed, just rearranged. Example: moved OIDC endpoint into OIDC OP.
This happened at the same time when we rewrote persistence storage, the session handling tools, and cookie handling.
Outcome: major rewrite from what we had before we started the work.
There are 3 issues open and 2 PRs that need to be dealt with. Goal is to sort out the PRs and issues and then release 2.0 later this week.
As always, there is an ongoing need for documentation.
---
Detailed merger breakdown:
CryptoJWT - OidcMsg -+- oidcendpoint - oidc-op
|
+- oidcservice - OidcRP
now we have
CryptoJWT - OidcMsg -+- oidc-op
|
+— OidcRP
We accomplished this by including oidcendpoint into oidc-op and oidcservice into OidcRP.
The inclusion was made in such a way the all classes and functions defined in oidcendpoint would appear under the same name in oidc-op.
This meant that users of oidcendpoint would in the future have to change
from oidcendpoint import XYZ
to
from oidcop import XYZ and everything would just work. Likewise for oidcservice and OidcRP.
Beside doing this change we also rewrote:
- session management
- persistent storage
- cookie handling
Regarding persistent storage and cookie handling our goal was that the oidcop should not deal directly with these tasks.
Oidcop should provide a frontend with access to the information that should be stored in/retrieved from a persistent storage but not handle the storage per se.
Likewise oidcop should provide the information that should be in the cookie payload (the cookie value) but not construct and release cookies.
---
Suggest updating the readme of the retired packages and then archive those packages so they are read-only.
Giuseppe has offered some updates on the federation draft. Looking for more organizations willing to pilot the spec. There are some concerns re: the security considerations section. There is a potential for a DoS via one of the APIs. That needs to be included in the security considerations section with some kind of statement that standard mitigations for DoS applies.
Release-drafter notes: https://github.com/IdentityPython/oidc-op/releases/tag/untagged-fad801bc6e3…
b. Satosa - https://github.com/IdentityPython/SATOSA
Planned work on Satosa is around the cookies. When we get a request, we hardcode which part of the request will be kept. Giuseppe is helping build the list of what will be kept.
Peter Gietz has developed several microservices for Satosa:
----
Production ready implementation of:
• Authentication against an LDAP server
• SCIM attribute store to fetch attributes via SCIM API (instead of LDAP)
• Authoritzation module for blocking services if necessary group memberships or attributes are missing in the identity (for service providers that do not evaluate attributes themselves)
• Backend chooser with Django UI for letting the user choose between any existing SATOSA backend
• Integration of MFA via PrivacyIDEA
Prototype implementations of:
• OAuth2 frontend supporting different OAuth2 flows for clients
• Authentication via TLS client certificate
• Authentication via Kerberos
These all are more or less capsuled as Micro Service, so although we would be happy to contribute the production ready stuff, we would have no problem to keep it as separate Open Source publications.
This will not be possible in a next project, where we need to do amendments in the core product. Basically it is about implementing an optional feature (Key ID in the JWKS response). Here we would have a big interest if this can be taken over into the SATOSA distribution, so we do not need to create a fork and maintain that. Our motivation: we encountered an application that expects such and throws errors, if KID is not present. David or I will write a separate email with more technical details on this.
Code is currently hosted here: gitlab.daasi.de
---
Question as to where to host these, either under Satosa or under a separate repository. If hosted under Satosa, then they will need to be managed in parallel with the other changes in Satosa. If hosted separately, then the maintainer (Peter) has more flexibility about how and when code is updated to match. A third option involves having a separate repo for microservices which will allow more flexibility for deployers to choose what to install; this will be the eventual direction for all microservices.
For now, we will add pointers to the gitlab code.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
New releases for pySAML2 (v 6.5.2 and v 7.0)
• https://github.com/IdentityPython/pysaml2/releases/tag/v6.5.2 - added support for the Shib metadata scopes; various bug fixes; see release notes
• https://github.com/IdentityPython/pysaml2/releases/tag/v7.0.0 - breaking change that changes the default encryption methods. Default algorithm is now rsa-oaep-mgf1p
• next: looking at the old PRs for certificates (how we load them, how we use them, etc)
d. pyFF - https://github.com/IdentityPython/pyFF
Thanks! Heather
Hola a todos!
With many people in Europe enjoying holidays the first part of this week, we’re going to go ahead and cancel the idpy developers call tomorrow, May 4. That said, you are welcome to join the informal call I’m having at 16:00 UTC on the changes happening in browsers that impact SSO and federation. I’ve mentioned this on the Slack channel; if you would like to be added to the invite (and haven’t told me that already) drop me a note and I’ll add you.
It is not going to be recorded - did I mention it’s very informal? - but there are slides I’m happy to share.
Thanks! Heather
