Shibboleth Developer's Meeting, 2022-01-21

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-04. 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

1. Noted while moving monitoring to OSU…MDQ beta thingy is open to world for tests. Maybe switch tests to InCommon MDQ for now? Should be embedded instead but in lieu of that… [Outcome: seems like a plausible thing to do, Brent opening a Jira issue.]

Attendees:

Brent

Daniel

Henri

• https://shibboleth.atlassian.net/browse/JOIDC-61

  • Polishing phase

• https://shibboleth.atlassian.net/browse/JOIDC-72

  • New feature realized during the metadata policy testing (above)

  • Current register-flow only adds “known” metadata claims to the response and stored metadata

  • Metadata policies are not limited to the same set of claim names, so any additional claims specified in the policies should be considered as “known” by the OP

• https://shibboleth.atlassian.net/browse/JOIDC-21

  • CLI: metadata policies to be fed via --metadataPolicyURL option

  • Admin flow resolves the metadata policy via metadata resolvers (no need for caches though)

Ian

John

• No updates worth mentioning

Marvin

Phil

• • Using dynamic client metadata to configure proxy RPs to OPs.

• Various RP improvements. Authentication Response decoding and validation.

  • Moving onto token exchange for auth_code flow. Should support other flows up to this point.

  • Testing against the OIDC certification test suites (obviously we do not have full end-2-end yet, but still neat).

• Maven wars.

  • Better than Star Wars, but not as good as Star Trek.

Rod

• Odds and Sods

Scott

• • Token flow is working minus encryption support, both opaque and (I think compliant) JWT tokens

  • Client ID → c14n after login → sub claim in token automatically (client_id also there)

  • Scope and audience claims come from the attribute resolver - resolution context extended with a subcontext (hook added in 4.2) that contains the requested/validated scope and whatever resource values are requested by the client for ease of access during resolution

  • Any released attributes encoded to non-reserved claim names are added to JWT automatically (i.e., don’t release what you don’t want included)

  • Still a few weeks of work left to do

Tom

• Jetty 10

  • pushed 10-testbed-eclipse branch

  • logback-access replaced with requestlog, file name and format is by default different

• • redirects in place

  • deployers please see <altReleaseDeploymentRepository/> on
    
    

Other