SAML IP-FI - Disposition of Comments

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	commit	Extended normative and non-normative text about disabling algorithms added.
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	commit	Non-normative language added clarifying this.
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.
10	IIP-MD03	This statement eliminates the use of any trust framework in verifying the signature. The public certificate may be revoked, expired, or issued by an untrusted source and the document asserts that this information MUST be ignored. One does not need an X.509 certificate to hold a public key. If one opts to use one it will come with trust framework artifacts that SHOULD NOT be ignored. Please explain your thoughts here.	Technical	No Change	There are no other trust frameworks that are defined interoperably for use with SAML, and the ones that have been used are applied informally and inconsistently. This profile is mandating the use of an OASIS-defined specification that's many years old and that guarantees consistent behavior, and addresses key management and revocation by means of metadata distribution. While it would be better in some respects to use bare keys and avoid the baggage of X.509, that's not practical due to implementation constraints and the syntax limitations of XML Signature. The use of certificates as a carriage format for keys is simply a long-standing practice.
11	IIP-ALG06	According to https://csrc.nist.gov/Projects/Hash-Functions/NIST-Policy-on-Hash-Functions SHA-1 is being deprecated and its use SHOULD be discouraged. Legacy verification is permitted. This section should limit the scope of SHA-1 usage.	Technical	commit	RSA-OAEP support is frequently limited to SHA-1, but support for SHA-1 has been reduced from MUST to SHOULD and called out as a backward compatibility issue.