...
Document After Consultation: (to be published after consultation/with changes included)
Number | Current Text | Proposed Text / Query / Suggestion | Proposer | +1 (add your name here if you agree with the proposal) | Action (please leave this column blank) |
---|---|---|---|---|---|
1 | Logo 60 x 80 | 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 | Patrick Radtke | Ken Papai Brett Bieber | |
2 | Re logo transparency | Nonnormative text may include a hint about a black or white border around the logo before the transparency if the background is a critical need of the logo. | Via IIW (Judith Bush) | Brett Bieber | |
3 | SP certificate requirements | Section SDP-SP42 says that an SP's metadata must contain certificate(s) that can be used for signing. But section SDP-MD10 mentions only encryption certificates for SPs. First of all, this a bit confusing: must an SP's metadata contain a certificate suitable for signing or not? Secondly, if, in fact, an SP's metadata must contain a certificate suitable for signing, why? | Scott Cantor, Peter Schober | ||
4 | Requirement numbering | Just to head off a bunch of comments, the final renumbering of the requirement blocks isn't done yet pending more tweaks to ordering or updates. | Scott Cantor | ||
5 | Reduce scope of document | 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. | Thijs Kinkhorst | ||
6 | Key hashing algorithm | [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. | Thijs Kinkhorst | ||
7 | Response signing | [SDP-IDP09] requires that response is signed. We are working with signed assertions (not responses) for many years now and I do not recollect this giving rise to any serious interop problem. So I'm not sure that this is an essential property for interoperability. | Thijs Kinkhorst | ||
8 | Encryption of assertions | 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". | Thijs Kinkhorst | ||
9 | Subject-id | 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. | Thijs Kinkhorst | ||
20 | 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 | Niels van Dijk | ||
21 | [SDP-SP05] | 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). | Niels van Dijk | ||
22 | SDP-MD13 | Aspect ratios (and optionally a minimum pixel dimension) may be more helpful than rigid pixel dimensions: e.g. square, 4x3, 16x9. | Brett Bieber | ||
23 | SDP-MD13 | Vector formats, such as SVG should also be recommended. | Brett Bieber | ||
24 | SDP-MD13 | Unless the background color logos will be presented on can also be specified/recommended, accessibility cannot be guaranteed with any logo, e.g. white on white. I'd recommend including samples of presentation, removing the transparency requirement, or explicitly stating that logos must have sufficient contrast to be displayed over a white background. | Brett Bieber | ||
25 | Is that merely saying "MUST support up to 5 minutes of skew"? If now I'm confused by MUST min 3 and max 5. (What about datetimes that are only 2 min off, then, below the "minimum" value?) | Peter S. | |||
26 | SDP-G02 | mdui:Logo has no explicit allowance for data: URIs so the 256 char limit will cause issues there. The minimum RSA key sizes given in bits are probably seen as falling under "otherwise referenced" and allowing for chars > 256? | Peter S. | ||
27 | SDP-SP04 | FYI, SimpleSAMLphp currently cannot support this requirement in supported releases (and once the software can lots of deployments may need updating) | Peter S. | ||
28 | SDP-SP20 | Maybe mention shibmd:Scope here or in SDP-MD01 (the latter if an actual requirement to configure authorized scopes from metadata is intended) so deployers don't need to go hunting how to achieve that scalably? | Peter S. | ||
29 | SDP-MD05 | Does running someone else's amended installer or deployment script that creates, say, a correctly configured backchannel, count as "deliberately and intentionally"? Maybe all that should be required is working stuff (e.g. reachable ports with correct keys, etc.), not "intentions"? I agree with the intention (ha!) but practically this seems tedious to enforce (having to ask "Do you really want to support X, and why?") – but then I may actually be doing that already as registrar... | Peter S. | ||
30 | SDP-IDP14/15 | Is error handling at SPs really so bad that IdPs now MUST fail instead of returning to the SP just w/o the requested (via Entity Attribute here) attributes? That seems to require new behavioural rules for all IDP implementations in existence (to fail authn if the SP uses a certain entity attribute and the IDP is unwilling/unable to comply), something that may not even be possible with anything other than Shib or SSP. | Peter S. | ||
31 | SDP-IDP18 | That sounds like a "SHOULD NOT release multi-valued attributes (at least not properly multi-valued as SAML intends)". We certainly don't want to encourage people to violate our own specs (eduPerson's affiliation has a MUST requirement for also asserting member for certain other affiliation values) or to release multiple values as one contatenated string instead. | Peter S. | ||
32 | SDP-IDP31 | 84% of IDPs and 77% of SPs in eduGAIN don't have PrivacyPolicyURL s 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? I show the SP's URL on the consent (or informaton) screen, sure, but the IDP's? | Peter S. | ||
33 | SDP-IDP31 | errorURL is even less widely deployed today (8% of IDPs in eduGAIN). Worth the trouble? | Peter S. |
See Also
- Trust and Identity Consultations Home
- Deployment Profile Working Group Home
- Note announcing the consultation
https://lists.refeds.org/sympa/arc/refeds/2018-04/msg00016.html