Consultation for SAML V2.0 Interoperability Deployment Profile V1.0

suggestion: high-res Favicon, Android home screen icons, Apple touch icons and Windows metros icons all use square images to represent websites. As such institutions are more likely to have existing, reasonable looking square logos to represent them. It will make adoption more straightforward if IdP operators can simply upload their schools existing high-res favicon/touch icons rather than creating their own, non-square icon. This site has more information on what existing systems are using https://sympli.io/blog/2017/02/15/heres-everything-you-need-to-know-about-favicons-in-2017/ The handful of schools I spot checked either had hi-res favicon or published hi-res Apple touch icons.

FWIW, for SPs that also want to make use of social logins Facebook, LinkedIn and Google all use square logos for OAuth clients

Ken Papai

Brett Bieber

Chris Spadanuda

The SAML-world already has many pages of documents. In order to be effective, the profile should be as concise as possible and contain the essential points needed for interoperation. And not be a wishlist or best-practice document.

I propose to remove the entire section on Logo requirements, on MDUI-requirements and the section on deep linking. Not that these are invalid points, they are just not essential and more of a best practice. Whether or not an IdP has a good logo is, to be frank, not one of our top concerns.

[SDP-MD09] "Certificates used MUST NOT be signed with an MD5-based
signature algorithm and SHOULD NOT be signed with a SHA1-based signature
algorithm."

This is a confusing requirement. X.509 certificates are used as a container for the key, not as a PKI. A few paragraphs above it is stated that the certificate should be self-signed. Talking about these signing algoritms for the key is not necessary and can confuse the deployers. Propose to drop the entire requirement.

[SDP-IDP09] requires that response is signed.

SDP-IDP11 requires assertion to be encrypted. Although I understand that there can certainly be benefits, I don't think it's essential for interop to make it a hard requirement. There are in my experiences many cases that work fine and in which encryption is not necessary per se. Propose to make it a "should".

The document obsoletes the NameID and requires the new subject-id attribute. This new identifier is however still very much in its infancy. I believe that an interop profile is not the place to be pushing new things. It should document existing practices and list proven and established technology that is already in wide use.

An interop profile should be about "if you follow these requiements, it will work". Any deployer picking up this document now will quickly find out that many federations cannot currently deliver this attribute at all. So the promise of interoperability by following it then quickly fails.

The subject-id is a fine idea but not established technology. I propose to remove anything related to the subject-id. It could of course be codified in a version 2.0 when it has been widely adopted.

3.1.4. SAML entityIDs

An entityID SHOULD be chosen in a manner that minimizes the likelihood of it changing for political or technical reasons, including for example a change to a different software implementation orhosting provider.

This is not in line with current (best?) practice of making the entity ID match the URL where metadata can be retrieved

The use of "The <samlp:AuthnRequest> message MUST NOT contain a <saml:Subject> element. This is a relatively unused feature that is supported by few IdPs."

While the use of saml:Subject is indeed not often used generically, there is a critical usecase for this for stepup authentication, as this typically requires the binding of a LOA to a specific user (as expressed in the subject).

SDP-MD13

84% of IDPs and 77% of SPs in eduGAIN don't have PrivacyPolicyURLs today. ACOnet is already mandating them for SPs (we're not at 100% either) but we have not done so for IDPs. Is the requirement for PrivacyPolicyURL also for IDPs just an overly broad include from the MDUI section? If not how exactly are those URLs envisioned to be used? IDPs can show an SP's PrivacyPolicyURL on the consent (or information) screen, sure, but when would anyone need metadata to show the IDP's own policy?

(Niels: at th point in the authN flow where this info could be shown, the user is either already in the IdP and hence already subject to the privacy policy, or the user is not, which makes this the wrong IdP for the user anyway)