Page Comparison

...

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

AGENDA

...

1. FedCM Update

Attendees:

Brent

• Any more questions etc on HC 5 update?

Daniel

• Nothing to report.

Henri

• Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JCOMOIDC-67

• Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JCOMOIDC-41

  • 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

• Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JOIDC-142

  • 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

  Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key SSPCPP-968

  . 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

• RP tinkering.

  • allow login_hint function in the profile configuration

  • Allow UserInfo request by POST as well as GET

  • Cleanup the IDToken and UserInfo request decoders

• Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JCOMOIDC-66

  • Creating interfaces, throwing them away, creating more interfaces, and making some diagrams to avoid more confusion.

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

...