November 2024 Update

The latest feature update to the OIDC OP plugin is available and contains some significant bug fixes along with the first iterations of DPOP and PAR support (for those tracking all the new-ish RFCs out there, an ever-growing list). We’ve donw quite a bit of work internally on automating the process of running the OpenID conformance suite and integrating the plugin into our testing infrastructure. The next big development cycle will include the initial work on OpenID Federation, some of the funding for which is coming from a member in the consortium to accelerate the development timeline.

The WebAuthn plugin saw another release candidate and we are in the final stages of getting a V1.0 of that out prior to TechExchange next month in Boston. Testing feedback has continued to greatly help with polishing that first release.

A plugin for installation and upgrade of Jetty continues to see further development but we have some distance to go before that wll be officially available as we work out the story for upgrades, patch versions of Jetty, and various issues specific to Windows or Linux. We will eventually be transitioning to this approach from the current Windows installation package for Jetty. Testing it requires a snapshot of the IdP as it will require V5.2 to work, but people may inquire on the dev list if interested in playing with it.

Work on various bits for V5.2 is ongoing in between (or motivated by) things we need for other work in development but there isn’t a timetable for it at the moment. A new version of the Spring Framework will be out shortly, and that will be one of the triggers to start thinking about when we might try and ship it.

I completed work refreshing the SP, releasing a V3.5.0 to fix a couple of small issues and more importantly to push out minor revisions of a number of dependencies, particularly on Windows, to get things more up to date. The latest versions of curl and OpenSSL (at time of release) were tested and used in the build, along with a new major forked release of xml-security-c which is now solely controlled by us for our internal use on the project. This 3.0 release stripped out a lot of unsupported code and features from the library so it is no longer so general purpose in nature. In the event there are third-party forks of the original Apache code, we hope that it will be done under a different name to avoid any confusion or conflicts.

Finally, work on the SP redesign has shifted from Java to a “teardown” of the main branch of the SP to strip out as much code as possible and get it into a state where new code can be added back in to start adding functionality needed for the new design. Part of that work included identifying a new unit testing framework to use, the plan being to be able to unit test as much new code as possible before needing to try it out in “anger” against the new Java code. Hopefully testing each independently will limit the problems when the two begin to be tested together, which is some way off.

I also undertook a planning exercise to again review the design and produce a breakdown of all of the work needed to produce the new agents, which is at Native Agent Design/Development Plan. One of the uses for that will be assisting us in potentially contracting for some of that work by third parties to share more of the workload (and knowledge of the code) beyond just myself, but it’s also just helpful in breaking down a large number of tasks and subtasks before they go into Jira.

Initially I had been planning to drop the use of the Boost library, as we move to more modern versions of C++ that should obviate a lot of what we used it for, but it appears as though it may offer a couple of significant benefits. One is a seemingly solid unit testing framework that I’m already playing with, and the other is a configuration abstraction called a “Property Tree” that supports both XML and Windows-style ini file parsing and is usable without a link-time dependency, keeping the build simple. The goal remains to reduce the use of XML as much as possible, but there are portions that work much more simply as XML so having a local option for that without adding runtime dependencies is very helpful.

A lot of the initial “new” work will consist of testing out this configuration API and seeing whether it can be swapped in for the more pervasive use of XML currently. I find working from the configuration “out” is also a helpful way to shape the design anyway.

There probably won’t be a full blog entry for December due to TechExchange, where I will be giving the usual project update in person.