...
Ref # | Clause | Comment/Request | Type E/T | Disposition | Notes |
---|---|---|---|---|---|
1 | Title/Abstract | The document is titled “SAML V2.0 Implementation Profile for Federation Interoperability”, but in the first sentence of the abstract it limits its context to full mesh identity federations. What is the reasoning for excluding proxied/hub-and-spoke federations, given that they also exist in the R&E sector and that the adoption of this model is on the rise by eScience collaborations? If the document is indeed meant to be limited to full mesh federations, perhaps the title should reflect this. | Editorial | commit | Clarifying text added to introduction. |
2 | 2.5 Cryptographic Algorithms | It concerns the section Under "Algorithm Support": I would very stronglyadvice to include part or all of the 'security considerations' (sec 2.6)of "SAML V2.0 Metadata Extension for Algorithm Support"[SAML2MetaAlgSup]. Even though you refer to that document, I worry thatpeople will not fully go through all the references, and I feel thatespecially those security considerations are very relevant andapplicable to your section on Algorithm Support.In particular I feel uneasy about promoting supporting bad algorithmsfor some time because entity operators could be unwilling to update.At the very least a safe default must be configured, which could thenperhaps be manually be overridden in extenuating circumstances.Automatic negotiation has let to problems in the past (e.g. with NULLciphers) and is IMHO unsafe. | Technical | ||
3 | IIP-IDP13 4.3 Single Logout | What I can see in the deployment profile is a demand on all implementations that say they fulfill SAML2int must fulfill all in the implementation profile whatever the deployment profile says. This could be a really interesting problem when you buy your Identity Providers from a vendor that do not offer a technical implementation for all parts of the SAML2int as described in the implementation profile, for example ECP or SLO. This is especially a procurement problem in combination with the use case to use SSO only. The implementation profile should be more open than the deployment profile and there maybe be a need for more than one deployment profile for different use cases. If we for example take a small vendor in the northwest of the US that many CIO’s want to buy almost everything from. Their support for ECP is if I remember correctly none and for SLO not so good. When you write SAML2int in a procurement directive the evaluation will be against the implementation profile not the deployment profile. | Technical | No Change | |
4 | Abstract | Clarify if hub&scope [sic] identity federations are out of scope of this document | Editorial | Duplicate of #1 | |
5 | IIP-MD01 | Use of SHOULD more appropriate that MUST (for IdPs) as draft specifications are subject to change. | Editorial | commit | WG agrees that this is a problem, but continues to feel that MDQ support is critical. References have been changed to non-expired versions of the MDQ specifications. The working group does feel that MDQ, as outlined in the referenced drafts, has stabilized. In the future, this profile may have to be rev'd in order to follow updated MDQ publication status. |
6 | IIP-MD10 | What happens when the intersection is an empty set? How can the Identity Provider be obliged (MUST) to use an algo they do not support? Further clarification is needed in the text. | Technical | ||
7 | IIP-ALG02 | Rationale behind mandating support for SHA1 given that the algorithm is no longer considered secure (particularly for signing) | Technical | commit | WG accepted the suggestion. |
8 | IIP-IDP13 | Does this apply to hub&spoke identity federations (e.g. SURFnet, eIDAS)? | Editorial | Duplicate of #1 | |
9 | IIP-IDP17 | Use of RECOMMENDED (equivalent to SHOULD) more appropriate than OPTIONAL in order to push support for SLO propagation | Technical | commit | WG agreed that the existing language was both intentional and continued to accurately reflect their opinion that advocating for SLO propagation could impede implementation of baseline support for SLO. Additional, non-normative explanatory text added. |