Idpy meeting 23 April 2024

Attendees: Shayna, Ivan, Hannah

0 - Agenda bash

1 - Project review

a. General -

b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc, JWTConnect-Python-CryptoJWT, etc)

https://github.com/IdentityPython/idpy-oidc/pull/99
Comes with some changes that break certain deployments (core AI - but has been fixed)
Move forward and then have new release of idpy-oidc

There has been some focus on federations and supporting capabilities of open id federations. Most of the work is in Roland's personal repo for fedservice.

https://github.com/rohe/fedservice - Roland is working in a wider context around wallets, but everything binds together through the federations.
Ivan is working with Nicos L to import certain capabilites to the front end that is being built for the Géant Core AAI platform. Currently uses idpy-oidc and will now also use fedservice for federation capabilities.

There are a few items that need to be revisited: client notification methods - private keyjwt and how it is handled internally in the library; how to keep public keys from the metadata, how to refresh, how often - Ivan needs to discuss with Roland - these capabilities are needed.

merged an MR on master that introduces exception cases that have wrong variable names - error handler is then crashing. Fixes need to be done to address this.
Roland's open PR to fix the dependencies and how they are checked - https://github.com/IdentityPython/SATOSA/pull/442 - missing checks of whether idpy-oidc and other libraries are in dependencies - Ivan needs to fix these parts and merge, then have a new release
There is pending work around routing workaround paths - https://github.com/IdentityPython/SATOSA/pull/451 - instead of running at example.com, you could have SATOSA running at example.com/satosa. This is useful not only for deployments that need it but also for separating out what the paths mean. Then there can be separate controllers and handlers for different paths. Looking into changing the framework. PR needs some work - Kristof B is aware. There was a previous PR that was more complex, so this one was created to specify the problem in a clearer way and move forward.
Ali and Hannah's work with the logout is very important.

https://github.com/IdentityPython/SATOSA/pull/444 - logout from idp side
https://github.com/IdentityPython/SATOSA/pull/431 - logout from service side and propagates to other entities.
important to decide how to organize keeping state on the server side. The cookie can not hold any more information.

Some other issues: How to handle claims for oidc - https://github.com/IdentityPython/SATOSA/issues/457 - mapping of what the standard oidc claims should be - including multi-valued which can be represented as an array, a space separated string, etc. What about a non-standard claim? Certain profiles for EduPerson for example. Map an internal claim - single value as a string, not a list. There will be discussion on this. Main idea is to extend internal attributes mapping file, making a more complex structure which indicates how these values can be compared to other values, how many items to exist, what types they should be, etc.

Main concern - what to do with XMLsec1. Should there be a move to a different way of encrypting/decrypting/signing/verifying SAML payloads?
With which algorithms should the payload be signed or encrypted? Which algorithms do we accept as valid for signatures to allow decryption?
Ivan plans to focus on this soon.

Ivan knows people are waiting on some answers on other issues and he is trying to get them.
Ongoing issue: Python and its support for temporary files on the Windows platform- Ivan has a small patch locally. Another user has a proposed solution for checking temporary files and deleting afterward. but it is not a long-term solution. Ivan would prefer it to be automatic if possible. Ivan's patch is a workaround. He will post it, but this needs further discussion. With Linux WSL the temporary file deletion just works, but Windows breaks. Few users are affected, but it does come up.
https://github.com/IdentityPython/pysaml2/pull/951 - bug fix for domain validation - in practice everyone sets properties in the SAML response that specify where the response came from as an IP address. This only affects domain names. User has suggested a fix but it includes the port. Strictly, the port is not part of the domain. Ivan has made suggestions on the PR.

e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)

2 - AOB