A taxonomy of federated applications

Eve's recent post on assurance use cases, specifically how she overlayed particular use cases onto a m04-04y type grid, made me think I might be able to ride on her coattails by building on the idea (as is my wont).

My starting point is the assumption that a federated SP/RP (ie some application that relies at least in part for obtaining user identity from some other entity (i.e an IdP) through whatever means) can be distinguished by

1) the nature of the identity that the RP expects/demands in order to provide to the user whatever service it is set up to provide. Eve listed 3 broad categories for this data

a) Anonymous authorization/personalization - the user shows up at the RPs door with nothing more than a set of attributes about themself, and the RP is able to do its thing based solely on these attributes. Importantly, the attributes will be those that will generally not allow the RP to actually pinpoint the user, but only place them within some larger group (for which the RP wants to distinguish service). What teh RP does with the attributes could be personalization, or might be access control (e.g. think RBAC). I'm going to refer to this scenario as "bag 'o' attributes".

b) Simple cross-session correlation - the RP wants to be able to correlate multiple visits from the same user so as to provide some sort of seamless experience/relationship across those visits. For this to work, the user has to present some identifier to the RP that will be consistent across their multiple visits - this is the 'pseudonym' scenario.

c) Real-world identity mapping - the nature of the RP application demands that it be able to map the user into a real-world (mortgage-carrying, investment fretting, dieting, etc) individual. The user must present to the RP attributes that map to an actual angst-ridden human, e.g. SSN, drivers' license, home address, etc.

2) the RP's willingness to accept the chance that some other user will be able to maliciously present the above types of identity by accessing the real user's account at the IdP. All else being equal, the RP's risk-tolerance determines what expectations it will have governing how the user authenticates to the IdP - through weak or strong methods.

Below is an attempt to place a number of identity use cases onto the above 2 axes. A use-case (as a stand-in for the involved RP) is distinguished by the nature of identity that flows (attributes, pseudonym, or real ID) between IdP and SP, as well as by the strength of the initial authentication to the IdP.

Some of the use-cases are straightforward I think. Let me try to defend some of the others

1) Before I can borrow a book from my local library, it needs to know my address (presumably so that it knows that my taxes have funded it as well as to provide a mechanism for dealing with delinquent borrowers). But the risks of book theft don't warrant strong authentication. Similarly for verified Twitter accounts - real identities married with weak authentication (n.b. this will change when Ashton's twitter account is eventually hacked).

2) For a bank in Panama (or Switzerland?), unconstrained by 'Know Your Customer' regulations or the equivalent, and able to provide banking services without knowing the customer's real identity, the identity asserted by the IdP might be a pseudonym, but the expectation would be for a stronger authentication to the IdP.

3) If I could I'd set up a filter for approving comments on this blog along the lines of 'Allow if commenter has a Identerati reputation of 5 or more'. I wouldn't have to approve individual comments, nor specify my rules in terms of particular individuals. All the commenting approval application would require would be for the IdP to assert the would be commenter's reputation. The box for this one is in dotted lines because its more speculative. It also spans out to pseudonym because thats the current default.

4) In a typical e-commerce scenario, the RP wants to be able to offer consistent & cohesive service to the user (the elusive 'long-term relationship')  so needs from the IdP a pseudonym for the user to index off, but ultimately is most interested in the 'will I get paid' attribute (as manifested in the 'valid credit card number'. Also, as the RP has a separate mechanism for verifying its 'payment probablity', it may be more willing to assume the risk inherent in a low or mid-strength authentication to the IdP.

I'm sure I've missed a bunch....