Vaststellen bevoegdheid

In the paragraphs below is an example implementation of all the functionality which a MR must support, this is not the required implementation, other implementations are allowed as long as they deliver the same result.

Process to find applicable authorisation

1. Check LOA levels

   1. If the level of assurance is included in XACMLAuthzDecisionQuery → request → Resource → LevelOfAssurance

      1. The LOA of the authentication means in the AD assertion MUST BE equal or greater than the LOA which is requested included in the XACMLAuthzDecisionQuery → request → Resource → LevelOfAssurance

      2. The LOA which is included in the DC MUST BE equal or greater than the LOA which is requested included in the XACMLAuthzDecisionQuery → request → Resource → LevelOfAssurance.

      3. The LOA of the Machtiging (Machtigen) MUST be equal or greater than the LOA included in XACMLAuthzDecisionQuery → request → Resource → LevelOfAssurance.

   2. If the level of assurance is NOT included in XACMLAuthzDecisionQuery → request → Resource → Level of assurance.

      1. Continue the process with the LOA which is specified in the Service Catalog.

2. Check ServiceUUID

   1. If the requested service is NOT a portal service:

      1. The ServiceUUID at XACMLAuthzDecisionQuery → request → Resource → ServiceUUID MUST match the serviceUUID (of the ServiceDefinition) which is part of the Machtiging (Machtigen).

3. Choose (Dienstafnemer)

   1. Generate List of Dienstafnemers for which the user has Authorizations (Machtigingen)

   2. Remove Authorizations that are for other DV

      1. In case of a specific service request: Remove the Dienstafnemers where the user does not have an Authorization for the requested Service.

      2. In case of a Portaalfunctie request : Remove the Dienstafnemers where the user does not have an Authorization for any service of the Dienstverlener belonging to the requested portal service.

   3. Filter based on ECTA

      1. In case of a specific service request: Filter the Dienstafnemers where the available EntityConcernedTypes of a Dienstafnemer cannot fulfill any ECTA set of the requested service

      2. In case of a Portaalfunctie request: Remove the Dienstafnemers from the list where the available EntityConcenedTypes of a Dienstafnemer cannot fulfill any ECTA set of any service of the Dienstverlener. Note: Here a Dienstverlener/Dienst combination can occur that later when filtering on Service Restriction turns out not to be usable.

   4. Alternative flow: No Dienstafnemers
      If the user does not have any authorizations left, the MR MUST inform the user and offer the option to cancel the login process (link to cancel flow).

   5. Let user select the Dienstafnemer he wants to represent
      Note: MR MAY skip this step is the user can represent exactly one (1) Dienstafnemer.

4. In case of a Chain authorization and multiple Intermediairy organizations, let user select the Intermediary organization.

5. Determine the list of services

   1. if the request is for a portal service

      1. create a list of all services of the DV

   2. If the Dienstafnemer selected is a Location (the authorization is limited to a Location), remove the services that do not indicate that they can respect restricted authorizations.
      Note: that there is multiple negative logic here. If the service specifies ServiceRestriction=Vestigingnummer it indicates that it can handle restricted authorisations and unrestricted authorizations.

6. Alternative flow : no applicable services
   If the user does not have any authorizations left (the services list is empty), the MR MUST inform the user and offer the option to cancel the login process (link to cancel flow).

7. Determine the LoA

   1. If the request is for a specific service
      Select the specific authorization of the highest LoA.

   2. If the request is for a portal service, from the list of services take the lowest LoA of all authorizations.