Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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
    serverSystem JIRA
    serverIdf52c7d31-6eab-3f0e-93c3-231b5754d506
    keyJCOMOIDC-67

  • Jira Legacy
    serverSystem JIRA
    serverIdf52c7d31-6eab-3f0e-93c3-231b5754d506
    keyJCOMOIDC-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
    serverSystem JIRA
    serverIdf52c7d31-6eab-3f0e-93c3-231b5754d506
    keyJOIDC-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
    serverSystem JIRA
    serverIdf52c7d31-6eab-3f0e-93c3-231b5754d506
    keySSPCPP-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
    serverSystem JIRA
    serverIdf52c7d31-6eab-3f0e-93c3-231b5754d506
    keyJCOMOIDC-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

Tom

Other