MDUI Guidance for Federation operators. May 2012

  • Consider making your guidance re-enforcing existing specifications and recommendations.

  • Ensure that your requirements and recommendations around MDUI are documented.

  • Update the reference pages on Federation Recommendations as required (this task will not be done centrally).

  • Review other federation’s requirements for inconsistencies with your own.

  • Note on the REFEDS mailing list issues of incompatibility.

  • For federations considering starting to adopt MDUI: It was noted at the meeting at Arlington in March 2012 that if your policy and scale allows it, it is considerably easier to make the changes on behalf of entities than it is to persuade entities to submit changes.

 Only use normative language from RFC2119 where appropriate. Note in particular section 6.   

Requirements and Recommendations

When reviewing or describing the MDUI requirements it is important to be clear about the importance of the recommendation:

1. A requirement may be mandatory. In this situation non conforming entities will not be inter- federable. Federations imposing such restrictions and federations not populating this field both need to be aware that this is a barrier to inter-federation. Normative language from RFC2119 may be appropriate in this situation.

An example might be:

  •   All SP’s MUST have an mdui:DisplayName.

2. A recommendation may be for aesthetic reasons. This is not a barrier to interoperability. Normative language for such recommendations is not appropriate and should be avoided. Examples:

  •  mdui:DisplayName should be less than 32 characters [and longer names may be shortened].
  •  mdui:Logos should be of a given size [but will be scaled appropriately]
  •  mdui:Logos should have a specific aspect ratio.

3. A recommendation may be functional. In this case non-conforming data may not be used by the federation with the restriction. This does not mean that such elements in other federations (including, one assumes, the entities owning federation) is inappropriate or should be suppressed. Normative language for such recommendations is not appropriate and should be avoided. For instance: 

  • Logos should have a certain minimum size [logos of less than a certain size will be ignored.]

In practice is seems that very few requirements fall into the first category. This may be why there is little appetite for a formal specification at this stage.


It has been agreed that uptake of MDUI is important, but no clear recommendations on how to achieve has yet emerged:

  • As noted above, filling in information on behalf of entities works well where policy & scale allow. Further it cannot be used for all elements. For example, it is usually easy for a federation operator or other third party to populate mdui:DisplayName appropriately, but significantly harder to populate mdui:Description.

  • Getting logos from the official sources can be particularly challenging.

Using a forcing function to get information (you cannot make any change until you supply this information) is effective, but can lead to data quality issues. Federations are encouraged to share ideas about successful techniques on the REFEDS mailing list. 

Appendix: Good practice and following standards.

It is worthwhile to reiterate some of items that are required by specification or good practice. However these items are not the sort we might expect to form the basis of a “REFEDS MDUI Standard”.

1. Follow the MDUI specification.

We take it as a shibboleth (sorry) that all federations desire to follow specifications.

Misuse of the elements specified for MDUI should be discouraged in guidance and disallowed by process. It is expected that any guidance should be written with knowledge of the specification. Additionally federations may choose to reiterate this in their guidance.

The UK has seen instances where Entity Owners have tried to submit meaningless (by the specification) entries because it ‘works well’ with one particular implementation. To reiterate from the specification (with annotation in bold) areas which have been seen to be problematic

  • DisplayName
    “specifies a localized name fit for display to users. Such names are meant to allow a user to distinguish and identify the entity acting in a particular role. The content of this element should be suitable for use in constructing accessible user interfaces for those with disabilities.”

  • Description
    “a brief, localized description fit for display to users. In the case of an <md:SPSSODescriptor> role, this SHOULD be a description of the service being offered. In the case of an <md:IDPSSODescriptor> role this SHOULD include a description of the user community serviced. In all cases this text MUST be standalone, meaning it is not to be used as a template requiring additional text (e.g., "This service offers $description").

  • Logo
    “specifies the external location of a localized logo fit for display to users. This element extends the anyURI schema type with the following attributes: 

height [Required]: The rendered height of the logo measured in pixels.
width [Required]: The rendered width of the logo measured in pixels.
xml:lang: Optional language specifier.

  • In order to facilitate the usage of logos within a user interface, logos SHOULD:
    • Use a transparent background where appropriate
    • Use PNG, or GIF (less preferred), images
    • Use HTTPS URLs in order to avoid mixed-content warnings within browsers
  • GeolocationHint element specifies a set of geographic coordinates associated with, or serviced by, the entity. Coordinates are given in URI form using the geo URI scheme [RFC5870].

2. Goodpractice

Federations may choose to re-emphasise standard good practice to avoid unexpected consequences.

  • As mentioned in the specification (and above), these should be protected by an https URL so as to avoid mixed content warning.

  • Sites (particularly) should be encouraged to avoid hosting their logos on a (Java) servlet container. Apart from the additional load on a (usually) scarce resource, such containers usually push a cookie with every request. Thus, such URLs when rendered by other sites, will be pushing third party cookies.

  • No labels