Shibboleth Developer's Meeting, 2024-05-17

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 2024-06-07. 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.

Add items for discussion here

JOIDC-201: Support for OAuth 2.0 Demonstrating Proof of Possession (DPoP)Resolved
- JCOMOIDC-113: TrustEngine implementation for token derived credentialsResolved
- Basic DPoP access token use case more or less covered now with token and userinfo
  - If public key thumbprint is stored inside our token claims sets, DPoP access tokens are issued
    - thumbprint may be fetched in PAR or authorize -flows, or via DPoP proof
  - Profile configuration option to control requirements & claims validators
- TODO
  - nonce-management
  - refresh token binding (public clients)
  - introspection and revocation support
JCOMOIDC-115: Update Nimbus oauth2-oidc-sdk into 10.15Resolved
- Upgrade is needed for the DPoP metadata-flag support: https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/issues/467/support-for-dpop_bound_access_tokens-in
- Before upgrade, we need a solution for a problem described in: Non-URI resource indicators

May need to miss meeting, I have some people coming to fix our drains…
MDA 0.10.0 released. Huzzah!
- Some downstream work to be done before I’m really finished.
- main is now 1.0.0-SNAPSHOT and there’s a maint-0.10 branch.
- I don’t see value at present in nightly and multi jobs on the maintenance branch, but will create them if needed.
New Spring Framework releases (including a new 6.2 milestone) available, will integrate those.
Next up after that: Git conversion of the Santuario repository

JWEBAUTHN-12: Add an access control predicate for guarding against username changesClosed
- Add a guard to check a user who has already registered a webauthn credential can not bypass webauthn authentication when registering a new one (under certain MFA configurations that allow some kind of alternate authentication to be used to bootstrap credentials).
  - In other flows, this is covered by requesting the correct authentication method/class principal etc
  - Is hard to think of all the options for trying to bootstrap the initial key, but I’ve tried to improve the documentation around this.
JWEBAUTHN-11: Pull identity information from the AttributeResolver during registrationClosed
- Pull user.id, user.name, and user.displayName from the attribute context for use when registering a new credential
JWEBAUTHN-8: Add an admin flow suitable for an sys admin to manage other users keysClosed
- Added an admin flow for admins to manage other users credentials. Only supports searching and removal for now.
Finishing the docs
3rd Alpha was released. Will get a beta out before the end of the month. Hopefully not long after that for a v1.
Will produce a few videos so it is easy for others to review

IDP-2288: Injection of beans into BeanPostProcessor causes Spring warningsResolved
Example script to report on project status based on a CSV file
- http://shibboleth.net/cgi-bin/projstatus.cgi
SP design and prototyping
Conceptual model is visable in https://git.shibboleth.net/view/?p=java-plugin-shibd.git;a=blob;f=sp-conf-impl/src/main/resources/net/shibboleth/idp/module/conf/sp/agents.xml;h=6f5f1171a2ca15130f8cd009a0eee2e7e678428d;hb=HEAD
- Agents have a unique ID and contain Applications.
  - Agents will be associated with some form of identity/credential to secure requests.
  - Applications have an ID that is unique within a given agent and expose a RelyingPartyConfigurationResolver to resolve the correct RPC and PC for a request.
- Every layer allows override of the agent’s entityID, client_id, etc. The protocol identity is thus maintained solely in shibd and is no longer a concern of the agent. The shibd deployer is the one that associates Applications with protocol settings and ensures metadata given to IdPs, if it’s needed, is correct.
- Pluggable rules control the virtual hosts associated with an agent/application, similar to what supporting unregistered OIDC clients might look like.