Idpy meeting 23 January 2024

Attendees: Johan W, Shayna, Ivan, Matthew E.

0 - Agenda bash

1 - Project review

a. General -

We would like to get Roland to do a demo on his wallet system. There is great interest about the trust within the system, the issuers, the credentials, etc. Shayna will message him about scheduling it.

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

Focus is currently on projects around oidc that implement the wallets.
version 3.0.0 of idpy-oidc was released 17 December.
side news - Christos is creating a repo to host GÉANT Core AAI frontend, which is based on idpy-oidc. The main component is SATOSA - this will happen soon.

c. Satosa - https://github.com/IdentityPython/SATOSA

Repo needs to be cleaned up. Some things have been merged but no release. After cleanup, Ivan needs to add dependencies for oidc backend as an extra requirement (optional dependency).
Other PRs that are pending to go in:

Roland's work on removing SAML parts - https://github.com/IdentityPython/SATOSA/pull/442 -
Pavel's PR - https://github.com/IdentityPython/SATOSA/pull/419
Johan's PRs - https://github.com/IdentityPython/SATOSA/pull/449 and https://github.com/IdentityPython/SATOSA/pull/450

Ivan is looking at these Metadata PRs - https://github.com/IdentityPython/SATOSA/pull/438 and https://github.com/IdentityPython/SATOSA/pull/448 - Ivan has some issues with these - there is a better way, using this (metaform) instead as a base : https://github.com/SUNET/swamid-satosa/tree/main/src

438 is getting info from oidc services to be accessed by user - denotes different metadata in terms of language in a specific way, which is also something that the oidc standard specifies. It's a nice notation that gets us away from having to nest things based on a language signifier. Instead, this uses display name of a service with a language tag - default (no language tag) is english. Only does this for some information, but more would be useful and there will be some work to accommodate that.
448 - work is from Vladimir in NZ- mixing attibutes for person with the metadata, because there is no other place for this information. A new slot should be dedicated for this information. Also there is some information such as display name, scopes, etc., that is implied to be about the IdP, but it could be about the SP - there is no indication where it came from. The idea is to have a dedicated slot - not mix things with the attributes of the subject, and then under its own key also have info for the service AND for IdP. Then everything is separated and made clear. And then we can denote the languages with the notation from 438 (inherited from oidc spec). Can be based on metainfo (see above) which has collators that work with both SAML and OIDC. For OIDC it is implied there is a data structure - someone who has statically registered the client would need to add this data - it is not part of the official spec.
Discussion of using Scott K's attribute store plugin response microservice for IdP metadata attributes. It pulls from metadata store in the context. Be careful if you redirect - the object with the information will go away. Part of the reason Ivan would like proper server side storage for the proxy is that some federations may have many scopes for their IdP which creates a huge payload, and if you grab the metadata from this object and try to put it in a cookie, it is too large.
Ivan would like to make this part of SATOSA, not just a microservice, so not just attributes of user are available, but also of the service and the issuer. This will require proper APIs for both the backends and frontends, to get the data in a specific, defined format.

d. pySAML2 - https://github.com/IdentityPython/pysaml2

Some updates need to be done for dependencies - there will be a new release to accommodate these things

cryptography has a new version
cryptojwt
xmlschema - new version/release is breaking APIs that are currently being used.

Fixing datetime() calls for python 3.12 as they are deprecated
Get back to configurable encrpytion algorithms / signing

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

djangosaml2 - possibly looking to add new logging calls to do tracebacks?
thiss - working on container to get readymade setup

Matthew E. is also trying to get an all-inclusive seamless access deployment working, and once they do they will contribute their containers/changes back to the community.
His goal is to create a docker compose file that others can use, using as a default eduGain metadata, to get their own seamless access working. Then put pyff, thiss-mdq and thiss-js in the docker official images library to get regular rebuilds for security updates and follow good current practices for containers.
Johan may be able to share something with Matthew from his own deployment, for smaller federations. They restart pyff service every 15 minutes to reload metadata.
pyff can be used two different ways: as a service, or as a process that runs once and processes metadata, spitting out xml files for you, along with a json feed which can be used by thiss-mdq/thiss-js. There may still be a memory leak in the service variant?
SWAMID is wanting to get a new release of pyff - there are some small commits to HEAD that they need.

2 - AOB