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.

No tags for this post.

7 Comments to “Account linking and the F-word”

  1. John Cowan 17 July 2007 at 9:25 pm #

    I don’t understand this. How can a federated identity not require mutual trust? If, for example, I am going to federate my identities with those of Sun Microsystems, and I am a paranoid weasel who doesn’t want you to have access to my system, don’t I have to trust Sun Microsystems that none of the identities other than “Eve Maler at Sun” that it claims to certify represent you?

  2. Eve M. 18 July 2007 at 6:32 am #

    Yes, identity providers and relying parties and users have to trust each other to a certain point to get anything done. In the case of OpenID, its design center requires that the asserting and relying parties not have had to “meet before” to set up a trust relationship, but real-life deployments do sometimes preconfigure trust with blacklists and whitelists. Parties using protocols like SAML are usually pretty used to having to set up an agreement that specifies the level and nature of trust; the InCommon federation is an excellent example of this. But all this is still a lot more “partial-trust” than the alternative Spock is using, which is to ask you to trust it with something precious: your LinkedIn account name and shared secret. Even if Spock weren’t (frankly) a web nobody today, that’s the kind of information you should be reluctant to hand out.

    Spock today isn’t trusting LinkedIn or allowing LinkedIn to trust it; it’s impersonating you on LinkedIn to get information you’ve stored there. If the two parties, and you, worked out an arrangement whereby you could introduce them to each other for the purpose of account linking, and you say it’s okay to share (some of) your profile data in one or both directions, each could potentially accept single sign-on assertions containing authentication confirmations and attributes from the other side without knowing your actual authenticator data over there.

    Note that, in addition to keeping Spock from knowing your password on LinkedIn, it also decouples the process of using Spock from authentication methods that might involve something more than or different from username/password, like if LinkedIn used a site key for you to authenticate them.

    What would be really cool is a generalized “introduction protocol” that sites can make available to users if they want to try and work out account links between any two sites at which they already have accounts (purely local or already linked to some other one). I’d much more readily do that than share all my passwords every which way. If we managed to make the interface easy to understand and use, and give it some level of contractual assurance around what sites are allowed to do with information they rely on (ha! users imposing click-through agreements on the sites they use! yeah, baby), maybe we’d have a true flipping around of who’s in charge.

  3. […] Via Tom Scavo comes the news (PDF) that the U.S. E-Authentication program has finished revising its architecture to use SAML’s latest version, 2.0, “to better meet the authentication needs of agencies.” I noticed that this issue of the GSA Federation News newsletter also has an article on interfederation, the higher-order joining together of existing federations, and GSA’s efforts to figure this out with the Internet2 InCommon folks. This is a really important tool for achieving the ever-wider linking of accounts that I’ve been blathering about lately. (Ooh, and it’s another term I can add to my growing F-word lexicon.) […]

  4. John Cowan 20 July 2007 at 8:44 am #

    Thanks for the explanation, Eve.

  5. Eric Norman 22 July 2007 at 2:17 pm #

    I think Eve’s first comment above about federating identities (the subltety about persistent accounts) is even more subtle. I would say that at least one of the parties must maintain a persistent account.

    In lots of non-pairwise federation schemes, this party is called the IdP. I.e. a user always has a persistent account with an IdP. If that were’nt the case, then an IdP wouldn’t maintain records about the user and wouldn’t be able to perform its primary function, which is to supply testimory about the accuracy of claims by the user.

    In the pairwise schemes that Liberty is fond of, I suppose you could say that one of the parties is the “designated IdP”.

  6. Eve 23 July 2007 at 5:31 am #

    Hi Eric,

    I think you’re right that the vast majority of cases involves a service provider that serves in the role of “federatable” identity provider (with a persistent account), and one or more service providers that have local accounts but are always consumers/relying parties of “federated info”. It’s not impossible to have an entirely transient connection using SAML protocols, but it’s obviously of much more limited utility. That’s why you’ll see, in the SAML Technical Overview, explanations of typical flows for usage of both persistent and transient pseudonyms that assume a persistent account store on the IdP side. I don’t think the language “designated IdP” is needed because it’s expressed in the protocol flow — it’s the party that does the responding to authentication requests etc.

    BTW, the pseudonyms have to be pairwise unique in order to avoid correlation of your activities by multiple RPs, but one common deployment topology is, of course, a hub (IdP)-and-spoke (several RPs) arrangement.

  7. […] Linked accounts are also quite useful for some purposes. By linked accounts, I mean a system in which I fill out a form that authorizes one business to take money from one of my accounts when a charge has been incurred. For example, I authorize my dentist to charge my insurance account. Linked accounts are a little heavy on the paperwork side. I have to set up everything and make sure both entities know their role. It’s easier when I can present a card, like my insurance card, to set up the initial link. I generally don’t like linked accounts because I prefer knowing when the money is going to leave my account. But there are times I use them and don’t know a better way to handle some situations, like the dentist. […]