October 2, 2006
@ 02:28 PM
Comments [13]
What's Wrong with Identity Silos?

Dick Hardt has a blog post critical of Yahoo's recently announced BBAuth entitled Yahoo’s Identity Silo where he writes

Yahoo has joined Google’s silo building by releasing BBAuth, a mechanism for other sites to access services and data within the world of Yahoo.

Unlike Google’s Account Authentication, Yahoo is allowing their service to be used for SSO and registration.

BBAuth is clearly targeted at Web 2.0 site developers, encouraging them to build apps on the Yahoo platform so that they get access to all those Yahoo users.. While I understand how this helps Yahoo strengthen their relationship with their users, it would seem Yahoo did not learn what Microsoft learned with Passport, as Yahoo is deepening their identity silo, rather then participating in the emerging identity infrastructure.

Given that I've been crusading for Microsoft to build solutions similar to BBAuth and Google's Account Authentication for Windows Live I'm interested in whatever criticisms of these approaches exist. The first thing I should note is that I don't like the term "identity silo". On the one hand it could be considered accurate but on the other it automatically potrays the party being described in a negative light. It's like using the term "baby killer" to describe people who consider themselves pro-choice. Any website which authenticates its users (i.e. has a username/password requirement to utilize aspects of the site) is an "identity silo" because the identity I've created on that site is only usable on that site and cannot be utilized elsewhere.

Lots of really smart people from big companies (e.g. Kim Cameron of Microsoft) and startups (e.g. Dick Hardt of SXIP Identity) with products to sell have now told us that "identity silos are bad m...kay". Since I drink the company Kool Aid, I agree with this premise. From reading Kim Cameron's The Laws of Identity and Microsoft's Vision for an Identity Metasystem it seems the solution to the problem of identity silos is federated identity where I can use credentials from one site to sign-in to another site as long as the sites trust each other. This sounds cool, it's like the promise of Single Sign On without one company trying to be your Passport to using the Internet. :)

So let's say I'm a website that wants to allow users to access their data from other sources besides my wbesite thus liberating their data and enabling new applications, visualizations and mashups. I need some way to figure out whose data to give out to these mashups when they come calling...I know, I'll use the unique username to figure out whose data I'm to give out and I can verify that its really the user asking because I'll require their password. Except, according to Dick Hardt and Eric Norlin this is bad because I'm deepening my "identity silo". Since I'm a practical guy I have only two questions

  1. Are there shipping technologies today that allow me to do what I want in an "Identity 2.0" way?
  2. Are they as easy to implement as telling mashup developers to include a link to my website in their UI and then process the data they get back when the user is redirected back to their site after signing in?
From my reading, the answer to question #1 is No (but we're really close) and the answer to question #2 is Hell No. If you were Yahoo! or Google, would you wait a few years for a technology that is more difficult for the developers you are targeting to adopt than what you can roll on your own today to meet your needs? If the answer is no, does that make you a "baby killer"?

Let me know what you think.


 

Categories: Web Development | XML Web Services
Tracked by:
/ronin/articles/2006/10/02/yahoo-bbauth [Pingback]
« RSS Bandit [Jubilee Release] Status Upda... | Home | Counterproductive Internal Hiring Practi... »
Monday, 02 October 2006 16:36:29 (GMT Daylight Time, UTC+01:00)
So what's wrong with CardSpace or OpenID? Whobar.org would be my practical implementation of choice ..
Paul Downey
Monday, 02 October 2006 19:23:00 (GMT Daylight Time, UTC+01:00)
I see the major risks of "single sign on" but I don't see the corresponding benefits. The risks are obvious: loss of authentication control. But are the benefits really that great? How bad is the currenct situation? Seems to work OK for most of us.
pwb
Monday, 02 October 2006 20:03:53 (GMT Daylight Time, UTC+01:00)
If SSO is the main benefit of these system, the trade-off seems a slight benefit in usability in exchange for a risk of depending on a third-party.
One thing I'd be interested in seeing is some possible exit techniques for those who choose to depend on someone else's authentication infrastructure.

On the other hand, you can argue that both Google's and Yahoo's authentication solutions are not really worth it purely from an SSO standpoint. In general, like 'pwb' above, it's possible that SSO is generally not that valuable.
What they are interesting for is the ability to get access to some of the collected data from the user. At least that seems like a more balanced trade-off.
Julien Couvreur
Tuesday, 03 October 2006 00:00:00 (GMT Daylight Time, UTC+01:00)
Aren't you mixing up two questions here? One is whether I can sign into your site without registering yet another username/password combination with you. The other question is: can third party sites/apps whatever access user specific data on your site, i.e. the mashup question. These are distinct problems.

Identity silos seem to be related to the first problem, not at all to the second. If site A wants to provide user data from user X to site B, site B will need to identify itself in a secure way to site A and user X will need to authorize site A to hand out his private data to site B. I don't see how the question how site B authenticates with site B is related to identity silos.

Now, the flow might of course be that site B redirects to site A, site A authenticates user X, X authorizes A to hand out the data to B. But again, the user only authenticates with site A, so the mashup question is not related to the user authentication, but rather with the question: How does site B authenticate? I.e. how can site A be sure that it actually is handing out the user data to the site that the user actually authorized?

And finally, it seems that you don't see a big problem with identity silos. But here is a HUGE one. Most people use the same username/password for all sites they register with. So, they will use the same for some forum that they use for their bank account. Which means that they have to trust the forum so much that they are willing to give them access to their bank account. Most users are problably not aware of this problem. I think big players like MS, Google and Yahoo should be and come up with secure solutions to this. Of course Cameron is just doing that.
davidacoder
Tuesday, 03 October 2006 00:29:44 (GMT Daylight Time, UTC+01:00)
davidacoder,
I agree that they are somewhat orthogonal questions. However it is the identirati (Eric Norlin, Dick Hardt, etc.) who have decided to conflate both issues not me. I'm simply responding to their criticisms. I suspect one of the reasons they are conflating the two questions is because they believe that the BBAuth model of Site B redirects user to Site A to login then gets back a token (Identity 1.0) should be replaced with Site B requests for claims about the users identity from Site A which is an identity provider (Identity 2.0).

>So, they will use the same for some forum that they use for their bank account. Which means that they have to trust the forum so much that they are willing to give them access to their bank account. Most users are problably not aware of this problem.

On the flip side, I see several problems with the federated identity approach. What happens when I want to change 'identity providers' (e.g. I switch from using Yahoo! Mail or LiveJournal) what happens to all the sites that I have joined using that "identity"? There are other issues that come to mind that make this 'solution' to the problem seem more problematic than the problem it aims to solve.
Dare Obasanjo
Tuesday, 03 October 2006 00:53:49 (GMT Daylight Time, UTC+01:00)
I think you are slightly romanticizing what Yahoo! is doing. They are shipping Passport with some very minor tweaks. Yes, Passport had some issues, but we could have fixed the issues and instead chose to shut it down. We chose to go with a cooperative, federated strategy. I do not get your point about problems with the federated identity -- the only example you give is exactly the same for Yahoo IDs as for CardSpace. If you use a different identity to log in to the service, obviously your profile data stored with that service won't automatically migrate. Same is even true for PUIDs.
Joshua Allen
Tuesday, 03 October 2006 00:58:50 (GMT Daylight Time, UTC+01:00)
Joshua Allen,
And I think you are letting the failure of Passport blind you to the actual demand for what Yahoo! AND Google have done in this space. I've seen nothing but kudos for both moves from developers, the only folks I've seen complaining are "identity 2.0" geeks who think federated identity solves every problem.

As davidacoder points out, the issues are mostly orthogonal. You still need something like what Yahoo! and Google have built to enable mashups. The only gripe then is that it isn't buzzword compliant by using CardSpace/InfoCard/WS-*.
Dare Obasanjo
Tuesday, 03 October 2006 19:17:00 (GMT Daylight Time, UTC+01:00)
I'm sticking with the SSO and data sharing are unrelated problems. I don't think SSO is really all that interesting. Most people solved this problem a long time ago - they use the same name and password for all their 'low value' sites. E.g. exactly the kind of site you would use SSO for. Maybe I'm missing something but I can't help but think that SSO really isn't all that important.

As for data sharing, that I suspect matters but all the current mechanisms suck. What we really need is a client software centric mechanism that can nicely integrate into the browser experience. For example, why in the name of all that is holy in the universe can't I click on a mailto link in my browser and have it bring up my favorite webmail site? (Not that I would ever use webmail but I long ago accepted that I'm not your typical user) Why can't I have a HTML tag that is auto-expanded by the browser into my contact list that I can then use to share data if I want to with the hosting site but the hosting site can't see (E.g. the contacts control), etc. All these silly Javascript hacks exist because the browser isn't nearly pluggable enough.
Yaron Y. Goland
Wednesday, 04 October 2006 01:38:11 (GMT Daylight Time, UTC+01:00)
>Any website which authenticates its users (i.e. has a username/password requirement to utilize aspects of the site) is an "identity silo" because the identity I've created on that site is only usable on that site and cannot be utilized elsewhere.

No. User-centric identity systems like OpenID are portable identities and are utilizable anywhere.

>it seems the solution to the problem of identity silos is federated identity where I can use credentials from one site to sign-in to another site as long as the sites trust each other.

No. Federated identity is hugely complicated and that is why it has not caught on. Most people are beginning to realize that if distributed identity has a chance it is user-centric and not federated.

>Are there shipping technologies today that allow me to do what I want in an "Identity 2.0" way?

No. Not yet. Part of the reason is because of what Dick states, that big companies are not participating in the conversation to make it happen. But it looks like it will, with or without you guys, because it is a superior user experience all around. This aint rocket science. It's just getting people to agree on a relatively simple standard.

>And I think you are letting the failure of Passport blind you to the actual demand for what Yahoo! AND Google have done in this space. I've seen nothing but kudos for both moves from developers, the only folks I've seen complaining are "identity 2.0" geeks who think federated identity solves every problem.

Do your research before passing judgement. 1) it's not federated and 2) yes it does solve just about every "problem". It is the correct architectural choice from a user's POV, but don't take my word for it. And no this doesn't make you a bad person for not wanting to implement, just not very visionary.





Chris Gondry
Wednesday, 04 October 2006 04:00:17 (GMT Daylight Time, UTC+01:00)
Considering the push behind CardSpace on Vista, it unfathomable to me that Microsoft Live! is still debating how to handle identity, and would consider something like BBAuth. If you don't want to confuse developers further the answer better be CardSpace.
christopher baus
Wednesday, 04 October 2006 17:44:06 (GMT Daylight Time, UTC+01:00)
The key feature provided by BBAuth is completely orthogonal to the functionality provided by CardSpace. The fact that BBAuth claims to enable Single Sign On is a red herring which I suspect that few will actually use in practice.

But I might be wrong.
Dare Obasanjo
Wednesday, 04 October 2006 19:09:22 (GMT Daylight Time, UTC+01:00)
Ok maybe there are two issues which BBAuth addresses.

1) Autentication
2) Access to Yahoo! data

I agree that most service providers including MS should offer 2, but they shouldn't require a centralized authentication system.

I don't see authentication as being orthogonal to CardSpace. Maybe access to the data is orthogonal.
christopher baus
Sunday, 08 October 2006 00:07:43 (GMT Daylight Time, UTC+01:00)
Excellent post Dare -

Yahoo bbAuth = Good, critics = shortsighted fools. In a broader sense this gets to the issue of open source elitism.
As a fairly inept developer I want simple, elegant solutions like those that Google and Yahoo (and even MSN!) are handing me on a silver platter at no charge. Many in Open source seem to be so skeptical of the commercial intent that they waste way too much time bickering about whether the big guys are playing fair and using enough of the new standards in their applications. I'm suspicious many old style coders simply fear (correctly) that the old priesthood is dying and they selfishly just want to retain as much of the old style complexity as possible. I saw this as Mashup Camp with critics of Google Gadgets and now with critics of bbAuth.
Joe Hunkins
Comments are closed.