A Question of Trust?

A question that comes up from time to time when discussing federated access management is "how can I rely on another organisation to manage accounts for me?". Federation saves services the trouble of managing user accounts by instead delegating the job to an external identity provider, but it's entirely reasonable to think carefully about that. Why should any service trust someone else to manage the keys to its valuable content?

In research and education federations, we have perhaps the best possible answer – that the universities, colleges and schools who act as identity providers use those same accounts, information and processes to protect their own systems. If the identity provider makes a mistake then its own data and systems are likely to be harmed at least as much as those of the service providers that rely on it. For most research and education service providers, that shared interest is likely to be sufficient. For the few providers whose service involves more risk than the identity providers' own, that may need to be supplemented with something else (whether that's additional checks on users, different means of authentication, or whatever your particular application requires).

But if, rather than "borrowing" a function that the identity provider is already doing in its own interest, you are asking them to do something specifically for you, then you have to fall back on one of the models used in the commercial world. Those seem to leave more doubt about whether you can rely on the provider to actually do as you wish:

• The service provider could simply pay the identity provider for what it does. That's a straightforward commercial transaction, but how do you (as service provider) know how much of the fee the identify provider is actually using to run the service you rely on? If the identity provider is commercially motivated, the answer is likely to be "as little as possible", to maximise its own profit. How much of an incentive do they have to keep your business? Commercial confidentiality means you’re unlikely to know.
• So maybe you try to increase that incentive by agreeing that the identity provider will be liable for any damage caused by their failure. You hope that will encourage them to do their job more diligently but, again, you don't know how they will actually respond. Many organisations deal with liability by taking out insurance. Whether that requires the identity provider to work better will depend their insurer's assessment of the risks, not yours. Or they may decide to "self-insure", balancing the income from the contract, the cost of delivery, and the risk of getting caught. Liability may give you a better feeling for what losses you may be able to recover, but it still doesn't give you much idea of the identity provider's actual intentions or practice.
• Or you can offer the identity provider its own interest in your success. That's typically the bargain that supports "free" identity provision – the service provider gets accounts managed for it, the identity provider gets information about how those accounts are used. So long as the identity provider cares about the accuracy of the usage information that it receives, it should have an incentive to manage accounts properly. But individual users, who in this model are "the product", may not be so happy about it. It may even encourage them to subvert the identity provider's systems – the same ones the service provider relies on – if they don't feel their interests are being protected.

So in the commercial world federation probably does come down to "trust", but in R&E federations we can do better than that.