eduID is a lot of things, including an identifier. The eduID IdP provides different identifiers, among other attributes to allow functioning as an IdP in SURFconext. 

The eduID concept requires all services to receive a targeted eduID number, so services can't profile a user by sharing data. An user can allow data exchange between two services by giving consent in an OIDC token authorisation. The SURFconext API-security service can translate the eduID identifiers targeted for the two services. Two services belonging to the same institution (determined by the coin:institution_guid in the SURFconext administration) will receive the same eduID identifier.

What eduID identifiers?

The current eduID IdP delivers the following identifiers to SURFconext

When a service connects to SURFconext, it can request the following identifiers (matching the examples above):

What should I use?

A service should only receive the information it needs for it's operation.

• If no persistent information on the user needs to be stored, a transient NameID should be used. This will be different each login
• If the user should be recognised at his next logon a persistent NameID can be used. The value will be the same at each logon, but unique for this service
• If the user needs to exchange data with other educational services (using SURFconext API security), or if the user should be recognised if he changes to another institution, the eduID identifier (urn:mace:eduid.nl:1.1) should be used.

Identifier lookup

Local identifiers

A student can have both an eduID and an institution account, and these can be linked. When he authenticates to an institutions service with an eduID, the service can receive the eduPersonPrincipalName (eppn) attribute for the institution. This way, the student's information can be found in the institutions information systems. The targeted eduID identifier can be added to the users profile in IdM or Student Information Systems. This feature is already present in Osiris.

Receiving  the institutions eppn can be done in two ways:

• SAML: SURFconext support can configure the service to insert the eduID when a user authenticates using the institutions IdP. The eduID attribute will be present in the SAML assertion. 
• oidc: When using oidc for authentication, the eduID identifier will be available as an extra claim in the response to the introspect request.

Example usage

During registration for a course at another institution, the user has to approve data transfer between his home institution and the guest institution. For this, he authenticates with his eduID at the guest institution using oidc, and approves the oidc-scopes needed for the data exchange. The guest-institution receives a oidc-token to access an api at the home institution. When the API is accessed, the home institution performs a call to the SURFconext introspect endpoint to validate the token. In the response some data on the user is send, including the eduPersonPrincipalName for this eduID user at the home institution. This eppn can be used to find the user in the student administration, and return the correct response to the API call from the guest institution.

Targeted eduID

If a service receives an eduID targeted for another service (eg, when an institution to institution API call sends this identifier), the service can lookup the correct targeted eduID identifier by using the eduID API.