Page Comparison

Smaller OIDC/OAuth Enhancements

Ongoing

Additional features for the OIDC OP plugin, initially focused on use cases adjacent to OIDC specs, or adding optional OIDC material, and some enhancements to provide some additional OAuth functionality. See JOIDC project in Jira. Some enhancements may depend on member interest/demand.

SP Packaging Automation

Ongoing

AWS-based process for automating SP packaging, at least encompassing RPM platforms. This will conincide with changes to the packages we produce. The initial work is completed but work is ongoing to allow for CI in AWS.

FedCM

Probably through 2025

The non-cynical take is that we are investing time in trying to work with Google on altering their plans for the browser so as to do as little harm to existing identity standards as possible. The cynical take is redacted (for now) to avoid guaranteeing they won’t listen to what we say.

Passwordless Features

Q4 2024

Research and implement support for emerging passwordless authentication features such as WebAuthn. Our problem remains the lack of a viable path to building a token management solution to support the core technical features, which are tractable but do not offer a deployable feature. The estimate entails the work that a "complete" solution might takeThis includes parallel work on both a Duo-centric and a native WebAuthn plugin solution, along with a bare bones UI. Future work will include a more full-featured UI that includes other requirements in addition to WebAuthn management.

Centralized Discovery Service, version 2

Developing the next major version of the Centralized Discovery Service product. This includes significant internal code refactoring, changes in configuration files to align with the IdP, and production of JSON metadata feed used by the embedded discovery service.

After consultation with members, the decision was made to park any work on this codebase and allow the original version to sunset with the V2 Java code base.

IdP Support for WS-Federation

Version 1.3 of the IdP had support for Microsoft's proprietary ADFS v1 protocol. This was not brought forward because it didn't seem to be used by very many deployers. It comes up from time to time but supporting this would conflict with our desire to drop the SAML 1.1 code from the project to reduce technical debt.

IdP OTP SMS Authentication

SMS seems to have rightly lost a lot of supporters given its security flaws and cost. Work on other tech makes more sense now.

Token Binding

Support for the emergent TLS Token Binding extension in our SAML implementations. This is dead in light of Google having pulled Chrome support for Token Binding.

SAML-ECP GSS-API Mechanism

Specification of a browser-less GSS-API mechanism for SAML based on ECP is largely complete with stable drafts available. Completion of the drafts depends on implementation feedback. A mechanism would need to be developed in C++ with C linkage to the mechglue layers of at least MIT and Heimdal GSS libraries. Some prototype work on this was done by NCSA staff with ISOC funding.

At this point the work seems to be largely overtaken by other simpler approaches and in any event the project lacks the C++ development resources long term to seriously consider something like this.

SP Availability in Fedora

Effort to produce SP packages compatible with Fedora standards and to get them accepted into the Fedora project. This has unknown implications on Red Hat packaging. This was a request from the Moonshot team. GIven the state of the SP and the state of Red Hat vis a vis the Linux community, this is parked regardless of the effort involved.

Resource Registry, version 1

Various federations have software that devolves management of IdP/SP information to people closer to those entities. SWITCH's Resource Registry is the canonical example of this. People have made requests that such a tool be available from the Shibboleth project. Currently each federation has something that might be considered a resource registry and each is very different so it's unclear that a single code base could ever cover all, or even the majority, of these uses.

Conformance Testing

Kantara (formerly Liberty) does (or did) some conformance testing of SAML implementations against various conformance testing suites, particularly eGovernment profiles that the project has participated in the development of. Vendors have expressed interest in Shibboleth participating at times, though not recently. There is a lack of demand from our community, and unwillingness to devote core team resources to the effort. We also support many things we think are more important but aren't part of the testing, and thus do not believe as a technical matter that the result is meaningful to customers, other than to rubber stamp poorly designed SAML implementations by competitors.

SAML 2.1 Standard

Effort to update and revise the SAML 2.0 standard within the OASIS SSTC. The work at the SSTC has essentially been put on hold due to lack of volunteers to work on it. Politically it would be quite difficult to make a lot of the sorts of changes that would benefit the project, particularly substantive changes to the conformance criteria since it would be impossible for most vendors to meet and none of them would ever want to do the work necessary to change that.

Notably, the SSTC has also ceased to be, so this would require re-chartering a new TC and rejoining OASIS.

TestShib NG

An effort to create a new TestShib software package and platform. Of late, http://samltest.id seems to have filled this niche well enough, and there’s also https://github.com/OpenConext/Mujina so it’s not really conceivable we would duplicate all thatThe last attempt to build this went away again, illustrating how non-trivial it is to sustain something like this…it’s more likely this would be done as part of building out more IdP features in support of testing.