...
- 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.Encryption
- 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 plan to ask Refeds to further tackle this issue.
- Error handling:
Recommendations to federations for implementing
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 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
Noteworthy differences between Implementation and Deployment Profiles
- Clock skew: the implementation profile is vague on this, stating a reasonable value with a recommended three to five minute range. The Deployment Profile requires a maximum three to five minute range.
- Forced authentication: The deployment profile recommends that the SP test the currency of the AuthnInstant to ensure that reauthentication was performed by the IdP. The implementation profile doesnt' require that this value be exposed to make it available for testing.
Remaining items for an R&E-specific profile
...