SP Collusion

Dictionary.com defines 'collude' as

'To act together secretly to achieve a fraudulent, illegal, or deceitful purpose; conspire'.

In the context of identity management, the term is typically used to refer to multiple providers communicating together about some principal without that principal's consent.

If each provider stores some aspect of a given principal's digital identity - collusion between them is made possible if the nature of such identity information allows them to infer that it is the same individual with which they both have accounts.

Federated identity management, if done improperly, can enable collusion by simplifying the correlation burden for the rogue providers. This because, valid (e.g. based on informed consent) connections between the two providers and some other third provider can provide to the rogue providers the necessary correlation keys.

Federated single sign-on (SSO) can be used to explore the dangers. In SSO, a user authenticates to an IDP, and then the IDP creates claims to that effect for use at other SPs. Correlation and collusion is enabled if the claims are not created carefully. If the same user presents two different claims to two different SPs, the SPs might be able to correlate the claims as referring to the same principal through any of the following mechanisms:

A common identifier in both claims, e.g. if an email address or SSN is used to identity the subject for which the claim was generated. SAML 2 and Liberty address this by defining mechanisms by which identifiers unique to each IDP-SP pairing are established and used.

sufficiently identifying attributes, e.g. if both claims describe me as male, 41, working on identity management, living in Canada, tired father of 3, then the SPs would be able to infer that their different local acocunts referred to the same user, me.

small-community IDP, e.g. if both claims are issued by an IDP known to only issue claims for a small community of end users, then the SPs can narrow down their focus. If the IDP is associated with a single principal then its trivial.

temporally, e.g. if the two SPs somehow knew that the nature of some other application required real-time data from both of them, then perhaps they could use the timing of the requests to correlate. For instance, one SP is a calendar service, another a shipping service. If both SPs received a request for one of their user's data within some window of time from a home grocers site, then the two SPs could infer that their two users might be the same. If it happened again it would be confirmed.

keying material, e.g. if the keys used to ensure HOK subject binding were to be reused for the two SPs, then they could correlate based on that.

I'm sure there are others.