|Ref #||Clause||Comment/Request||Type E/T||Disposition||Notes|
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||commit||Extended normative and non-normative text about disabling algorithms added.|
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
|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.|
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.|
Rationale behind mandating support for SHA1 given that the algorithm is no longer considered secure (particularly for signing)
|Technical||commit||WG accepted the suggestion.|
Does this apply to hub&spoke identity federations (e.g. SURFnet, eIDAS)?
|Editorial||Duplicate of #1|
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.|
|Tentative responses needing WG review.|
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
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.
|Technical||RSA-OAEP support is frequently limited to SHA-1, but we could change this to match the language up above for CBC and just call it support for SHA-1 has been reduced from MUST to SHOULD and called out as a backward compatibility requirementissue.|