Shibboleth Developer's Meeting, 2022-02-04

Call Administrivia

09:00 Central US / 10:00 Eastern US / 15:00 UK / 17:00 FI

Calls are normally the 1st and 3rd Fridays of each month. Next call would be Friday 2022-02-18. 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.

https://shibboleth.atlassian.net/browse/JOIDC-11?focusedCommentId=32046
1. Stumbled on a complex set of registration trade-offs after starting on encryption support.
2. Related is whether we actually intend to support unverified profile configurations, which currently break due to assumptions that client metadata is present.

https://shibboleth.atlassian.net/browse/OSJ-347
- As suspected, these tests aren’t doing much except checking for a successful fetch. Should we switch to an InCommon target? Do Scott’s changes to proxy port 9000 to /mdq change this at all?

https://shibboleth.atlassian.net/browse/JOIDC-72
- Also related to the patch (3.0.4) released this week: only the desired/supported claims to be stored during the dynamic registration
- Deployers can choose e.g. request_uris
https://shibboleth.atlassian.net/browse/JOIDC-21
- Metadata policy resolution via file or remote endpoint now works
- TODO: JWT access token, polishing and unit testing

Continuing to chip away, very slowly, at the spec churn required to add Amazon Linux 2022 support to cpp-linbuild

RP progress
- Access Token exchange and verification
- Id_token JWT validation hooked up according to spec. One or two things need review.
- Transcoders plugged in to map claims to IdPAttributes, but see below for missing functionality.
- Work on UserInfo request/response
RP issues/questions remaining
- Should we always try to fetch claims from the UserInfo endpoint and aggregate with those from the id_token? or just if enabled in (say) the profile config (or conversely allow to disable in profile config). It is not clear to me from the spec. how you would decide automagically.
- Attribute filter - similar to the SAML proxy
- Support for authentication request params as requestObjects. Would require a JWKS endpoint if allowing asymmetric keys (and associated key handling).
- JWT Decryption support
- client_authentication to the token endpoint. Only supports client_secret_basic atm (post not that different, but JWT would be).
- - This would be non-trivial to me, there are plenty of other remaining issues with the RP so happy to add a placeholder action for this and substitute in the TrustEngine validation when complete. (Happy to look at it if needed, but would take some time)
- - need to add decode logic to convert JSONObjects to IdPAttributes. Long term maybe it could be based on Maps rather than the minidev JSONObjects.

When do we want to move the lowest version?
Getting rid of internal shib-thirdparty repo / -P centralDisabled
- All nightly build do a post build signature check of their local repository check except
  - XMLSecTool - This uses a more complex (better?) assembly which bring in more stuff. Under way.
  - IDWSFClient - can we pull this from the night build? (I have keys for it, but why add clutter) Also, it needs totally orphaned not-yet-commons jar
  - The depcheck projects
  - jetty94-dta-ssl-nightly, trustany-ssl-nightly disabled. What to do about this.
  - jetty-base - no nightly build, but the windows variant does have some checking
  - Anything else?
- Need to make sure that versions:set doesn’t import anything else we don’t know about
  - Anything else being used during a build?
    - PS. site site:stage is used to build site and API docs, not sure if that needs or is part of verification (it passed fine for the last build). Unless a rogue plugin adds some malicious JS to the API docs.
- My belief is that with the above bullets fixed/understood/waived we are good to go, Do we agree
Jetty-10 Windows. I’m going to wait until the jetty-base is stabilized and documented and then do the Windows stuff (noting the building the installer also has to change). This means that the current plan is to ship 4.2.0.0 with Jetty 9.4-44. I’m happy with that because we can slipstream out a 4.2.0.1 whenever we feel like it.

- Finishing up introspection/revocation flows and tests
  - Both legacy and JWT tokens validated with new claims validators
  - Fixed signature verification to allow for non-JWK credentials
  - Added compliant client_id claim (fallback to legacy claim name used now)
  - Flows are usable (with proper authentication) by either the client_id or an audience of the token (original use cases addressed by the former)
- TBD documentation and the encryption support plus RP config for whether to issue unencrypted tokens
- Looks like combination of Spring defect + Java HashMap implementation quirk
- Hopefully Spring fix will limit future occurrences
- Eclipse and testbed seem to run ok under 17
Jetty 10
- Found undocumented but supported request log hook for sending to SLF4J, simplest way to get request logging via logback
- We can ship it with either slf4j/logback 1.x or 2.x, our choice