In the current paradigm of Identity Provider, Credential Provider and Relying Party, the question arises: who cares most about proving the identity of the individual requesting service?
The RP must manage their own risks related to identification. But how should this be accomplished?
Is it the responsibility of the Identity Provider to establish the uniqueness of the individual? Or should that fall to the Relying Party? The answer might surface when we consider what identification means to the RP.
The processes and methods for disambiguation reside with the Registration Agent function (the RA collects information from the individual registering). Assuming that techniques to prevent fraud, impersonation and other manipulation are in place for the Registration Agent, all that remains is to build up enough identification elements such that within the desired population of individuals, the incidence of non-unique identities is within the tolerable risk level.
The RP is interested in ensuring that the right services are delivered to the right individual. The higher the value of the transaction or the greater the negative impact of misidentification, the more the RP must ensure correct identification. This means, eventually, the RP wants to be able to disambiguate every individual in the service population.
Another factor is liability for identification errors. If the RP uses an external IDP, there must be contracts or federation agreements established such that the RP can account for the resulting risk. The identity federation operator might be interested in avoiding moving liability away from the RP, and thus decline to provide identity disambiguation services as a shared service.
So, where to put the RA?
Put it with the IDP as a shared resource if you want to build an Identity Registry which can be used for identification information sharing, and the federation conformance program is very robust.
Put it at the RP if centralization creates too much uncertainty and complexity to properly manage risk or engage in contracts, or if federation conformance is uncertain.
Put it with the Credential Provider if a hard link between Credential (Token) and Identity Record is desired.
Don’t forget that the discussion is shifting towards inventing a universe of Attribute Providers – in which attributes can be verified and assembled by whichever party needs them. The way that Attribute Providers come into existence within the Trust Frameworks and federations may make some RA placement choices obsolete.
So. If it has the attributes of walking like a duck and talking like a duck, the registration agent and the RP care if failure to disambiguate between a duck and the Killer Rabbit of Caerbannog leads to general mayhem and destruction.
(all right, all right, it’s a bad multi-mixed-metaphor – but it made for an interesting title)