Attendees: Johan L, Shayna, Ivan, Mikael, Hannah, Matthew

0 - Agenda bash

1 - Project review

a. General -

Find a new time slot for a weekly meeting - Mondays 12-13 UTC
Find a time slot for a review of "documentation pain points" meeting with Matthew E -we will take time from the 27 January meeting
Ivan will send a message to the board, to discuss transitioning to a different model (running services)

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

Roland - discussion of PRs in stages vs one big one - Ivan will reach out to him again. Mikael reports there is a workshop going on about handing over the keys to the kingdom.
there will be a PR coming regarding audience policies

before the open id connect frontend/library can release a new token, and include an audience as a claim in the token, this audience can be setup with certain rules. There is a specification in the RFC that the client can request certain audiences can be included in the token, in the audience claim, using the resource indicator.
How the OP will decide if they will do this or not is more complicated. The OP will process the request and will see the client wants the audiences in the auth claim, so it applies a filter. But what if it doesn't? How does it signal that it didn't respect what the client requested? No matter what, ultimately the OP will decide which audiences go into the auth claim.
But what if the policy changes over time? The OP may be reloaded with a new policy. The client will use a token or give one to an RS, and we need to take into consideration that the policy may have changed when replying from the different endpoints where the audience can have participation.
What happens if we can't refresh our access token because a policy changed? What happens if you are allowed to do more things than were requested? The potential change over time spans is the tricky part, and may cause the OP to deny a request.
Need to introduce a hook in the right places where the audience will be set/returned/displayed to apply the policy needed.

Nikos has gone through the PR Roland opened - looks good and was tested - will be merged.

Ivan (speaking for both SATOSA and pysaml2) will work on the next stages of release, incorporating different categories of PRs - he has some changes locally but hasn't pushed them yet

Making sure compatible with python 3.13 - should do this with all code. Has been addressed for pyff (see below)

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

Conversations with Enrique around pyff - need discussion with spec authors around trustinfo elements- Matthew Stewart will ask the working group for their help to expand on the specification and capabilities. There are some questions about processing the list of preferred/exclusively trusted identity providers, done through the services metadata or another structure - a JSON payload with a list of sets of IdPs. During the processing of the list, it is possible that what has already been processed is getting overwritten. It shouldn't happen that the same list should be entered twice. How should this be handled? Should it be up to the implementers; should we throw an error or a warning? Need to determine how to handle these edge cases. Should this invalidate the service such that we don't continue to process its metadata? Should we skip the repeated entity, use the last entity, etc?
Mikael added a github action to make sure they can build pyff with latest python release. This should probably be done for all code.

2 - AOB

Change meeting invite and ensure Enrique and Alex are added
Matthew is going to post his mock SAML workflow writeup to the idpy-discuss list. He is doing a similar writeup for the idpy-oidc libraries. It is a narrow example of the authentication flow, mocking up an OP and RP, simulating a request and response and processing the response. He may be able to share some of that with us at the next meeting. It is using pytest but not simulating things like a web browser.