The affiliation identity model of the Switch edu-ID has been designed to be compatible with services in the former SWITCHaai federation that "know" nothing of edu-ID. These services can be accessed by users with edu-ID the same way as before with the organizational SWITCHaai account. The only difference from a user perspective is that authentication happens at the Switch edu-ID IdP instead of the organizational IdP.
With the affiliation attribute model, a service gets attribute information compliant to the SWITCHaai attribute specification. From the perspective of the service, it just gets an attribute assertion from one HomeOrg. In the diagram below, this would be an assertion from either HomeOrg UniA (A), or HomeOrg UniB (B) or HomeOrg eduid.ch (P). No configuration changes or other adaptations are necessary to support users with an edu-ID account.
With the university members only configuration, a service only gets the assertion from one current affiliation of a user. If a user has more than one affiliation, the Switch edu-ID identity chooser kicks in where the user picks the desired affiliation to access the service. Users without at least one current affiliation are denied access.
In the diagram above, the service would either get the attribute assertion A or B, depending on the user's choice in the discovery service or the affiliation chooser.
Note that the type of accepted home organizations can be further specified in the intended audience setting in the resource registry.
With the all users allowed configuration, a service gets the assertion from the personal identity or from the current affiliation of a user. If a user has one or more affiliations, the Switch edu-ID identity chooser kicks in where the user picks the desired identity to access the service.
In the diagram above, the service would either get the attribute assertion A, B or P.