Document Title: SAML V2.0 Implementation Profile for Federation Interoperability
Document Status: Initial IPR closed
Originating Working Group: Federation Interoperability
Comment Review Period Closing Dates: 2017-07-29 at 11:59 UTC
Submitted to Leadership Council: pending
Leadership Council Comments: pending
| 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 strongly advice 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 that people will not fully go through all the references, and I feel that especially those security considerations are very relevant and applicable to your section on Algorithm Support. In particular I feel uneasy about promoting supporting bad algorithms for some time because entity operators could be unwilling to update. At the very least a safe default must be configured, which could then perhaps be manually be overridden in extenuating circumstances. Automatic negotiation has let to problems in the past (e.g. with NULL ciphers) and is IMHO unsafe. | Technical | in progress | in progress |
| 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 | After much discussion, the WG continues to feel that both of these items are essential to the profile. An informal survey of various stakeholders supports this position. Many vendor products will, in fact, require modification to conform to this forward-looking profile. |
| 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 | WG feels this is fairly self-evident but agreed to add brief language about this, which has not yet been drafted. | |
| 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. |