As part of the REFEDS Discovery Project, Rod and I are looking at ways in which federations are using MDUI. To describe MDUI simply, it is information and hints put in to metadata to make the user interface around access management look much much better. The concept of MDUI itself is based on a proposed OASIS standard which is trundling its way through the sign-off process as we speak.
The trouble with pesky standards are in the way they are interpreted and implemented in real world settings. It is natural for organisations to adopt different approaches to elements such as these – a basic level making different elements required or optional, and adding different parameters around the elements (length, size etc.). There is also the problem that different parties will want to have an opinion on this – particularly federations that need to collect and distribute the information, but also software implementations that use the information. Rod has done an excellent job of collecting recommendations on MDUI from software developers and federations on the REFEDS wiki.
So could we look to standardise our approaches to MDUI? Is it possible to come up with a REFEDS set of recommendations around its use? I’m not so sure. It’s worth breaking down the elements to see if this is possible.
———————————————————————————————
DisplayName and Description
The idea that an entity should have a display name and a description of what it is seems fairly non-contentious…but there are differences. One of the obvious differences is in the allowed length of each elements – but an obvious way to amend that would be to recommend the shortest set amount for each.
Then is it sensible to say that federations should require these elements to be populated? They are certainly not required elements across the board within federations at the moment. My gut feeling would be that everything recommended would have to be optional…although that significantly waters down the potential impact of MDUI. A useful approach adopted by several federations for DisplayName is to use what is already there. Federations already register md:OrganizationDisplayName for entities – and using this as a fallback for non-populated mdui:DisplayName is imminently sensible.
So if we were to try and make a recommendation around this? It would have to be:
mduiDisplayName: optional, max 33 characters. Fallback to md:OrganizationDisplayName.
mduiDescription: optional, max 100 characters.
———————————————————————————————
Logo
Logo is quite simply the hardest element to deal with. It’s hard to define the requirements, its hard to get organizations to submit due to corporate branding concerns. Moreover, the exact recommendations made are going to depend on the software used by the service in question. These means that if you optimise for a Shibboleth Embedded Discovery Service, your logos aren’t going to look so great in DiscoJuice. There are also more generic guidelines to consider, such as the work done on recommendations for social media buttons. Whilst lots of organisations have taken the step of developing favicons which tend to support this kind of work, it is by no means ubiquitous.
So what could we say regarding a recommendation? At the moment, there seem to be three common elements – provide a link to an image that is on an https page, an image that has a transparent background and an image that is a .gif or a .png. There is also general agreement that there are different requirements for IdP logos and SP logos.
Will we ever resolve the size issue? I’m not sure. Federations are likely to make recommendations based on what looks best in their Central Discovery Service or WAYF, or that looks best in the software implementations that they most widely support. Once we get in to the realm of sharing metadata via interfederation, this is going to create all sorts of problems. However, there is simply nothing close to a pattern in the recommendations currently being made.
If forced to make a recommendation, it would look something like this. This would mean a change in practise for some federations and may not satisfy some sofware approaches.
IdPLogo: optional, close to 60 x 80 pixels, .gif or .png, transparent backgroud, provide a link on an https page.
SPLogo: optional, in the range of 64/150h x 64/350w pixels, .gif or .png, transparent background, provide a link on an https page.
I’d also want to discourage federations from adding additional requirements to the logo formatting – would this create problems for anyone?
———————————————————————————————
Keywords
There are no specific use cases for keywords active within federations at the moment so I would think any recommendations would want to say silent on keyword use or discourage use at this point in time.
———————————————————————————————-
InformationURL
There are currently debates around the interpretation and use of InformationURL at this point in time. As any potential users of this information would need to have a good, clear, understanding of what the URL was for I would think any recommendations would want to say silent on InformationURL use or discourage use at this point in time.
———————————————————————————————–
PrivacyStatementURL
The use of a PrivacyStatementURL is less ambiguous than InformationURL and there is no need to make specific recommendations around structure as it is simply a URL. On a practical level, however, it would be useful to point to guidance as to what a PrivacyStatementURL should lead to. Other working groups within REFEDS are looking at proposed wording and advice for such a statement and it would be sensible to combine this work.
———————————————————————————————–
IPHint, DomainHint and GeolocationHint
RFC recommendations for each of these elements are well described in the Metadata Extensions specification. It would be sensible for any REFEDS recommendations to use these directly without change. In terms of use, inaccurate data in these fields can create significant user confusion so it would be appropriate for accuracy checks to be run on this information before including in metadata. This creates a new overhead regarding management of entity data.
———————————————————————————————–
So that’s it! The main problem area is the use of logos and it will take some debate to get this to a comfortable resolution. It is of course typical that use of logos is one of the key benefits of the MDUI information in supporting user interfaces.
I don’t think that REFEDS making any recommendations around these elements in particularly going to help or drive uptake. I think it is clear that it is going to take a long long time to get a decent percentage of entities using MDUI.
Do we need to do something now, though, to prevent differing recommendations being made by federations and software providers? If we make some recommendations, will anyone listen and change their current practises? Is there any value to be placed in such a coordination exercise?
We would dearly love to hear your thoughts.
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….
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.
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.
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.
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.
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.
The answer to the question about where advertisement block sizes comes from is that there’s a standards body involved:
http://www.iab.net/guidelines/508676/508767/ad_unit
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.