7 thoughts on “Can we standardise on MDUI?

  1. Rod Widdowson

    My hope had always been that logo size would resolve itself in the same way that advertising plugin logos did.

    I’m not sure what the process was, but in some manner ‘everybody’ seems to ‘know’ that if you want to place adverts on webpages they should either be landscape and such an such or portrtait and such and such. So webdesigners (our homologue would be software guys) make the holes the appropriate shape and advertisers (the Entity owners) make their adverts (logos) the appropriate shape.

    But as everyone knows, I’m a hopeless dreamer….

  2. Lukas Hämmerle

    I agree to most of the recommendations, but:

    – A maximum length of 33 characters for display name is rather short. About a third of the organizations in SWITCHaai have official names that exceed these 33 characters. The longest name has 67 chars (i.e. “Scuola Universitaria Professionale della Svizzera Italiana”). I guess languages like German or Italian just need more words to describe things 🙂 Many of our institutions have abreviations, like “SUPSI” for the above example. So, as a last resort we could use these as names but . Our current Discovery Service usually uses both, the abbreviation and then the full name. This results in: “SUPSI – Scuola Universitaria Professionale della Svizzera Italiana”. Using this format increases the names considerably making more than half of our institutions exceed the 33 characters.
    On the other hand, looking at the UK metadata, it seems you will face similar problems. Just displaying “LSHTM” as name instead of “London School of Hygiene & Tropical Medicine” (44 chars) does not seem very user friendly.

    – We probably could live with the 100 chars max value for an IdP description. However, I have no idea what to reasonably describe with that length. One idea could be to just use the description to contain the full name (and possibly a tagline) of an organization whereas the displayName could contain a short name or an abbreviation (like “SUPSI” for the above example) to stay within the 33 chars limit.

    – Regarding the location of the logos: We have started to add the logos not as URLs but as data URIs. So, like the certificates they are then embedded directly in metadata. This should also be ok according to the schema and the spec. We tested it with Shib SP and IdP. The latter had a small problem that prevented the logo from being displayed, but this issue is already resolved.

  3. Mikael Linden

    My approach to MDUI has been the data protection law. They seem to be a perfect match. The law requires that the users are informed on the release of their personal attributes. There are of course several interpretations on what this means. In the eduGAIN project, we are converging to providing the following information to the user by the IdP’s attribute release module:

    – SP’s name (mdui:displayName and, optionally, mdui:logo)
    – short description of the purpose of the SP (mdui:description)
    – link to SP’s Privacy statement (mdui:PrivacyStatementURL)
    – attribute names and values the SP requests (md:RequestedAttributes)

    For DisplayName and Description, some simple instructions such as don’t use acronyms (instead, put them to mdui:keywords!) and use language which is understandable also for users not affiliated to the institution.
    Md:OrganisationDisplayName as a fallback for mdui:DisplayName makes only sense for IdP Entities.

    Data protection authorities provide a lot of material on how to write a privacy statement for a service. For SP’s logo, the requirements set by the attribute release module are probably relaxed compared to the Discovery services’ requirements on the IdP logos.

    A use case for IdP keywords is Discovery Service. Just type you home organisation’s acronym to an incremental search box.

    If the lang attribute is present for the elements, at least lang=”en” should be in place.

    The discussion with SP communities (like research infrastructures) indicate that the SPs suffer from Home organisations’ hesitation to release attributes, due to the data protection implications. In eduGAIN, we are designing a package which helps IdPs and SPs to comply with the law, and the MDUI elements are one of the pieces. We hope being able to receive the attributes from the IdPs is a strong enough incentive for the SP entities to populate their MDUI elements.

    eduGAIN aims at cross-federation attribute release. To make MDUI useful in eduGAIN, it should be interpreted consistently across federations. I think a common practice is more important for the elements’ semantics than for the elements being MUST or MAY.

    Because MDUI adoption is still low, the window of opportunity is open for a common practice across federations. If we don’t make a common recommendation now when it’s still possible, in a couple of years we’ll see the same problem we see now for the eduPersonAffiliation attribute; the attribute is widely used but federations have adopted conflicting semantics, which is hindering its cross-federation use.

  4. Pål Axelsson

    I find it interesting that you’ve choosen to recomend a lenght of description that is less than some federations hav in their recomendations today. Why?

    The logo size is interesting to. I think we’ve to look into what size organisation has for their web logos. Sometimes it’s stipulated very har what size you could use on the web. For example my home university demand that the logo shall be 125×125 pixels.

  5. Rod Widdowson

    FYI Length restrictions are usually a software driven restriction, which federations bring forward.

    If you are trying to cram a logo and a 200 character entity name into a box which is 100 px wide then it’s not going to end well.

    Equally if you populate a standard web browser’s dropdown menu with such a beast you will often find that it overruns the width that the designer allowed.

    When I’m writing software I usually trim such monsters down – which brings up another issue – starting with “The University Of” is not friendly to the users when they are seeing trimmed result. You see this in spades in the UK Federation. Unfortunately IdPs are sometime not allowed to say (the useful) “Foobar University” rather than “The university and further educational insitution for medical and ethical research of Foobar”.

    I’d agree that 33 feels stingy, OTOH a case can be made for keeping things brief (and I appreciate that this is potentially a cultural issue). In my (facetious) example above, I’ll bet that most students when asked where they are studying would say “Foobar University”. Certainly I refer to my old university as “Edinburgh University” not “The University of Edinburgh”.

    One thing I think we all agree on is that the described use of the elements should be respected. So people should be discouraged from putting “Use this site for really cool things” as their DisplayName, even if it does give the Discovery experience they want.

  6. Tom Scavo

    As Mikael points out, using md:OrganizationDisplayName as a fallback for mdui:DisplayName only makes sense for IdP entities. Moreover, it goes against the spec, which is quite clear on the precedence of names.

    I feel strongly that mdui:DisplayName should be required. In the near future, the InCommon Federation will not be able to accept entity metadata without mdui:DisplayName. This is in no small part due to changes in the use of md:OrganizationDisplayName spurred on by the emerging MDUI spec.

    We shouldn’t agonize too much on the maximum length of mdui:DisplayName and mdui:Description since UI designers can compensate for long strings, but I agree with Rod that the most important characters should come first, both because the UI may choose to truncate the displayed string and because published lists will be sorted on mdui:DisplayName.

  7. Ian Young

    The answer to the question about where advertisement block sizes comes from is that there’s a standards body involved:


    There was initial chaos, then a period when a few standard “ad units” were boiled down from that, then they gradually added to that over time as new use cases became apparent.

    It’s not an industry I’m particularly fond of, but that’s definitely the right process.

Comments are closed.