Buy or Build

Don Schmidt defines federated identity as

an approach to identity management that allows one organization to grant or deny access to its protected resources based on digital identities managed by another [trusted] organization. The key point is that the resource provider relies on an externally managed identity, rather than creating another locally managed identity for the subject requesting access

My thoughts:

1. an exclusive focus on 'grant or deny access' seems too narrow as there are lots of other ways that the identity requestor might use the externally managed identity it receives beyond access control, e.g. simple customization like a 'Hi Bob' welcome screen.
   
2. stipulating 'organization' would seem to preclude those cases where the user hosts their own identity attributes (e.g. CardSpace personal cards, Liberty ID-WSF clients). But perhaps that is the intent?
3. is specifying 'trusted' meant to rule out the opt-described OpenID dynamic model? Even in this case, I'd argue that the RP trusts the OP (it is willing to accept the OP's claims after all), albeit probably not very much.
   

Nevertheless, I completely agree with Don's key point, that federated identity involves/requires identity outsourcing - essentially, an RP decides to 'buy' identity rather than 'build' it, and thereby enjoys some reduced set of responsibilities (and possibly associated risk) for identity operations.

By this criteria, of course all key identity initiatives, as they all make possible the 'buy' option, can be described as 'federated'.

One Shibboleth down, only a few more to go.

Tags: federated identity