| Attribute Type | Attribute | Requirement | Explanation |
| User Identifier | subject-id | Mandatory (at least one of the five attributes) | The LS Login, along with the services connected through the LS Login, are required to uniquely identify users. Without a unique identifier, it is not possible to distinguish two different users from each other. As a service that supports Sirtfi, it is required that it is able to uniquely identify users when tracing incidents. 1The LS Login can use eduPersonPrincipalName only if one of the following conditions are met: i) the IdP supports the R&S Entity Category, ii) the IdP releases eduPersonAssurance attribute and it has a value of https://refeds.org/assurance/ID/eppn-unique-no-reassign, iii) the federation in which the IdP has registered has a policy that prohibits the reassignment of the value of the eduPersonPrincipalName attribute |
| pairwise-id | |||
| eduPersonPrincipalName1 | |||
| eduPersonTargetedID | |||
| eduPersonUniqueId | |||
| Affiliation | eduPersonScopedAffiliation | Mandatory (at least one of the two attributes) | Access to many of the services connected through the LS Loginrelies on authorising their member users based on affiliation with their home organisation. |
| eduPersonAffiliation | |||
| Level of Assurance | eduPersonAssurance | Optional | Access to the services connected through the LS Login will be dominantly supported by identities coming from the IdPs from the R&E sector and eduGAIN. The best-fit and most natural way is to use the Assurance Framework that originated as the collaborative work of R&E federations – the REFEDS Assurance suite https://wiki.refeds.org/display/ASS. To ensure the uniqueness of the identifiers, we expect: https://refeds.org/assurance/ID/unique; or https://refeds.org/assurance/ID/eppn-unique-no-reassign To ensure sufficient identity proofing and credential issuance, renewal, and replacement: https://refeds.org/assurance/IAP/medium; or https://refeds.org/assurance/IAP/high |
Name | cn | Optional (one is sufficient) | The LS Login and the services connected through the LS Login expect to receive the name of the user. For example, when a user applies for a new project or for membership to an existing project, the managers need to be able to recognise who the applicant is. |
| displayName | |||
sn + givenName | |||
| Optional | The LS Login needs to be able to contact the user regarding the status of their account. In addition, many of the services connected through the LS Login expect the email of the user in order to be able to contact the user about matters related to the service. |