Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Shibboleth Developer's Meeting, 2023-12-15

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 2023-12-15. Any reason to deviate from this?

60 to 90 minute call window.

Call Details

This week's call will use the Zoom system at OSU, see http://shibboleth.net/pipermail/dev/2023-December/011148.html for access info.

AGENDA

  1. Javascript encoding - any simpler alternatives to OWASP?

  2. Plugin testing - per IDP-1712

Attendees:

Brent

  • I’m on vacation this meeting and also next meeting, assuming it’s still Fri Jan 5 (back at work on Mon Jan 8 )

  • OSJ-391 - Getting issue details... STATUS

    • Done unless we find any issues

      • Scott will review usage of the relevant class to understand how we might provide a simple means of adjusting things for deployers (if there isn’t already one).

  • OSJ-392 - Getting issue details... STATUS

    • Nominally done. Will do some final review and possibly some more unit tests in early Jan.

Daniel

Henri

  • JOIDC-186 - Getting issue details... STATUS

    • Drafted an approach that seems to work:

      • Refresh token type in profile configuration

      • Token endpoint can be wired with a customisable Map of functions (keyed with refresh token type) that encode RefreshTokenClaimsSet into whatever String

      • Validating endpoints (token, introspection, revocation) can be wired with a list of functions that decode String back to RefreshTokenClaimsSet

Ian

John

Marvin

Phil

  • Just working on the WebAuthn plugin

    • Working registration and authentication

    • The code is a mess. Still not looked in detail about storage API implementations

    • Thinking about the different use cases:

      • Passkeys (discoverable credentials). No username, select credential on the authenticator and send that back to the IdP. Requires ResidentKey, and authentication I think requires UserVerification (UV) and UserPresence (UP) checks. Working

      • Passwordless. Username initial input. Does not require ResidentKey, but still requires UP check and UV. Works, but I do not have an initial username input page yet.

      • 2FA. Run after a previous factor. Does not require ResidentKey, requires UP check but not UV. It does not set this options correctly, currently (although shouldn’t be hard to signal this).

    • The plugin bundle is working, although it contains a ‘selection’ view-page to choose between keys or password which probably is not needed in the final product, need to think about that.

      • Maybe make something alpha more public mid Jan.

Rod

  • Nothing.

  • Been thinking about plugin/IdP version testing IDP-1712 - Getting issue details... STATUS

Scott

  • 5.1 backlog

    • IDP-2057 - Getting issue details... STATUS

      • Works, but so ugly, this is why I never tried it until now.

  • Some review of Duo as passwordless solution, still have to mock that up

  • IDP-2212 - Getting issue details... STATUS

    • This is a repeat of something Spring supposedly fixed, and I haven’t reasoned out a likely cause for a 5.0 system now to exhibit it, hoping reporter comes back with something.

Tom

  • IDP-2175 - Getting issue details... STATUS thanks Scott

  • IDP-1712 - Getting issue details... STATUS jenkinsfile “strategy” needs review

Other

  • No labels