Idpy meeting 14 May 2024

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

0 - Agenda bash

1 - Project review

a. General -

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

Roland was asked what would an identity federation look like using the same type of setup? Roland has something running. Will allow a person who wants to see what the federation is to grab a number of docker images to run their federation. Roland is working on the recipes for this, but someone else is making the actual docker images.

digital wallets - Roland set up an experiment - wallet connects to SATOSA frontend credential issuer, gets redirected to backend to talk to SAML Idp, which returns attributes. Then when the wallet connects to the credential endpoint, it gets a credential with the attributes that the SAML IdP released.

requires persistent storage for the attributes - when you get to the credential endpoint, SATOSA frontend doesn't know anything about them otherwise
when the wallet asks for information, it is expected to provide a credential type (personal, DL, etc). Discussion is going on about specifying credential types that eduGain returns. Could ask for a specific type of information - such as higher ed - i.e. affiliation (not things like courses, degrees)
Roland asked about this (credential types) in Slack - Ivan asked if we know what the payload looks like? - not yet. Still under discussion.

Ivan is looking at native oidc clients - spec says "when this uri is met, this application opens". When uri is localhost and it is a local client, the port number can be anything. In oidc we check for a port exact match. This needs to be fixed - Ivan will describe it in an issue. Breakdown uri into parts, sure make domain is correct, make sure path is correct, but port....
During oidc registration there are references to this claim which is the client type option which separates confidential information from public clients. But some people are using it to say this is a native app, or a web application. The convention seems to be that native clients are public clients. This is still a mystery - what this client type with native means, and web.
Nikos PR Draft - resource indicator, how and when we set the audience in generated tokens https://github.com/IdentityPython/idpy-oidc/pull/102
Roland also has a PR https://github.com/IdentityPython/idpy-oidc/pull/101 - import export module - now works for the complete application structure. Ivan will review.

Kristof - meeting to close off PR about the base url that can be used
lots of pending things and things to be fixed.
Ivan wants to make a check for the optional dependencies and then put out a new release, then move on. Approximate timeframe - hopefully within this week.

A new PR https://github.com/IdentityPython/pysaml2/pull/961 - uses xmlsec module instead of xmlsec1 binary. Created new crypto backend - extended pyxmlsecurity to do encryption with xmlsec module. Could be a new crypto backend and could also do the signing - can xmlsec module do the signing directly? Possibly use this to replace xmlsec1 binary. Issues with xmlsec1 binary after version update - had to do updates on our side to parse output as the outputs changed. The module takes care of this. There are a few tricky things:

xmlsec1 binary - command line options in place to not do any additional stuff like going out to the web to find certificates. Some of these options are missing in the module. We want to make sure it uses the cerificates we provide and not something else. Within the xml payload there is a certificate and this is the one used instead of the one from the metadata.
Matthew question - xmlsec module - is it python standard or third party? Answer - third party. How well has this been tested? Xmlsec1 is battle tested. Ivan - it is C bindings for the xmlsec library.

Tricky thing in pysaml2- have to specify a file in a filesystem. Serverless use cases where that type of config is not readily available require hacking up some way to generate that file before you can configure the pysaml2 client- would this new backend give a new way to configure that keying material? Ivan - Doesn't change the options for the keying material. But currently with xmlsec1 binary we invoke from the command line and pass in pointers to files. With new xmlsec module - won't have to do that - things are loaded from memory. But keys for satosa and pysaml2 entities need to be there. Trick: you can store those material as base64 strings within params - then entry point can unpack and store them on docker file system.

Ivan has used another library to do signing parts - could leverage this to clean up parts of the code.
These can be optional choices - doesn't have to replace what is already there

There are some smaller things to looks into, and a few big ones which need focus

https://github.com/IdentityPython/pysaml2/pull/924 Configurable options for the encryption algorithms

Also some maintenance - taking care of date/time/locations - deprecations in certain methods
Need to merge a few things around how tests are run, pre-commit configurations, etc.

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

pyeleven - important project - a release or maybe tag to make builds more predictable. Pypi would be nice but not required.

Victor was building a project around CA and parts of pyeleven - his code should be under the SUNET repos.
Should do a new release and make sure things are up to date - do a check on the dependencies.

https://github.com/IdentityPython/pyFF/issues/265 - error when trying to load certificates (which may not be well-formatted - unclear). This should be an easy fix.
https://github.com/IdentityPython/pyFF/issues/264 - trickier issue - taking the signature of metadata document when pyff uses configuration with xrd file. Ivan is not familiar with using it this way. Need to understand why the check is being skipped. It worked properly before but it not working correctly now. Did Matthew say he was looking at this? Out put of pyff is given to thiss.io

SAMLtest test idp - gone - SATOSA image needs to be fixed. https://github.com/IdentityPython/satosa-docker/issues/10

2 - AOB

A topic for the board: There is a tension between delivering tools, working on the proxy, and working on the services that support the proxy. Need more people to be involved in the reviews. Issues are very complex, so it is hard to find people to address things beyond the few that have the overall knowledge.