Shibboleth Developer's Meeting, 2024-03-15

Call Administrivia

09:00 Central US / 10:00 Eastern US / 14:00 UK / 16:00 FI

Calls are normally the 1st and 3rd Fridays of each month. Next call would be Friday 2024-04-05. Any reason to deviate from this?

60 to 90 minute call window.

This week's call will use the Zoom system at GU, see ZoomGU for access info.

(IAY) Do we need to have the discussion about locking and unlocking versions during releases again? The release went very smoothly this time, but we seem to have ended up in a position where although every component (including the parent) is unlocked (-SNAPSHOT) the inter-component dependencies (including to the parent) are not. I’m not sure if this is what everyone thought we intended, but it seems like it will make CI jobs work differently now than they did before the release, and that’s what I thought we were trying to get away from… “Discuss”.
IdP patch releases, particularly the plan for 4.3.2

Add items for discussion here

Implementing/finishing the final non-resolved issues for commons 3.1 and OP 4.1
Some temporary items for providing IdP 5.0 compatibility
- Logout: instructions to modify propagate/complete views
- MDDriven claim naming: Abstract OIDC transcoder contains some parts from 5.1’s AbstractAttributeTranscoder
- CSP: temporary global beans OPCSPDigester and OPCSPNonce (as shibboleth.CSP* equivalents are not yet available)
JOIDC-183: Some sort of weird dependency/classpath issue with json-web-key-generator-0.8.2-jar-with-dependencies.jarClosed
- Replacing of the JAR-file to the new destination is straight-forward, but how about deleting the one from old location?

IdP release
JWEBAUTHN-5: Add support for FIDO Alliance MetadataClosed
- Add Yubico’s metadata service to the plugin. Allowing Verification of authenticator attestations, and enhancing the registration UI
  - I guess ‘registration policies (certification levels etc)’ would be a thing to use it for in addition to the above. But not sure how far we want to go with that.
- For this to work with the default Sun PKIX implementation, a deployer would need to enable the CRL distribution points extension com.sun.security.enableCRLDP otherwise its revocation checks will fail when verifying the metadata signature (but that would affect more things on the IdP?).
Some cleanup to the RP, ready to release when oidc-commons is released.

Building Jetty.
- Some user changes come with the new build. How to document?
- Do we want to deploy the jetty msi to NEXUS or is that needless?
- Can we scare up someone to test a new build jetty msi for an existing release prior to me doing the real release
- “How to build” Documentation will need rewritten when we are done
Updated matrix testing for scripting plugin. Do we want to do this elsewhere?