...
- SAML 2.0 Deployment Profile (revised)
- List of R&E-specific requirements for a follow-on working group
- List of federation operator-specific requirements for a follow-on working group
...
- Identifiers: To address the large number of identifiers available today, most of which have significant issues or have been widely deployed incorrectly, the group created two new identifier attributes and documented them in a separate profile which is being approved by OASIS SSTC.
- Federated logout: This topic has many options with no guidance. The working group couldn't find a one-size-fits-all solution but instead presented several well-defined options.
- Encryption: A lot of compatibility issues arise from a relying party's requirements around signing and encrypting SAML messages. Clear requirements were created to help to resolve this problem.
- Logos in metadata: After much discussion, a consensus couldn't be reached to create definitive requirements for logos. Basic guidance was created, but the group referred readers to federation-specific requirements. We are deferring to Refeds REFEDS to further establish international consensus.
- Error handling: The group discovered a lack of consistency and consensus across our community in use of this element . To resolve this, the profile standardizes the usage of error URLs. Error URLs are important, and with guidance around their use and content, they can be even more useful.
...
Several items in the profile will require some coordinated effort by federations for broad adoption, similar to work done to aid large changes in the past such as the move to Shibboleth IdP version 3. InCommon's governance may wish to make some of these requirements part of Baseline Expectations in the future. Items of interest include:
- Changing encryption algorithms
- Adopting new identifiers
- Firming up common standards around logos and enforcing them
- Self-declaration of conformance with the profile for deployments, and publishing list(s) of such deployments
Noteworthy differences between Implementation and Deployment Profiles
The working group identified a couple of areas where the implementation profile and deployment profile don't completely align. These are worth bringing attention to, but , in the opinion of the group, are acceptable differences.
...
- Standardized attribute release requirements for participant IdPs (could get tricky with applications that don't want attributes, for example library/publisher SPs)
- NOTE: This one requirement needs to be better defined: Dealing with FERPA suppression of attributes for graduate students participating in research projects
- Prevent vendors from charging fees for use of SAML in a multilateral federation context
- NOTE: This one requirement needs to be better defined: "Lack of framework/contract terms; change controls, support escalation"
- Publication of security contact information for incident response (requirement for support for SIRTFI)
...
First and most obvious, the working group recommends that InCommon the TAC support the revised SAML2int be being presented to Kantara's Federation Interoperability Working Group (WG-FI) for review and ratification. Once ratified, we recommend that Refeds works to integrate the requirements of the revised profile into federation-specific requirements.
As noted above, there are requirements that were left out of this profile that don't apply globally but benefit an R&E specific application. The working group recommends that InCommon the TAC charter an effort to create an R&E-specific profile to be layered on top of SAML2int using the above requirements as a starting point.
...
Finally, the working group recommends some well-planned marketing and insentives incentives to help InCommon participants achieve compliance. This could involve adding items to Baseline Expectations as noted above, but it also could include a badge or signaling in metadata. As with SIRTFI, metadata signaling could be self-asserted. InCommon might also want to consider a Baseline+ certification; participants who don't meet the extra requirements won't be removed from the federation, but those who do will receive additional benefits. Adherence to many items in this profile might fall into that category.