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
1A: If the level of assurance is included in XACMLAuthzDecisionQuery → request → Resource → LevelOfAssurance
- 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
- 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.
- The LOA of the Machtiging (machtigen) MUST be equal or greater than the LOA included in XACMLAuthzDecisionQuery → request → Resource → LevelOfAssurance.
1B: If the level of assurance is NOT included in XACMLAuthzDecisionQuery → request → Resource → Level of assurance.
- Continue the process with the LOA which is specified in the Service Catalog.
2: Check ServiceUUID
2A: If the requested service is NOT a portal service:
- The ServiceUUID at XACMLAuthzDecisionQuery → request → Resource → ServiceUUID MUST match the serviceUUID (of the ServiceDefinition) which is part of the Machtiging (machtigen).
3: Choose (Dienstafnemer)
3A Generate List of Dienstafnemers for which the user has Authorizations (Machtigingen)
3B Remove Authorizations that are for other DV
3B1 In case of a specific service request (ServiceID Index > 0): Remove the Dienstafnemers where the user does not have an Authorization for the requested Service.
3B2 In case of a Portaalfunctie request (ServiceID Index = 0): Remove the Dienstafnemers where the user does not have an Authorization for any service of the Dienstverlener
3C Filter based on ECTA
3C1 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
3C2 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.
3D 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)
3E 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
5A if the request is for a portal service
5A1 create a list of all services of the DV
5B 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
7A If the request is for a specific service
Select the specific authorization of the highest LoA.
7B If the request is for a portal service, from the list of services take the lowest LoA of all authorizations.