Attribute Specification

Purpose of this document
In a federation, information about the user is represented in SAML attributes transferred from the Identity Provider to the Service Provider. It is important for both parties to interpret the data in the same way.

Exact definitions of the attributes are maintained in their defining schemas. Within this specification, we use the following schemas:
 * person, organizationalPerson (X.521)
 * inetOrgPerson (RFC2798)
 * eduPerson (http://middleware.internet2.edu/eduperson/, version 200806)
 * SCHAC (http://www.terena.org/activities/tf-emc2/schacreleases.html, version 1.4.1)
 * niifPerson, niifEduPerson (NIIFSchema)

This Attribute Specification provides an interpretation of the defined attributes for their use within the federation. It might be somewhat more specific than the original definition, in order to let the SPs get more specific information about the user.

Beyond the specification, parties may bilaterally agree on any other attributes.

Terms

 * An attribute is implemented, if the information is available according to the semantics of the specification. Releasing an implemented attribute is simply a policy decision of the IdP.
 * An attribute is released, when the data is transferred from the IdP to an SP. Not all available information is sent out normally, only the attributes that are relevant for the SP.

Levels of implementation

 * Mandatory: every IdP must implement the attribute.
 * Recommended: it is recommended for every IdP to implement the attribute, however, it is understood that it might be impossible or very complex for certain IdPs
 * Optional: an IdP may freely implement the attribute, however, the implementation must follow this specification.

Attribute Requirements of the SP
SPs can indicate attribute requirements among the information provided to Resource Registry. This information also shows up in the federation metadata. From the point of view of the SP, an attribute can be:
 * Required: the information is a requirement for the proper operation of the SP application
 * i.e.  is often required for applications, which are not prepared for handling opaque identifiers.


 * Desired: the information can add extra functionality to the application or can provide better user experience
 * i.e. when  is transferred, the user is not prompted to supply his or her common name.

Persistent user identifiers
For most services, it is necessary to store application-specific data, such as user edits for a wiki page. This data is stored in a database, which is local to the SP, while the key between the user and the database entry is the persistent user identifier.

Persistent identifiers can be:
 * computed: the identifier is generated run-time from one or more attributes of the user (usually by some cryptographic hashing algorithm).
 * stored: the identifier is stored in the user's digital identity at the IdP, thus it is persistent even when other user information is changed. Uniqueness of the identifier must be preserved.

Identifiers can hold the following properties:
 * persistence: IdPs must ensure that the identifier does not change during the life-cycle of the user at the institution.
 * non-reassignable: IdPs must ensure that an identifier of a user will not be reassigned to another user.
 * opacity: opaque identifiers do not refer to any personal data
 * targeted: targeted identifiers are different for each SP, thus the SPs are unable to build common user profile without the cooperation of the IdP. Such identifiers are preferred from privacy reasons.

Persistent identifiers can be transferred in SAML attributes or in NameID of a SAML Assertion. Certain SP implementations (such as Shibboleth 2.x) can hide the details of the transfer, and can provide a persistent identifier in REMOTE_USER header.

List of attributes
In this specification, only mandatory and recommended attributes are specified. The Hungarian version of the Attribute Specification contains descriptions of the optional attributes as well. If you have any questions regarding the optional attributes, please contact the Federation Operator.