Posts Tagged: openid


29
Apr 09

Facebook Adopts OpenID

via Inside Facebook:

Less than three months after joining the OpenID Foundation’s board as a sustaining corporate member (i.e. putting its weight and financial support behind OpenID), Facebook has just announced at the “technology tasting” event this afternoon at its Palo Alto headquarters that users will soon be able to log in to Facebook with their OpenID.

Very cool!


7
Feb 08

Major steps forward for OpenID

There’s big news from the OpenID foundation today: Google, IBM, Microsoft, VeriSign, and Yahoo! have joined the foundation’s board. This is obviously a major step forward for OpenID, but it’s also good for the entire open identity movement; the major players are seeing the value in consumer choice and control. At ClaimID, we’ve been advancing these themes since 2005, so it’s especially rewarding to see this news. From the OpenID foundation announcement:

By bringing on these companies and their resources, the OpenID Foundation will now be able to better serve the needs of the entire OpenID community. In 2008, we can expect to see a larger focus on making OpenID even more accessible to a mainstream audience, the development of a World-wide trademark usage policy (much like the Jabber Foundation and Mozilla have done), and a larger international focus on working with the OpenID communities in Asia and Europe. Awesome!

Congratulations goes out to OpenID foundation chairman Scott Kveton, and all others involved in the foundation who’ve worked on this initiative. Scott’s blogged the coverage of the announcment if you’d like some more insight. Again, congrats to the OpenID foundation for this huge achievement – today is a very big day for OpenID and open identity work.

Cross-posted to the ClaimID blog.


6
Feb 08

The Future of Social Software

Last weekend, I spent a few days at O’Reilly HQ for the Social Graph Foo Camp. This was a very interesting experience; I was challenged as both a researcher and practitioner. What I saw made me very hopeful – people agreeing on methods and protocols, solving real problems. Realistically speaking, a camp like SGFoo (or IIW) pushes this work ahead 6 months in the span of just a few days. It’s hard to understate the power of connections, conversations, late nights and lots of coffee and Red Bull.

As it happens, before I went to SGFoo I’d been reading a bunch of stuff on qualitative research methods. Methods books, cases, studies….my brain was very keyed-in to a type of observation that is almost annoyingly analytical. It was hard to shake this perspective as I participated in discussions this weekend. It’s certainly informed some of the thought I’ll share today.

Watching the discussions last weekend was a little like watching the future of social software unfold in realtime. Granted, market leaders will continue to be the vanguard of the movement, but the pathways and patterns these companies will use were the crux of the discussion at SGF. There were a number of advocates for the human perspective and user studies, but the real emphasis was on fast development, prototyping, and seeing what works in the wild. This particular approach has been the hallmark of Web 2.0 development strategies, and I doubt we’re going back any time soon.

Yesterday, danah boyd wrote an interesting piece entitled “just because we can, doesn’t mean we should.” In it, boyd challenges the assumptions of privacy and audience that go into the design of social software; that the desire live publicly is a notion of privilege, available to a select few. It’s hard to disagree. The ideologies that inform Beacon or the initial News Feed are hardly mass-market, and there are countless other exemplars out there.

As a relative outsider to the Valley scene, I found myself being challenged by the assumptions of these new technologies. For a simple example, consider a portable friends list. The idea of a portable friends list is when you sign on to a new service, you can upload or authorize your friends list, and find all of your friends who use that service. Theoretically, this vast, barren new space becomes a rich, social space with the click of a button.

Stepping back for a second, let’s consider the assumptions of this technology. As we’ve seen with Facebook, our networks grow to be very large, a collection of “friends” of varying tie strengths and varying contexts (work, school, family, etc). Furthermore, the process of joining a new social community is one of boundary negotiation and sense-making. That is, you’ve got to learn to crawl before you walk; norms and acceptable behaviors are negotiated over time. When someone signs on to Twitter, friends everyone, and then dumps all their RSS feeds into Twitter, you cringe. They haven’t figured out the norms. Now imagine that, every time you sign on to a new service, you’re forced to learn the norms in realtime, in front of an audience of hundreds of your friends.

The problem is that these assumptions actually aren’t problems in Silicon Valley. If your day job is to design social software, it’s likely you’ve internalized the rules of community, you’re a native. Even if you didn’t know Twitter, you’d figure that dumping your RSS streams into Twitter would be bad form, unless you saw everyone else doing it. The social software power user can easily move between sites; she is also incentivized to discover and master new communities.

With regards to friend networks in the Valley, there’s incredible density in work-friend networks, and likely even family networks. In the Valley, you want to be friends with coworkers, competitors, famous-types; your network is a proxy of your stature. Finding everyone you know on a site is a means to a primarily economic, secondarily social end. Of course, this is hardly a Valley-only phenomenon, but the difference is these assumptions are being written into software for all of us.

This post shouldn’t be taken as an attack on technology or the work anyone is doing; it is good work and it will go forward. Rather, this post should challenge the implementer to look critically upon the assumptions that go into the technology being implemented. Rather than making your average user add a friend list on day one (to increase your userbase), make the addition of users a game in which the user selects the context appropriate friends and learns the norms of the systems. Think about Facebook before and after they introduced privacy to NewsFeeds; such a simple change in assumptions can vastly affect perceptions and experience.

The work showcased at SGF represents the future of mediated social interaction, even if only in the rules, pragmas and assumptions. One thing is clear: This stuff ain’t going away, and it ain’t just for Valley-types anymore. I would argue that research, testing and social thought complement Web 2.0 development models, and perhaps they offer us a way forward as this stuff goes mainstream. These are exciting times.


21
Mar 07

On eating one’s own dog food – OpenID networks in ClaimID

So I’ve been spouting about the power of OpenID-enabled social networks for quite some time now. As have others, especially the inimitable Marc Canter. OpenID + social networks make so much sense – though I’ve not yet seen anyone build a truly open, OpenID-based network. This is when I realized that I need to eat my own dog food.

So Terrell and I got to hacking, and today we’ve pushed OpenID-based contact networks into ClaimID. Our logic for doing this is really pretty simple. ClaimID is about your reputation, and obviously your contact networks are part of your reputation. However, what good are contacts if only a small percentage of your friends use ClaimID? So what we’ve done is made it so that any OpenID can verifiably be a contact. Say your boss isn’t a ClaimID user but does have a Wordpress.com blog – they can quickly and easily be your contact in ClaimID, without ever having to register an account.

Doing contacts like this reflects the reality that we’re not all going to agree on one place to keep our identity. Some people are going to want their blogs, or Facebook page, or LinkedIN to be their identity “place”. As long as these are OpenID’s, they can all be your contacts in ClaimID (and any open network). Its a win-win for everyone – you can have the contact networks you desire, and your contacts don’t need to jump through hoops to be your contact.

As far as I know, ClaimID is the first company to take this approach to networks. Yes, others allow OpenID logins, but this is the first I’ve seen with a truly open contact network. And after doing it, I feel even more strongly that this is the future. There’s no reason to put walled gardens around our networks anymore. Our networks are the web – and social network services should realize that.

If you want to kick the tires, browse over to my ClaimID profile, and add me as a contact (top right) with OpenID. Feedback and other cool ideas welcome.


8
Mar 07

OpenID in the Browser (and the role of third-party IdP)

The more I read these “problem with OpenID” posts, the more I realize the solution is to turn the browser into an IdP. Making the browser the IdP mostly solves the problem of phishing, it completely solves the problem of an offline IdP, and is much more user-centric (I control my data at the very granular host level).

However, thinking through the browser as IdP brings up problems. Maybe you have input. Some problems (and potential solutions).

  1. Non-static IP address. Ok, my computer spends 80% of its time at one IP address, but the other 20% of the time I could be anywhere. This means my OpenID is different from time to time. Solutions:
    1. I log in directly with my browser-based IdP 80% of the time, and dynamically delegate[1] via a third-part 20% of the time.
    2. Usability problem: I would have to register both my main IP-based URL and my delegate URL to the site.
    3. Solution: Perhaps I could auto-register them both at login? Or perhaps I delegate 100% of the time? 100% delegation would still allow user-centricity, but it would not solve the “IdP offline” problem.
  2. Not at my browser all the time. Ok, so if my IdP is in the browser, what happens when I’m away from my browser? For me, I spend 97% of time in one browser I control, but this is not the case for all of us. Solutions:
    1. Third-party delegate IdP becomes primary OpenID for out-of-browser authentication.
    2. I carry around a copy of my Firefox at all times with me.
    3. Of course, solution 1 reintroduces the problem of phishing, and I’d have to store a password at my third party IdP (though that makes sense).
  3. Ugly OpenID. Yeah, it is probably better to be http://claimid.com/fred than http://152.2.210.81/fred, but most sites are going to mask the OpenID anyway by asking you to create a user account. And since the OpenID management is in the browser, it will easily autofill for you so you’d never really need to know your OpenID (though you would need to know your delegate OpenID).

So it strikes me that OpenID in the browser solves some of critical components of the OpenID “problem”, some of the time. Alone, it is optimal, but in reality we have dynamic IP’s and use different computers. It seems like it would fit 80% of use cases, though you’d have to delegate to have fault-tolerant browser-based OpenID. Of course, what about Cardspace – the design assumptions there seem to be that you’re at your trusted computer at all times – so maybe the bar isn’t being held that high.

I guess we can get caught up in the discussion of “Well, if you’re going to delegate, why bother”, which I think is a red herring. The problem here is really data and who controls it. When the data is in the borwser, you really, truly control your data. Your delegate is just a redirect in the either – we might think of it as a public service or something like a DOI.

This is fodder for an interesting discussion, but if you have any input I’d be interested to hear it. What do we lose by making the browser an IdP? Nothing – as far as I can see it is only a win.

[1] Dynamic delegation is the notion of a service that updates its delegation address based on where you are. For example, if you change IP addresses, the dynamic delegation service would simple update to point traffic to your new location.


15
Feb 07

I'm wrong. It's 63 million OpenID's.

In the last post, I stated that AOL enabled 20 million users with OpenID’s. I culled that number from a 2006 article in Information Week about AOL’s subscriber base.

I was wrong. Via Sam Ruby, I see that AOL has enabled anyone with an AOL instant messenger ID with OpenID. So we’re not talking 20 million OpenID’s, we’re talking more than three times that – 63 million AIM accounts at last count (and there are definitely more, as that stat was from May 2006). I left an OpenID comment with my AIM screenname at the ClaimID blog – it worked perfectly.

Wow. 63 million AIM acounts = 63 million OpenID’s. Just like that. Scott Kveton, knock number 4 and (a good part of) number 2 off your list.


15
Feb 07

20 Million New OpenID's

Messina pointed this out a few days ago, and there’s been chatter, but now we have confirmation from AOL about their OpenID strategy going forward. As of this morning, AOL’s ~20 million subscribers all have OpenID. Just like that.

This is how markets and technologies evolve. Adoption of OpenID by a major provider like AOL (or Myspace, or Facebook) will bring OpenID consuming companies to the market. This drives the overall OpenID pool size, making it a significant faction that vendors like Google, Yahoo and Microsoft can’t ignore. Factor in killer apps (coming in 2007), and you’ve got a revolution on your hands.

Microsoft has already gone far with Cardspace integration and public support. Yahoo’s coming along, especially with helpful efforts like Simon Willison’s Idproxy. Google’s head is still buried deeply in the sand, hawking the so-1999 siloed efforts of Google Accounts. Will this sleeping giant wake up and see the value of OpenID?

Update: I’ve got the stats wrong on this – it is actually 63 Million+. See this post for more information.