Account linking and the F-word

I recently suggested that account linking is an identity Trend, and got some interesting responses to my query about what people think are Trends vs. Transients vs. Tropes vs. Transparents.

Separately, on the “ID Gang” mailing list (sorry, private and not linkable) over the last couple of days, there’s been a discussion about the beta service Spock and the fact that it asks you to supply your login credentials for other web accounts, such as LinkedIn. That’s not a very attractive proposition. The question was posed on the list: What’s a better way to associate profiles than this? I bet you can guess what my answer was…

The better way would be for Spock to link its account for you with those other ones, allowing a more limited version of your identity information to pass between them without Spock having to know your credential data on the other side.

This process of account linking, along with ways of avoiding sharing your “real” account identifier on each side for even more privacy, is something Liberty ID-FF and SAML have specified for a long time, and there are lots of existence proofs in the world (with a variety of technologies). You can do the linking implicitly when a new local account is created after you’ve been transferred over from your remote login site, or you can arrange to do it explicitly (e.g., by having the user opt in in real time) if a local account already exists.

Such linking would require a service like Spock to give up some control and to accept a more loosely coupled and partial-trust relationship, not just between it and another service (or between it and an OpenID provider or whatever), but also among them and the user. So an important point about account linking is that it’s more about what distribution of trust and responsibility and ownership all of the parties are willing to live with, rather than deep technology or protocol details, which means we’re immediately flung into the world of “business decisions” and governance matters.

I later commented that account linking is an essential process you have to go through to get any kind of unified identity layer, given that lots of valuable local/limited-scope accounts are already in existence. Account linking is precisely how we would begin to dissolve identity silos, the same way ATM network silos got dissolved: one relationship at a time.

Now, since “silo” came up as a Trope in the comments to my other post, as did “federation”, perhaps I should swear off both words unless I qualify every usage for the sake of clarity and cliché avoidance! Along these lines, following are additional (slightly edited) thoughts I shared in the Spock thread having to do with terminology.

Some term disambiguation is probably warranted, given that this gets close to the dreaded F-word (federation and its variants):

There are several ways SAML and Liberty use it, and an important one is to talk about federating identities (plural). To a first approximation it just means account linking (it’s a little more subtle than that because the protocols don’t actually assume that a persistent “account” or “user record” or whatever has to exist).

By the way, federating identities doesn’t necessarily imply the existence of a circle of trust (a federation of business partners who have pre-negotiated a relationship, like the United Federation of Planets) — it could be done ad hoc. Scott Cantor has often complained about the infelicitousness of Liberty having given the impression that the technical process relies on a business contract.

Sometimes this same thingie is discussed using the term identity federation (the process of linking) or (a) federated identity (the resulting link), but I’ve come to believe these are often ambiguous because there’s a narrow-scope usage and a broad-scope usage.

The broad usage, typically in the form federated identity or federated identity management, is more in this sense: technology that is capable of distributing identity information and delegating identity-related tasks (at least including authentication) across domain boundaries. The organizational distances between the parties can be arbitrarily large — it’s not enough to say just “distributed” because this is often used for multiple boxes that might live inside a single enterprise. It thus seems to me that OpenID qualifies as “federated identity” just as much as SAML does. :-)

To complete these thoughts about terminology, I think identifier namespace is a fine phrase to use in place of the sometimes-pejorative silo. OpenID has an extremely large, flat, unified identifier namespace that consists of URLs and XRIs. Most other federated identity system deployments have an identifier namespace that’s smaller than this, maybe more privacy-sensitive, and certainly not guaranteed to be something a consumer site could understand or should use directly.