Add identifier for IdP Identity Switching capabilities

[martin-lindstrom]

The term Identity Switching (id-växkling) refers to cases where an identity (issued and asserted by an Identity Provider) is used to create another identity. This may typically happen in user provisioning cases where an organization or a federation uses its own primary identities and makes use of a certain Identity Provider's assertion only to set up its own identities, and after that the Identity Provider is no longer used.

Some Identity Providers accepts and allows Identity Switching and others do not. The reason for an Identity Provider policy to prohibit Identity Switching is mainly commercial. If a relying party only uses the Identity Provider for provisioning of its own user identities the Identity Provider will service very few requests from this relying party compared to the case where the Identity Provider is used during the entire life cycle of a user (i.e., for each login).

Sweden Connect federation agreements/contracts do not specify whether Identity Switching must be supported. This means that there may IdP:s in the federation that allows Identity Switching and that prohibits it. However, there is no technical way of finding this out.

This issue suggests that a new metadata entity category, allow-id-switching, is introduced. The IdP:s that allows/accepts Identity Switching based on issued assertions then declare this category in its metadata.

Or should we treat identity switching as the default and use a prohibit-id-switching category instead?

There may also be cases where a certain IdP normally prohibits Identity Switching but accepts this for some relying parties, for example regulated by bilateral agreement outside of Sweden Connect.

The question is whether we have to cover this case of if it is out of scope for the Sweden Connect specifications. I tend to lean to that this is a thing between the relying party and the Identity Provider/eID issuer.

[GunnarKlintberg]

From a technical point of view Federated signing is a ID Switching technology. In the Policy it must be very clear this new Category shall not apply in use case when the IdP is used in Authentication for Signing if the federated signature service is used.

And what about the growth of Proxy IdP's will be a challenge when they translate SAML specifications from one federations to a "local" one to be able to not need to rewrite the SP implementations? If Policy saying that the LOA 3 certification from Sweden connect is lost when add proxy IdP that does not map 1-1 of all Matadata Category and also SAML profile is a challenge. Today we have a gray zone that is not good when we certify the eID but is lac of good policy what MUST be applied in the IdP side if you shall end-to-end use this Loa 3 "certification" when IdP and maybe proxy IdP's is used in the implementation. But the last is maybe little bit out of scoop of the new category.

[martin-lindstrom]

I think that this really belongs to the federation policy and we don't have to mention anything about this in the context of the technical framework.