Note: This draft has been published for consultation. The final version is expected to be published at this same location on 1 August 2025.
Following a period of consultation, and effective from 1 September 2025, SAFIRE has made several changes to its identity provider & service provider requirements, as well as its metadata registration practice statement.
These updates share a common goal: raising the baseline — the minimum set of standards required for participation in the Federation. While the 2021 baseline changes focused on relevance and interoperability, this new set aims to improve cybersecurity and build greater trust among federated entities. Trust, in particular, is a key differentiator for global academic federations. These changes are also aligned with the REFEDS Identity Federation Baseline Expectations and eduGAIN’s current best practices.
A summary of the changes, along with their implementation timelines, is provided below. The corresponding updates to the identity provider and service provider requirements, as well as the metadata registration practice statement, are all versioned as v20250901.
Changes affecting identity providers
Attribute support
Support for the following four new attributes has been added to the Federation. These are now formally supported under the revised baseline:
From 1 September 2025, the subject-id attribute (a general-purpose subject identifier) will become a mandatory attribute for all new SAML identity providers. This, in turn, will enable the pairwise-id attribute, which is generated by the Federation when an identity provider includes a valid subject-id.
While this requirement will not be applied retrospectively, existing identity providers are strongly encouraged to review their attribute release policies and release as many of the optional attributes as possible.
In particular, subject-id and eduPersonAssurance are widely used in REFEDS attribute release profiles. These attributes are becoming increasingly important for global research services, which are prioritising the trustworthiness of personal information received from third parties, and raising their own baselines accordingly.
A future baseline change in SAFIRE is likely to make both subject-id and eduPersonAssurance (or their equivalents in other protocols) mandatory for all identity providers.
Sirtfi framework mandatory
The 2021 baseline required identity providers to include a <md:ContactPerson> element aligned with the REFEDS Security Contact Metadata Extension. While adoption of the full Sirtfi framework was encouraged, it was not required.
From 1 September 2025, all new identity providers must complete a self-assessment and be in a position to attest their compliance with Sirtfi framework as a condition for participation.
Existing identity providers will be expected either to complete a self-assessment enabling them to attest Sirtfi compliance, or to submit written reasons explaining why they are currently unable to do so. For those who have not yet attested, the following grace period applies:
-
1 March 2026: Identity providers that have not self-attested Sirtfi compliance will no longer be published to eduGAIN.
-
1 April 2026: Providers that remain non-compliant will be considered in breach of §6 of the Participation Agreement and may be suspended from the Federation.
-
Where written reasons are accepted, these will be published in lieu of a self-attestation of compliance. Acceptance of such reasons will defer enforcement of the above requirements for a maximum of one year.
This change links to additional requirements explained in the section on security vulnerabilities and outdated software.
Changes affecting service providers
Security contact mandatory
Since 2021, service providers have been encouraged to include a <md:ContactPerson> element conforming to the REFEDS Security Contact Metadata Extension. In practice, most new service providers have complied.
From 1 September 2025, this becomes mandatory for all new service providers.
Existing service providers have until 1 November 2025 to update their metadata accordingly.
As with identity providers, inclusion of a security contact is a prerequisite for adopting the full Sirtfi incident response framework, which is strongly recommended.
Changes affecting all Participants
Security vulnerabilities and outdated software
SAFIRE’s Participation Agreement has always required participants to follow best practices for IT security — including the application of software patches. To date, this has not been actively enforced.
Unfortunately, several Participants are using outdated SAML software (some more than a decade old) with known security vulnerabilities. This poses risks to others, especially when identity providers are compromised, as they can be used to access multiple services. It also reduces the trust other parties place in the Federation as a whole, and risks Participants who actively maintain their services being unfairly affected.
To maintain trustworthiness within the global inter-federation, we will now begin enforcing the existing policy. While all participants are affected, our initial focus will be on identity providers, in line with the new requirement for Sirtfi.
The timeline for enforcement is as follows:
-
1 September 2025: Courtesy notices will be sent to technical contacts of identity providers believed to be running vulnerable or outdated software, requesting an upgrade plan (or allowing them to dispute the assessment). Notices may also be sent on discovery of new issues.
-
1 October 2025: Courtesy notices will also be sent to senior institutional IT managers and/or CIOs of affected providers, informing them that their identity provider is at risk of suspension. Where applicable, library management may be copied on this communication, particularly if the library is a major consumer of federated services.
-
15 November 2025: End-user facing notices will begin appearing on login for identity providers still using vulnerable software. These will inform users of potential risks, allowing them to make informed login decisions. This can be deferred by agreement if an upgrade plan is in place.
-
1 February 2026: To minimise the potential impact on third parties outside SAFIRE, affected providers that have taken no steps to remediate the issue will no longer be published to eduGAIN.
-
1 April 2026: The Sirtfi compliance grace period ends. As the use of known-vulnerable software is incompatible with assertion [OS1] of Sirtfi v2, clause 6.2.4 of the Participation Agreement will begin to be enforced. Providers still operating vulnerable software at this point may be suspended from the Federation. (For the avoidance of doubt, this deadline also applies to any provider who has deferred Sirtfi compliance by submitting written reasons.)
Sirtfi v2
Effective immediately, all new Sirtfi attestations must conform to version 2 of the Sirtfi framework. Attestations only to version 1 are no longer accepted.
Existing v1 attestations remain valid, provided that:
- The entity remains compliant, and
- The required annual review is completed.
However, we recommend that all entities migrate to Sirtfi v2.
The change from v1 to v2 is minimal, involving only one additional normative assertion at [IR3]. A summary of the changes is available here (PDF).
Entity Categories
When an identity or service provider requests the publication of one or more well-known entity categories (such as those defined by REFEDS specifications) in their metadata, they are asking the Federation to attest that they meet the eligibility requirements for those categories. Other entities, in turn, rely on SAFIRE’s assertion as evidence that appropriate due diligence has been carried out.
SAFIRE already has processes in place for some entity categories, such as Sirtfi v2. However, in line with the broader focus on the trustworthiness of metadata and attributes, Federation Participants should expect these processes to be refined and updated — both when an entity category is first requested, and through periodic reviews. The Federation website will always carry up-to-date information on these processes, and any substantive changes that need to be applied retrospectively will be published in advance.
As an example of how these processes might evolve, the annual security contact challenge has already been updated to ask identity providers to confirm their current software versions. This was first implemented in July, and speaks directly to the section on security vulnerabilities and outdated software above, as well as the new requirement for Sirtfi. It forms part of a revised process for attesting compliance with the Sirtfi framework.