There are two fundamentally different architectures to implement identity management: the federated (or networked) approach, and the claims-based approach. I have written about the risks associated with federated identity management before, and about the “identity crisis” in general: 1, 2, 3 and 4. In a talk Gregory Neven gave at our institute, he mentioned a risk of using a federated identity management system I wasn’t explicitly aware of.
In a federated identity management system, if user wants to access a service, he is redirected to his identity provider (IdP). The user must sign in to his IdP, who then signs a statement about the attributes that are valid for the user that are relevant for providing the service. The federated approach is very popular currently: Facebook connect, and many national eID schemes (like DigiD in the Netherlands) work that way. SAML is the underlying standard for these systems.
The problem is that the IdP must be online. In particular the signing key used to sign the statements the IdP issues about the user attributes must be online. Yet this signing key is, depending on the kind of attributes the IdP can vouch for, a highly valuable and therefore sensitive piece of data. And it is quite difficult to both make a piece of data highly available and very secure at the same time.
In the claims based approach, made popular in attribute based credential (ABC) schemes, the identity provider is not online: it is not involved when verifying user attributes. In ABC schemes the user obtains his credentials from the IdP in a separate phase. For high security attributes (like attributes that provide access to very sensitive information) the IdP may even require the user to go through a complex issuing protocol, that may even require him to visit a specific location with a credential issuing terminal. The signing key can be much better protected in these cases. This may be relevant for instance in critical infrastructures, financial transactions, and military or law-enforcement applications.