Scopes and Claims
The OIDC service supports edu-ID only attribute model configurations. It basically provides data from the personal part of an edu-ID. Optionally, affiliation data is available by using the extended attribute model.
The Switch edu-ID OP releases user attributes on request of certain OIDC scopes as listed below. However, for data economy clients shall only get required claims. Hence, claims released within the scopes can be filtered in the Resource Registry. All the required attributes are then available upon request with the respective scopes on the UserInfo endpoint of the OP if available for this particular user. See the Token documentation for details on claims released within the ID Token.
The following scopes are supported by the Switch edu-ID OP and can be requested by relying parties. Please refer to the OIDC specification for details on the various standard scopes and claims.
openid scope
The openid scope is a standard scope and required to indicate that the application intends to use OIDC to verify the user's identity and in order to get the standardized ID token, according to the Section 2 of the OIDC specification.
With the openid scope, the client is authorized to retrieve the sub claim. This claim can either be a pairwise identifier or a public identifier which should be used to identify the user. It is highly recommended to use the pairwise subject unless there is a strict need for the public one. The subject type can be specified in the Resource Registry.
| Claim | Type | edu-ID source attribute | Description | Additional information |
| sub (pairwise) |
string | pairwise-id (unscoped) | Subject - Identifier for the End-User at the Issuer. | The pairwise subject is the default and shall only be changed if there is a good reason to do so. The pairwise subject is a privacy-presesrving pairwise identifier which is derived from the triple of user, issuer and sector. The sector of a client is given by its sector_identifier_uri which can be defined in the Resource Registry. Like this, one can have a set of client where the same user can be identified across all of them via the same subject. |
| sub (public) |
string | swissEduPersonUniqueID | Subject - Identifier for the End-User at the Issuer. | Alternatively to the pairwise subject, a client can request the public subject which has the same value among all clients. For the edu-ID, the value of the public subject is the value of the swissEduPersonUniqueID claim of the user. It shall only be used if there is a strict need for it which can not be handled with the pairwise subject. |
Scopes related to claim release
For all claims received via a certain scope, make sure to check in the attribute specification for that claim whether it comes as a single value or as an array.
Standard scopes
You can check in the Switch edu-ID attribute specification which claims are supported and which scope is required in the request to receive them. From the standard scopes, only profile and email are supported, and also not all of the possible standard claims are supported.
Note that the email claim corresponds to the primary e-mail address of the user and may change over time. Furthermore, the email_verified claim will always return 'true' since the edu-ID user registration process enforces initial email address verification. This does, however, not guarantee that the address still exists, as there is no re-verification process once the user set it as primary email address.
The standard scopes address and phone are not supported since the user attributes supported by the Switch edu-ID can't exactly be mapped to the claims in these scopes. However, the claims swissEduPersonMobilePhone, swissEduPersonHomePhone, swissEduPersonBusinessPhone, swissEduPersonHomePostalAddress and swissEduPersonBusinessPostalAddress might be available via the https://login.eduid.ch/authz/User.Read scope if configured in the Resource Registry.
Non-standard scopes
For user attributes of Switch edu-ID which can't be mapped to the standard scopes, the scope https://login.eduid.ch/authz/User.Read has been introduced. It can be treated like all other scopes in client requests to the OP. Check the attribute specification to see all the supported claims in this scope.
offline_access scope (refresh token)
Clients configured for the scope offline_access receive a refresh token (OIDC Spec). The refresh token is particularly useful for personal mobile clients, to prevent a user from having to re-authenticate every day. At client registration in the Resource Registry, specify the Offline Access grant type so the OP will grant the client offline_access scope on request.
Check the Tokens documentation for details on the refresh token.
Additional scopes
The Switch edu-ID OP is able to support additional scopes not related to claim release. Use cases are scopes in access tokens, which are used for accessing a separate resource server where the trust between client and resource server is established via Switch edu-ID. Support for resource servers is currently on the Roadmap and is to be implemented.
acr claim
At the authorization request, the client can request claims. This is particularly useful if the client want to ensure MFA is enforced for the login. See the 2-step login documentation page for details.