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 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?
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.
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.
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
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.
Comments are now closed.