Page Comparison

...

1. Propose we release updated 17 parent and re-lock everything to that to stablize javadoc mess

   1. Unless we’ve decided to start leaving everything unlocked and letting dependency updates bleed into all the CI jobs?

   2. If there are additional release profile changes we want to make, might be a good time.

   3. Decision is to leave it all unlocked for now, and we’ll assume a full re-release next time. Patch-compatible dependencies can be updated at this point.

2. Overall backlog of new work / release planning

   1. Confirmed, no outstanding V4 work right now, work on V5 is primarily feature (5.1) stuff so targeting maybe early December for that along with some minor updates to plugins for features there.

3. Board update

Attendees:

Brent

• Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key OSJ-388

  • tested their changes and our update is ready to go. xmlsec 3.0.3 was released Thurs (yesterday).

  • need to update xmlsec dep to 3.0.3 - wrt to the agenda topic: do in java-parent or override in opensaml-parent, etc?

• Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key OSJ-391

  • Can default these in TLSSocketFactory impl itself, and can be overridden either at factory-level or per-request if necessary (the latter most likely)

    • Minor risk is if we have any gaps where we don’t have an HttpClientSecurityParameters that can be supplied to override

  • Should extrapolate to cipher suites also? Maybe hardening the protocols would already limit the “bad ones” inherently.

• Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key OSJ-392

  • I have observations not expressed in the issue yet. No resolution yet. Summary:

    • I think the issue isn’t use of xsi:type per se, it’s any case where you don’t have XMLObject support for an element/type in your runtime environment, and you get an XSAny.

    • If I remember XML Schema esoterica correctly (maybe not), any element’s content model can be subtyped - it’s just not common. I.e. RoleDescriptor isn’t special.

      • <KeyDescriptor xsi:type="brent:MyAwesomeKeyDescriptorType"> - where that type is a subtype of KeyDescriptorType.

      • Is a theoretical concern, maybe we just ignore and focus on the “expected” extension points.

Daniel

• Nothing to report.

Henri

• Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key JOIDC-13

  • Propagation: found a way to control the front-channel propagation result in UI

    • The propagation flow calls the RP’s front-channel logout URI in yet another iframe, but proceeds itself into the similar end-state as back-channel does

  • RP-initiated logout:

    • Mostly done now, also including some initial flow tests (first flow test for me with a flow resuming from a view)

    • Some fine-tuning needed for id_token_hint validation (first case when OP is validating its own signatures)

  • TODO

    • Finish unit / flow tests

    • Tests against the conformance suite

    • Documentation

...

• Jira Legacy
  server System JIRA serverId f52c7d31-6eab-3f0e-93c3-231b5754d506 key GEN-333

  
  Problem being bin/install.sh is not being made executable if the sign-snapshots profile is active
  Cause seems to be that Maven plugins (in this case maven-antrun-plugin) are called once with multiple executions
  So activating the sign-snapshots plugin calls make-files-in-bin-executable after the assembly is built
  Workarounds ? maybe use the assembly plugin to change the filemode
  

...