Add requirement about segmentation of SSO identities

[randomstuff]

In the context of OpenID Connect, I was wondering whether a requirement mandating that user identities from different IdPs are properly separated i.e. that a IdP cannot spoof a user from another IdP. This is actually relevant for any SSOs and might go into V2.

Original wording:

Verify that, if multiple identity providers are used by a RP, the identity of a user from an identity provider cannot be spoofed by another identity provider (by using the same user identifier).

Alternative wording:

Verify that, if multiple identity providers are used by a relying party, a malicious identity provider cannot login as users from another identity provider (eg. by using the same user identifier).

The wording should reject unintended/malicious spoofing of user identities but still allow cases where the sharing of user identities between different IdP is intended / by design.

[TobiasAhnoff]

I was thinking that this is not limited to users, it could also be an issue for machine-to-machine (OAuth client credentials), all scenarios where the RP use multiple identity providers (issuers).

Maybe have something that not only for OIDC, or do we already address this in other issues?

Verify that, if multiple identity providers are used by a RP, the identity from one identity provider cannot be spoofed by another identity provider (by using the same user identifier).

or, from the JWT spec "The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

Verify that, if multiple identity providers are used by a RP, the identity MUST either be scoped to be locally unique in the context of the issuer or be globally unique.

[randomstuff]

Maybe have something that not only for OIDC, or do we already address this in other issues?

Yes, that's why I was suggesting it should go into the V2 chapter (instead of the OIDC one) and was avoiding OIDC-specific terms. This would equally apply other user type of user identity sources (SAML, LDAP, CAS, etc.).

[elarlang]

Steps here:

• formulate requirement text
• check we don't have duplicates in V51
• think about suitable section

[elarlang]

ping @tghosth as it is in V2 area