The IdP 4.1 release was of course completed last month and has been a success so far, though it's early. Only one major regression has come to light and it's relatively easy to work around for now. I'm in production with it since last week without any problems so far. I posted a how-to documenting what I did to clean up my system after I did the upgrade. I did do this work prior to my MTP of the upgrade, but I wouldn't have hesitated leaving things alone until later if I'd been under more time pressure.

I'm particularly happy with the sheer volume of work we accomplished in only 12 months, made possible by the additional resources the increase in membership over the last few years has provided. The quality of the release is as high as we've ever had but with substantially more work done at the same time. The new plugin model should help increase the speed of feature delivery and enhancements with greater security isolation.

After taking a bit of a break, we are focused right now in responding quickly to issues and a few bugs that were left open from before the release and are expecting to deliver the first patch for the IdP itself as soon as it makes sense to do so. The end of April is a reasonable guess but probably will depend whether any additional issues are reported.

An SP security update was shipped to disable an ill-advised feature that was added a long time ago without a lot of clear justification. My best guess right now is that the main use case for this was the (very rarely used) Form SessionInitiator, which while not formally deprecated...probably needs to be deprecated. This ties a bit into the ongoing discussion about the future of the SP, which has been somewhat on hold while 4.1 was being wrapped up but will be front burner very shortly.

We will be starting a discussion in earnest about the SP on this Friday's development call, and I produced a design write-up summarizing the current codebase and some of the considerations and possible directions we could take, if we do anything. My major concern after completing that draft is that no amount of redesign is likely to result in a practically maintainable amount of code. We can reduce risk and address some of the concerns that triggered this conversation, but in the end "can't find anyone to maintain it" is a much bigger problem than just about anything else and I'm not sure if we can reduce the footprint enough to overcome that. That's a question the membership and Board together will have to contend with.

Browser not supported