If it walks like a duck, who cares if it’s actually a killer rabbit?

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)

4 thoughts on “If it walks like a duck, who cares if it’s actually a killer rabbit?

  1. Is there room for a blended model wherein a central ID registry provides coverage for say 80% of the use cases but the other 20 need (for example) that hard link between credential and identity record? Or does this become too complex to manage ass a single system?

  2. I think you’ve kind of answered it yourself, or at least implied it – ‘follow the money’.
    If you follow the money (and that will lead you to different parties or combinations of parties in different use cases). then you’ll know who is bearing the risk, what remedies are available.

    Whether you have a separate RA may be dependent on whether it can stand up authoritative sources of identity information. Personally, I wouldn’t get hung up on it. After all, how many times are you going to use it? It might be an over-generalization, but in essence it is a one off event for each service it is applied to, assuming all the other parts of the process can be trusted as well..such as binding the identity to the credential, and the credential itself.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s