Upon client initiation of a an OIDC Authorization Code Flow for a citizen user, federation is performed as shown below. Citizen access to the eHealth Infrastructure goes through NemLogin.

...

SAML Attributes for Citizen Users

NemLogin provides a set of SAML attributes in a SAML assertion which is used to identify the citizen. Other attributes are also part of the SAML attribute; they are however not currently used. The table below lists the current attributes that are delivered by NemLogin:

Citizen User Access Tokens

Citizens accessing the eHealth Infrastructure is are handled a bit differently from other users accessing the platform. As citizens do A citizen does not carry a context of system roles and rulesorganisation. Instead, it access is limited to Patient data about the citizen itself and scoped by herself/himself.

Using the provided SAML attributes. This means that the citizen is not able to switch context and that the citizen can only access data being scoped to him/herself. The scope of access is determined by setting the citizen in context of him/herself and not allowing context switches.

Note on Citizen access tokens

In order for a citizen to gain access to its patient data the citizen needs to be created using the https://docs., the infrastructure searches for a Patient resource that corresponds to the citizen. If found, the infrastructure automatically sets the Patient context in the access token and the user_id is set to the Patient resource reference. The citizen cannot switch context and can access only Patient data being scoped to that Patient context.

In case no Patient is found, the access token user_id is set to a UUID instead of a Patient resource reference. This design ensures that federated NemLogin can be verified without blocking the citizen from accessing the platform. When no Patient is found, the citizen is accessing the infrastructure before having been enrolled (created as a Patient) by an employee through https://ehealth.sundhed.dk/latestfhir/ig/OperationDefinition-ehealth-patient-create.html . Failing to have done so will grant the citizen access to the platform but not its data. This will be reflected in the access token as the user_id will be a UUID instead of a FHIR Patient resource reference. This design ensures that federated NemLogin can be verified without blocking the citizen from accessing the platform