After spending a non-trivial amount of time discussing therms like Digital Identity,
Claims, Digital Subject, etc. and very lawyerly interpretations of the definitions on the
Identity Gang Wiki, I thought Iwould take a step back and talk about how I think about identity and how it should work.
Identity Data
To start, I as a human being (yeah, I'm pretty sure I am one of those) who does interact to some extent in the digital world, have manifested myself in a number of locations (on the order of 300).
In this wide variety of locations I have created, stored or somehow caused to be created data about me or associated with me. For example, my email provider has my email (yes, emails sent to me are a part of my identity data), Amazon has my account details with orders back to the mid-90s, Ebay has my account history and my very important feedback rating (a solid 124 with no negative feedback in the 8 year's I've been there, thank you very much!). In addition all of those locations required me to create some security credential (e.g. username/password) to use to access my identity data (so that other bad guys didn't get access to it).
Note that some of this data is not owned/created/asserted by me, but instead some third party's assertion (such as Ebay's Feedback rating -- it wouldn't be worth much if I could just change its value).
This entire conglomeration of data, credentials and all, is what I refer to as Identity Data. The Identity Gang term Digital Subject, I think, refers to the entity to which all this data applies to/is related to, etc..
Identity
Identity is a grouping of Identity Data that is tied together in some way. In today's walled-garden world, the grouping tends to be the Identity Information related to a specific account at a specific provider. So, I see this as me having more than 300 independent identities at all those locations I mentioned earlier.
For many reasons (perhaps something to cover in another story) this situation of multiple independent identitys will change over time to a smaller number of identities that share access to the same group of Identity Data. The portions of the Identity Data within an Identity that may be visible to any particular party may be different (such that my name and email address might be visible to my blogging site, while my name, phyiscal address, and phone number might be visible to an ecommerce site). Federation is the term used to describe this sharing of identity data at multiple parties. I'll discuss that in more detail below.
This model of sharing the same Identity across multiple parties makes it easier for the user to maintain their data and also can increase the security of the users data by enable the user to select some form of strong authentication (or even a good username and password that they don't share elsewhere).
A user may have all of their Identity Data under a single Identity and use that one identity everywhere. My mother is probably a good example of someone who would do this.
A different user may have different sets of Identity Data (which may be duplicated) under different Identities. For example, many of us will have personal Identities and work (or job related) identities. My Identity at Intel is separate and distinct from my identity at home (even though I use the same name in both places). Other reasons for doing this include things such as manifesting a pseudonym or keeping public and privite lives separate.
Federation
Federation is when I use my Identity (remember: group of identity data) at one provider to establish/use a relationship at a second provider.
Sometimes this relationship is such that the 2nd provider gets a persistent handle for me so that when I return later they can associate my prior actions at their site (perhaps remembering previous orders, or preferences which I've recorded there). This type of federation is common in an ecommerce and/or premium service environment and in most privacy conscious settings, results in the generation a unique identifier for the user between those two providers rather than using the same identifier at multiple providers.
Federation is also used to describe situations where a persisten handle is not generated for the user. A common example of this is when one party just provides some non-unique data to the second party (such as membership in a group). In such case, the second party can't tell the same user has come back (at least not because of these protocols), but is still willing to provide services to the user knowing that they are a member of the group.
I'm not so convinced about the non-persistent thing being called "federation", although I do agree that it's a very useful use case.
Tags : identity / federation / identity gang