When scaling an internet identity solutions (or identity federation or trust frameworks) to many relying parties and identity providers, one is bound to run into scalability issues. I’m not referring to the amount of users, or logins/transactions, but to the relationships that need to be formed between the identity providers and the relying parties. To make things complex, there are technical issues related to this, and organizational issues. I simplify this here to four issues: the technical issues have to do with finding the necessary meta-information (URLs etc), and with protocol translations (not relevant for all scenario’s). The organizational issues have to do with trust (who is part of the federation/trust framework etc) and business aspects. The business aspect is related to business model: in lot’s of business models someone, typically the relying party, is paying another, typically the identity provider. For example, imagine a trust framework in which 100s of relying parties would use 10s of identity providers, and needing a contract between them. This quickly becomes a combinational explosion that does not scale without some form of automation or intermediate party.
Different internet identity solutions address, or do not address, these issues in different ways. In this blog post I write down my current thinking on this subject, hoping for input from others. The alternative architectures I found are:
- A single IdP – avoid the issue altogether. This kind of monopolist identity provider is however not an option in many cases.
- Centralized meta-information – centralize the meta-information, this obviously addresses the technical issues, and can also help with the trust issue since this list can serve as a whitelist. (This list does not have to be physically centralized, and can also be a list-of-list etc). It does not help with the business aspects, or protocol translations.
- Hub – one central component managed by a (very) trusted party that can basically address all four issues mentioned above, but does become a more-or-less monopolist, as used by for example SURFfederatie.
- Broker – similar to the hub architecture, but there is more than one hub (allowing competition between them), as used by for example eHerkenning (eRecognition).
The figure below depicts the four alternatives, with examples (biased to the Netherlands). The numbers indicate the amount of connections from the perspective of the source of the arrow.
There are three major arguments that came to my mind while looking into the architectural alternatives (ignoring the single-IdP architecture):
- Standards compliant – What is interesting is that most (or all?) identity federation standards basically assume the world consists of three type of parties: users, relying parties (aka service providers) and identity providers, and have no concept of meta-data repository, hub (3.5 ? parties) or brokers (4 parties). Going into details is too much for this blog post, but I found that staying standard conformant can clash with the hub and broker architectures, or extensions to the standards are needed that may make it difficult to use COTS federation software (including for the meta-information architecture).
- “Justifyable Parties” – in accordance with Kim Cameron’s Laws of Identity nr 3, there have to be good reasons to add parties, especially when they are in the protocol flow and have access to privacy sensitive information or/and are a security risk. For hub and broker architectures, this can be a difficult trade-off.
- Security – related to both arguments above, but end-to-end security can and I think often is broken when introducing a hub or broker. The hub/broker thus needs to be trusted to an extend that for certain scenario’s is not desirable.
A major benefit of a hub or broker model is that should be easier for relying parties to hook up to the federation, both technically (there only need to connect to a single hub or broker), and organizationally (they trust the hub/broker to keep track of who is trusted, they only need to have a single contract contrary to many for each identity provider).
Disclaimer: the above thinking is work-in-progress, and I’m struggling with simplicity vs accuracy …