Attributes that are necessary for a Service Provider

b) [Purpose limitation] to only process Attributes of the End User that are necessary for enabling access to the service provided by the Service Provider;

c) [Data minimisation] to minimise the Attributes requested from a Home Organisation to those that are adequate, relevant and not excessive for enabling access to the service and, where a number of Attributes could be used to provide access to the service, to use the least intrusive Attributes possible;

In practice, this can mean that

access control at the SP requires certain attributes

providing the service requires a reliable (i.e. not user-provided) identifier to be associated with each on-line account

the Service Provider software will not function or important functionalities of the service require the attributes

the service requires that people are able to transfer their existing real-world trust of other members of the collaboration

Examples of NECESSARY attributes

an attribute (such as, eduPersonAffiliation, eduPersonEntitlement or schacHomeOrganization) indicating the user's permission to use the service

if the attribute is not released, the service cannot verify user's authorisation

a trusted value provided by the IdP is needed instead of a value self-asserted by the user

an attribute (such as SAML2 PersistentId) uniquely identifying the end user is necessary to store user's profile in the service

a trusted value provided by the IdP is needed. The user cannot self-assert his/her unique identifier

if there are several alternative unique identifiers available for the service, the least intrusive MUST be used

pseudonymous bilateral identifier (SAML2 persistentId) is preferred

if there is a legitimate reason to match the same user's accounts between two Service Providers, a more intrusive identifier (such as eduPersonPrincipalName) can be used

a name attribute (such as cn or DisplayName) is necessary for a wiki or other collaboration platform, if the users know each other in the real life and need to be able to transfer their existing real-world trust of other members of the collaboration

if it makes a difference in the collaboration platform to know the person's name, it can be released

otherwise, the user may be indicated as "unknown" or user "12345678901"

email address, if, for the functionality of the service, it is necessary to be able to reach the end user

for instance, the service is for applying access to a research database, and once the application is processed, the applicant is informed if the access was denied or grant

Attributes that are optional for a Service Provider

Optional attributes belong to category REQUIRING CONSENT and can be released to the Service Provider, if the user consents to it.

An Attribute is categorized as REQUIRING CONSENT if the service can operate without it, but the service will provide some additional service level to the user (or to other users of the site) if the Attribute is provided.

Examples of optional attributes

for a wiki, the user's email address

if the user wants to receive email notifications on updates of certain pages in a wiki service, instead of frequently visiting the wiki

alternatively, if the user does not want to receive email, he has the liberty to frequently visit the wiki page

for a wiki, the name of the user (for instance, to show who has edited a page)

if the wiki is not related to a real-world collaboration where people know each other by name and need to tranfer this trust to the wiki

Alternatively, the Service Provider may ask the user to type in the optional attributes by him/herself.

For contrast, the definition of "freely-given" is that it can be withdrawn at any time. If withdrawing consent to disclosing a name breaks the service (as it does for a research collaboration) then consent is the wrong basis. That is exactly the situation where necessity applies.

Attributes that are not relevant for a Service Provider

The SP can only process attributes that are adequate, relevant and not excessive in relation to the purposes for which the SP processes them. The SP MUST NOT request other attributes from the IdP.