Attribute Sets

The UK Access Management Federation for Education and Research enables Identity Providers to transfer information about their users to Service Providers in the form of attributes. Each Service Provider and Identity Provider could, if it wished, define its own unique set of attributes and agree their meaning on a bilateral basis with those with whom it wished to communicate. However, where an attribute communicates some information that is likely to be required by many Service Providers and Identity Providers, there are clear benefits for both sides in having a common definition for the attribute and its meaning. The federationís Technical Recommendations for Participants therefore set out a small number of common attributes that can be used with the same meaning by any federation member. These are divided into different classes to minimise the effort required by the majority of Service or Identity Providers who have relatively standard access management requirements. It also provides groups or individual Service Providers with the flexibility to develop and, if appropriate, standardise extra functions.

  1. Core Attributes carry the fundamental information that is likely to be required as a minimum for the majority of access management exchanges. It is expected that most Identity Providers and Service Providers will support use of these attributes. Identity Providers that do not support them are likely to find that Service Providers are unable to offer a full range of services to their users. Detailed information and guidance on the values and use of these attributes is provided in the federation documentation at:
  1. Subsidiary Attributes are used to carry additional information where a common requirement has been identified widely, but not universally, across Service Provider members of the federation. Recommendations for how these attributes are used and their values and meaning will be provided in the federation documentation, so that those who do need to support them can do so in a common way. It is not expected that all federation members will support Subsidiary Attributes, so Service Providers that use them are likely to have to justify to Identity Providers the extra effort required.
  2. Additional and Custom Attributes may be used in the rare cases where a Service Provider has a unique requirement that is not satisfied by the Core and Subsidiary Attributes. The federation documentation contains suggestions on how to select these attributes, should they be required. Following these guidelines increases the likelihood of a common requirement being identified and a Subsidiary Attribute being defined to satisfy it.

The current sets of Core and Subsidiary Attributes can be found in the Technical Recommendations for Participants. The list of Core Attributes is unlikely to change; however, it is anticipated that additional Subsidiary Attributes will be defined in future. Service Providers whose service needs are not met by the existing Core and Subsidiary Attributes are invited to contact the federation helpdesk (service @ to discuss their requirements.