Hola a todos!
As discussed on the last call, we’re going ahead and canceling the call for 22 December. THAT SAID! Please fill out the doodle poll so I can get the 2021 series of calls on the calendar. Right now, only four people have responded. I you have an opinion about when the calls should happen, please fill out the poll:
I had a question from Torsten Lodderstedt, who some of you know, on whether our OIDC/OAuth2 implementation
supported all the features that the FAPI 2 baseline stipulates.
Turns out we do support most of them (PKCE, PAR and the new iss authorisation response parameter).
What we don’t have support for is RAR (https://tools.ietf.org/html/draft-ietf-oauth-rar-03 <https://tools.ietf.org/html/draft-ietf-oauth-rar-03>).
The new session/grant subsystem has hooks for it but we’re lacking the part that actually can use it.
I don’t think that GEANT has any use for RAR but I may be wrong. If so I’d like someone to tell me.
The larger question is of course: should we care what FAPI/FAPI 2 demands ?
Or ultimately, our customer what do they want ?
Anyone knows who are customers are ?
Anyone with an idea as to who we would like to be our customers ? Except for the HigherEd and Research ?
Can anything be sadder than work left unfinished? Yes, work never begun. -Christina Rossetti, poet (5 Dec 1830-1894)
Hello idpy developers!
ON the last call, the group suggested sending out a poll oto see if our current call time slot works for 2021, or if there might be a better one for the participants. I’ve put together a poll to see if we can answer that question. When you fill out the poll, please consider whether you can make that time slot every other week, and not just that one day.
If you could fill that out before you head off for any vacations you might be taking this year, I would greatly appreciate it!
Ivan, Giuseppe, Heather, Hannah, Roland, Scott, John P, Johan, Nikos
1 - Status of architecture documentation & Normalizing idpy projects (see email from Ivan, "Subject: [idpy-discuss] Normalizing across all projects”, 10 November 2020)
Before we make djangosaml2 part of idpy, we should have a stronger set of guidelines on what we expect in terms of managing a project (using semver, readthedocs, change logs, etc). Could also use something called “cookie cutter” which does several of the set up of these kinds of things for projects in GitHub. While we would not create new project spaces for projects that come in with their own repository, it would allow for a type of model and technical documentation on how we think projects should look like. Note that this would let us to also normalize on how we handle issues, what labels we use, PR templates, a common FAQ, tooling to build and test packaging, boilerplate (README, LICENSE, etc)
• Example: https://github.com/SUNET/eduid-webapp/tree/master/cookiecutter-app
Ivan will continue to write up his thoughts in email.While Ivan can make these decisions for Satosa and pySAML2, need input from other maintainers.
• We can agree to semver and pep8, but some of the other things we’ve been talking about are very heavy for some of the smaller projects.
• Do we know who our customers are, and what they need? Will they be taking our libraries and using them to build their own use cases? Or are they looking for a packaged service they can just run? We can’t cater to both. Can we have two categories of rules? One size won’t fit all projects.
• What about change logs? They send a good signal to deployers about what to watch for when they upgrade (or help them decide if an upgrade is required).
• README and LICENSE files
• PR and issue templates (already exist)
• Change logs
3 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
New project for the documentation on session management (code is still in oidcendpoint). Since readthedocs can’t handle documentation for forks, this allows the publication of material before the code is even final. Has not pushed to readthedocs yet; will aim to have that done before the next call.
b. Satosa - https://github.com/IdentityPython/SATOSA
c. pySAML2 - https://github.com/IdentityPython/pysaml2
There was a bug in the redirect binding, where the request was also going to be signed. The problem is that by default, if the signing algorithm was not specified, the right parameters were not produced. This has been fixed. In the same PR will be Giuseppe’s work on configurable signing and digest algorithm (see https://github.com/IdentityPython/pysaml2/pull/744). Ivan will be pushing a commit with partial notes (in the form of bullet points) and other people involved will help turn that into proper documentation. We will need to refactor the whole process of signing, encryption, and decryption.
d. pyFF - https://github.com/IdentityPython/pyFF
4 - AOB