2015-08-07

Owned by Scott Cantor
Last updated: Aug 07, 2015
2 min read

Shibboleth Developer's Meeting, 2015-08-07

Call Administrivia

10:00 Central US / 11:00 Eastern US / 16:00 UK

Calls are normally the 1st and 3rd Fridays of each month. Next call would be Friday 2015-08-21. Any reason to deviate from this?

60 to 90 minute call window.

 

Call Details

This week's call will use the Lync system at OSU. To participate, call:

  • +1 (614) 688-1800 (please use if possible)
  • +1 (800) 678-6114 (use only if you're charged for the 614 number)

The Conference ID is: 738127#

International participants should be able to access the 800 number without charge through Skype.

OPEN ACTIONS

  1. Scott will draft a note to REFEDS proposing that we do this in future releases and make this a formal, community consensus call to make this happen.
  2. Scott will determine if we have any hidden projects needing git conversion.

AGENDA

Add items for discussion here

  1. Approve draft of Java Product Version Policy.
  2. Target Spring 4.1.x or 4.2 for next release?
  3. Java Version 7 support/require policy?
  4. Next steps to get local storage done?


Attendees:

 

Brent

Mostly working on delegation work.  Working on actually wiring up a Liberty SSOS flow, figuring out authN and c14n subflow usage.

Should plan on a v2 bugfix release for soon-ish the JSSE getPeerHost() issue.

 

Daniel

Nothing to report.


Ian

 

Marvin

Nothing to report.

Rod

 

Scott

Pushed out a quick library fix for a PKIX bug, Windows service release process seems to work ok.

Finished work on IDP-748 with minimal consent management API context to avoid cross-flow query string dependencies.

Reviewed SWITCH design notes on SPNEGO

Jetty 9.3 issues, docs still need to be updated. Another fix for the trust store type bug is done, need to test in a nightly release so it actually gets fixed in the next patch.

Tom

Notes on Version Policy :

  • I think the package name should be dispositive (i.e. api vs impl) always, because the package name, not the multi-module project name, is what appears in XML configuration files. So, I think I suggest reworking the following :

Note that in contrast to the single-module case, the package name of a class is not dispositive in regard to its status, though as a general rule the package names in an API module will not likely contain a segment named "impl" to avoid confusion.

  • Parent POM version policy ? Maybe include a note stating that all of our projects should have the same parent POM version when released.

Notes on Spring 4.1 vs 4.2 :

Notes on Java 7 policy :

Updates :

  • Some related work for other folks
  • Back from out of town : box patching, Sauce tests

Next steps for local storage :

  • Git questions, push changes from personal sauce branch to master, cutover to git, configure tests against browsers without local storage, work on plugging local storage flows into the Java impl, TMTOWTDI. 

 

 

 

 

Other