Hi guys,
I’m presently maintainer/co-maintainer of 5 software packages:
- idpy-oidc
- cryptojwt (together with Jakob Schlyter)
- fedservice
- idpy-sdjwt
- openid4v
All of them part of Identity Python or soon to be part of Identity Python.
As everyone else I’m not getting younger so I’ve decided to bring down my involvement in the maintenance of these packages.
Jakob Schlyter if prepared to take over the responsibility for cryptojwt.
Apart from that there is no obvious choice. So you/we have to start looking.
My expectation is that 6 month from now I will be a contributor but not a maintainer.
— Roland
Hello IDPY Board members!
It looks like most of us will be at the TIIME meeting in Copenhagen? Is anyone NOT planning on being there? I'd love to have a f2f idpy board meeting if possible!
Thanks! Heather
Hello idpy board members!
On our annual call earlier this year, we discussed meeting after the R&E/FedCM Hackathon to determine what impact (if any) the outcomes of that meeting would have on idpy.
First off, the meeting was quite successful in that the group came up with two proposals that might be viable and allow browser to distinguish between unconsented tracking and a federated authentication flow without messing with the protocols involved. You can read the proposals here:
https://github.com/fedidcg/proposals/issues/4https://github.com/fedidcg/proposals/issues/5
The group did not have time to really dive into the proxy use cases; we will come back to that after we’ve received feedback on the initial proposals. It does sound like pyff might be a part of at least one if not both of the proposals; Leif, Sam (Google) and others will look at that as part of early prototyping to kick these proposals around a bit.
Beyond that, I don’t think the board has much we need to do at this time. If you have any questions or are interested in following the work, you can either join the FedID CG or the new REFEDS working group (which will focus entirely on the R&E use case).
Please let me know if you have any questions!
Thanks! Heather
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
Hello idpy Board members!
As a reminder, our annual call is scheduled for Tuesday, 7 February 2023 at 09:00 UTC -8. If you did not receive the calendar invitation a few weeks ago, please let me know!
Our draft agenda and a few slides are available online (I originally sent this with a PDF but that made the mailing list software reject the message as too large)..
Thanks! Heather
Hello idpy Board members!
Our board slate for 2023 remains unchanged. Thank you to everyone who agreed to continue as board members!
• Heather Flanagan (Spherical Cow Group)
• Ivan Kanakarakis (SUNET, lead architect for Satosa, pySAML)
• Leif Johansson (SUNET)
• Roland Hedberg (independent, original developer and architect)
• Christos Kanellopoulos (GÉANT)
• Chris Whalen (individual contributor)
• Mike Jones (Director OIDF, author of OIDC and JWT and OAuth)
With that done, we need to get our annual board meeting on the agenda. I have put together a doodle poll to try and find a time next month. Please fill out the poll by Monday, 23 January 2023.
https://doodle.com/meeting/participate/id/enRxyole
Thanks! Heather
Wrongly sent only to Christos.
> Begin forwarded message:
>
> From: Roland Hedberg <roland(a)catalogix.se>
> Subject: Re: [Idpy-board] satosa - oidc
> Date: 24 October 2022 at 15:20:06 CEST
> To: Christos Kanellopoulos <christos.kanellopoulos(a)geant.org>
>
> Christos,
>
> It goes without saying that I’d prefer us to use the eduTEAMS implementation.
> Given the effort you have put into it, it’s at the top of the list.
> But, we need it to be public.
>
> I’d prefer that you would just publish what you have and we can go from there.
> That you have a private branch where your higher demands on software quality is met is not a problem to me.
>
> If you plan to wait until idpy-oidc has stopped changing then you will have to wait forever. Or at least until I stop being
> responsible for the package.
>
> There is always going to be new RFCs, Internet drafts, OIDF standards and industry specifications that we want/need to support
> if we want to be noteworthy. And that forces us to add/rewrite/refactor idpy-oidc.
>
> I try to keep people informed about such changes at the bi-weekly idpy meetings.
>
> The standards I’m working on right now are CIBA and OIDC Federation. Both of which demand some basic changes..
>
> Please send me an invite to your Thursday call and let's go from there.
>
>> 24 okt. 2022 kl. 14:56 skrev Christos Kanellopoulos <christos.kanellopoulos(a)geant.org>:
>>
>> Hello Roland,
>>
>> Of course, we do not have to use the eduTEAMS implementation. Having said this, once again we are hindered by the the changes in the underlying libraries. In September the development team has migrated the frontend to the new OP library, but our testing has showing that the new implementation is not stable for production use. At this point we are not sure whether it is a problem in the OP libary or the way it was integrated. I believe we will have more information on Thursday about this. Perhaps Ivan can say more about this.
>>
>> We have already given access to a number of people in the private repository, but we have not seen any contributions yet. I would be happy to add you and/or other trusted people in the private repository and also invite you in our Thursday call if you have the time to help in realising a stable version that we can open source.
>>
>> Christos
>>
>> On 24 Oct 2022, at 14:34, Roland Hedberg wrote:
>>
>>> Sorry for the confusion! I meant satosa-pyoidc not satosa-oidcop.
>>>
>>>> 24 okt. 2022 kl. 10:23 skrev Roland Hedberg <roland(a)catalogix.se>:
>>>>
>>>> Hi!
>>>>
>>>> This situation with EduTEAMs not releasing their satosa-idpy-oidc integration is really hurting IdPy.
>>>>
>>>> I think we should give up on EduTEAMs and instead bring in Giuseppe’s implementation.
>>>>
>>>> As long as we keep satosa-oidcop on line as the ‘official’ IdPy SATOSA-OIDC package we loose a lot of
>>>> help in making our own OIDC implementation better.
>>>>
>>>> — Roland
>>> _______________________________________________
>>> Idpy-board mailing list -- idpy-board(a)lists.sunet.se
>>> To unsubscribe send an email to idpy-board-leave(a)lists.sunet.se
>>
>
Hi!
This situation with EduTEAMs not releasing their satosa-idpy-oidc integration is really hurting IdPy.
I think we should give up on EduTEAMs and instead bring in Giuseppe’s implementation.
As long as we keep satosa-oidcop on line as the ‘official’ IdPy SATOSA-OIDC package we loose a lot of
help in making our own OIDC implementation better.
— Roland
Attendees:
Leif, Christos, Roland, Ivan, Mike, Heather
Regrets:
Chris
Notes
1. Agenda Bash
2. Board Nominations
a. 3 slots, currently filled by Leif, Christos, and Heather, will be open
• Note that Heather’s role is also “At-Large Director of Identity Python"
• Heather to send a note to REFEDS about the board nominations as well as to idpy-discuss
3. Approving updated policies
a. idpy project policy - https://github.com/IdentityPython/Governance/blob/master/idpy-projects.md
A. Should we be more specific about how much the tests should cover? Common numbers are 80% coverage. Yes, will add that.
B. Add a note about IPR and licensing, saying what's expected and pointing back to the main statutes as the canonical source
C. Should we add that we want a direction where all dependencies are maintained within idpy? Where strategic direction is more solidly align? We are still at a stage where we still maintain flexibility. We should be a supportive framework to get the job done than legislate what it means to be a project.
D. Add a note about incident handling
b. idpy incident response policy - https://github.com/IdentityPython/Governance/blob/master/idpy-incidentrespo…
A. Main changes was to explicitly take advantage of GitHubs incident management tools
B. See also the new FAQ: https://idpy.org/security/
c. Heather will send the revised policies to idpy-discuss and to Commons Conservancy
4. AOB
Thanks! Heather
