SAML IP-FI - Disposition of Comments

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.

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.

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.

Clarify if hub&scope [sic] identity federations are out of scope of this document

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.

Rationale behind mandating support for SHA1 given that the algorithm is no longer considered secure (particularly for signing)

Does this apply to hub&spoke identity federations (e.g. SURFnet, eIDAS)?

Use of RECOMMENDED (equivalent to SHOULD) more appropriate than OPTIONAL in order to push support for SLO propagation

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.

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.

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.