Shibboleth Developer's Meeting, 2023-03-17
Call Administrivia
09:00 Central US / 10:00 Eastern US / 14:00 UK / 16:00 FI (note unusual time in UK, FI due to DST change in US)
Calls are normally the 1st and 3rd Fridays of each month. Next call would be Friday 2023-04-07. Any reason to deviate from this?
60 to 90 minute call window.
Call Details
This week's call will use the Zoom system at GU, see ZoomGU for access info.
AGENDA
FedCM Update
Attendees:
Brent
Daniel
Henri
- JCOMOIDC-41Getting issue details... STATUS
Flow tests for authorize, token and userinfo flows now cover signed and encrypted JWTs with all supported algorithms
Algorithm exclusion also covered for signing and key transport algorithms, one bug found for exclusion of data encryption algorithm
- JOIDC-142Getting issue details... STATUS
Next up
Ian
Spring Framework 6.0.5 and 6.0.6 are out, but not integrated. We expect their new signing key to be published on their web site soon, now.
John
Unable to attend today
Almost done with - SSPCPP-968Getting issue details... STATUS . A little bogged down in naming cats.
Updated Amazon Linux images to latest, including newly-GA AL2023. Completed smoke test builds on x86_64 and aarch64.
Marvin
Phil
Rod
null cleanup
Some Jira backlog
Scott
Started null cleanup on OpenSAML
Reviewing HttpClient changes
Working on SP configuration “framework” based around Application interface
Instead of reusing RelyingParty resolver, Application will do its own resolution of default or overridden RP config
Moved “default” SecurityConfiguration into RelyingPartyConfiguration
More sensible than the old approach of the resolver exposing it
Obviates the need for profile-specific security configs in most cases but still an option
Deployer declares Application beans that can reference shared or contain specific RelyingParty/Profile configurations
All the beans typically inside RelyingPartyResolver service will be in the “ServiceProviderService” (no idea what to call it yet) that exposes the Applications and other Remoted endpoints that do work
With Spring magic, no need for the current idea of a “default” Application and nested overrides. Just map requests to an Application, and share beans as needed to have defaults and special settings