8:25 a.m.
Sorry I missed this. It was the middle of the night here in Taipei where I am for the
FIDO plenary.
Sounds like you had a good meeting!
-- Mike
From: Heather Flanagan <hlflanagan(a)sphericalcowgroup.com>
Sent: Tuesday, February 7, 2023 10:14 AM
To: idpy-board(a)lists.sunet.se
Subject: [Idpy-board] Notes from today’s idpy Board call (7 February 2023)
Attendees:
Chris, Roland, Heather, Ivan, Christos
Slides:
https://docs.google.com/presentation/d/13QL_QRmxZQkLrHYAizoUqTdVZLlQnkwjLMv…
Notes:
* 2022 highlights
* also add that we have an official docker image for Satosa
* note that all but the CryptoJWT should be noted as archived; replaced by
idpy-oidc
* Status of current work
* Considering future idpy projects
* GÉANT+SUNET+SURF were awarded a grant that will allow them to roll out a wallet
in the academic space. Part of this work will be developing these capabilities for Satosa,
and turn Satosa into a digital wallet. Everything on this slide will need to be added to
Satosa, and work needs to start now. There will be a dev team from SUNET working on the
wallet, and GÉANT will run the pilot on their infrastructure. This work is expected to be
in a public space, though it is on top of the OIDC front end that's still private (but
that is expected to be moved to the public space very soon). By this summer (end of
August) we need to have the PoC ready. The list on the slide will be separate libraries.
* pySAML2 has been stable; the work happening now is to support the new REFEDS
entity categories, updating the python version, and typing. When we look to the future
projects, they are all OIDC related. So what will happen to pySAML2? We can keep
developing and adding features, but should that be our focus? Is it time to shift this
purely into maintenance? What impact does this have on the logging issues that intertwine
between Satosa and pySAML2? It is possible for these to drift such that the logs could
look very different depending on the protocol. They will always look somewhat different
because they are different protocols.
* Roland's refactoring of idpy-oidc will be presented as a PR soon, and that
will need to be verified against the eduTEAM work. When that's done, the code will be
in sync and all future work will be in the public space. For logging, will need to be able
to follow an individual as they move between protocols; we shouldn't let the two
libraries drift too much when it comes to logging. This needs a broader architecture
discussion. The library does not have the context of what is using it, which makes logging
very difficult. We will need to have sponsors for this work given the scale and human
resources to do this.
* Heather + Ivan to organize a dedicated call for this to determine scope.
Heather then will discuss with the board the opportunity for sponsors. Funding can
continue to be in-kind with organizations who are willing to contribute their resources
and code, and we can also start looking for sponsors to the project overall and routing
money through IdPy
* Should idpy have its own funding and development capacity? Or is the way
we're working now sufficient and appropriate for this project? At least for logging,
the restriction has been that in-kind contributors see this as important, but too big to
handle.
* FedCM - Two things here to remember - browsers are changing, and, separately, FedCM
may be a solution to help bridge the impact with the protocols. One thought is that this
is an entirely separate authentication flow. In all cases, these changes may change how
idpy libraries work. The FedCM API is likely incompatible with how we handle
authentication today. SAML would need a new binding, OIDC would need new features as well.
The idpy board needs to be aware of these changes and potentially have a voice in the
proposals and take a position. Are our sponsors willing to fund the work here? If they
don't, will we lose the opportunity to influence the work positively?
* Heather to schedule another board meeting in March after the FedCM hackathon to
discuss outcomes and next steps
Thanks! Heather