Steven Osborn » OpenID

Identi.ca out of the gates

steve918 — Thu, 03 Jul 2008 02:02:23 +0000

Just a few ours after launch and my email box is chalked full of subscriber notices for the latest buzz on the interwebs. As of this posting they were still under 3,000 users, but growing quickly. The small number of users actually makes the public time-line fun.

The Good:

OpenID Support
Open Source
Beginnings of an Open/Distributed Platform

The Bad:

No Delete
No SMS support
No User search
No mobile version

The Ugly:
It’s written to run on top of a single MySQL instance without sharding/partitioning support which will have a hard time competing with twitter in the scalability department. The name is a bit awful, twitter is a much cuter name. Besides, what are we going to call an update? A Ident? Not quite as cute as a ‘Tweet’.

I’m not really certain if this has the makings of a twitter-killer that can finally put an end to the fail-whale, but I’m really excited about the openness aspect, openid support and idea of a distributed micro-blogging platform. I would most enjoy identi.ca eventually being a WordPress plug-in and micro-blogging becoming an extension of my typical blogging and XMPP.

Why I'm against OpenID Whitelisting

steve918 — Wed, 25 Jun 2008 05:07:53 +0000

So let’s talk about what OpenID whitelisting really is. It’s essentially a way of saying we don’t trust our users to store their identity securely and we’re not ready to deal with what happens when they loose it. Which really isn’t anything new. Right?

Today we trust users with their passwords, but only because we haven’t figured out how to tattoo it on their forehead in a way that prevents sharing. We also trust users to choose a reliable email provider so that when they forget the password to our site we have a way to help them retrieve it. Again we don’t really like giving the user such great responsibility, we just haven’t come up with a way to trust them less.

We trust users as long as they play within the padded walls we enclose them in. Whitelisting is essentially adding padded rooms to the places we let our users into, when all they really need is a helmet and some knee pads.

If it’s truly a matter of not trusting all of the identity providers out there, then maybe we should be focusing on ways to assert and secure that trust instead of choosing sides and picking partners. Maybe it means certification or accreditation; certainly not my favorite solution, but at least it establishes a level playing field and gives the user some real options that actually reduce their current username/password problems. This way we trust our users to choose as long as we have control and/or reassurance that the choices they have to pick from are good ones. But none of this is necessary provided we actually trust users to manage their own identity in the first place.

If we really want to build a user-centric single-sign-on solution then we have to start taking off the training wheels and give users some control of their identity. I understand it a scary world out there, but lets focus on ways to protect them instead of sheltering them.

SourceForge Ships OpenID!!

steve918 — Wed, 30 Apr 2008 21:03:10 +0000

SourceForge.net shipped support for OpenID this morning followed by an official announcement on their community forums. In just a few seconds I had my OpenID tied to my existing SF account. Their implementation seems very solid and straight forward.

This certainly makes them one of the largest, most prominent OpenID Relying parties to date.
I sure hope this leads to all of OSTG websites ( Slashdot, Thinkgeek, Freshmeat, etc…) following suit.

Their front page now advertises: 1,840,049 Users + 250,000,000 OpenIDs

Their OpenID management screen is really hot; It allows you to add additional OpenIDs to your account, decide which one you want to make public (if any) and choose one to delegate your SourceForge.net endpoint to. So developers can use http://sourceforge.net/users/username as their OpenID endpoint.

Digg It!

SourceForge OpenID RP in the works.

steve918 — Mon, 14 Apr 2008 19:50:23 +0000

Luke Crouch, one of SourceForge’s developers left a subtle message today in their community forums hinting at what OpenID features they’ve been working on recently.

It looks like they will be shipping a full on RP implementation along with delegation support for their developer profile pages.

“dedicated Identity Providers can focus on delivering comprehensive digital online identity services for web users, while we need to focus on those users’ needs as OSS community participants.” — Luke Crouch

I’m really excited to see SF leading the pack in the OpenID world. Their RP offerings will certainly be a valuable contribution to the community.

Improving OpenID Delegation

steve918 — Fri, 28 Mar 2008 03:32:50 +0000

When I authenticate using my delegated OpenID I’m actually proving I own two different URIs. I own http://steven.bitsetters.com which I’m delegating from and I own (or at least have some control over) http://steven.myvidoop.com. So a RP can easily associate both endpoints with my account. The problem comes when I decide to change the endpoint I’m delegating from. Let’s say I get tired of WordPress (I know it’s a stretch) and decide to use Blogger instead. Now I want to delegate using http://steve918.blogger.com. Currently this would require me to login to every site I previously signed into as steven.bitsetters.com and add steve918.blogger.com as an associated URL. (Assuming the RP even supports associating more than one OpenID per account. ) The thing is, this process of explicitly adding my new delegated OpenID leads to an extremely high cost of switching that is not necessary.

As I mentioned in my previous post, delegation is an important part of the OpenID ecosystem, but it needs to be manageable for muggles. If reliers could make this association for me, I’m free to bounce from one social networking site to the next and use what ever delegated ID I feel contains my social graph and most useful profile information at that time. Having this free switching economy also makes it much more appealing for all the sites I mentioned previously to provide delegation services.

The only scenario this seems to affect is someone who is using a single endpoint, but delegating through it with multiple identities. Basically people masquerading different profiles through the same IdP account. In this case I think it’s up to the RP to allow the user to decide which OpenID they wish to make public (if any) on that site.

The real problem in this scheme is that all the extra work falls on the RPs and realistically I don’t think many of them will go above and beyond hacking in the bits that are provided to them via easily available OpenID libraries. So as a community maybe we can extend the libraries to include support for easily storing and managing endpoints. I’m honestly not even sure how realistic this is, but I think doing so could make it easier for RPs to check all the boxes on the best practices checklist.

OpenID Delegation: Ship It.

steve918 — Mon, 24 Mar 2008 19:11:50 +0000

It seems when everyone’s talking about the lack of OpenID relying parties compared to identity providers they often leave out an important role in the OpenID stack: Delegation. Of course this doesn’t solve the problem everyone is feverishly complaining about, but it is curious to see no one ever really mentions delegation.

Any website who aggregates significant amounts of user data that is a content rich endpoint for the user is a perfect candidate for providing delegation services. I just want to make it known that just shipping simple delegation is a great option and an important one. If you ask people to give you a URL that most describes them on the internet they’ll probably point you to their page on one of the following:

Ideal delegation sources:

Facebook
MySpace
FriendFeed
Twitter
MySpace
Digg
Delicious
SourceForge
Magnolia
Jyte
LinkedIn

For these sites choosing to ship delegation instead of their very own identity provider has a lot of important benefits for the site and it’s users. As a content provider shipping delegation is unbelievably simple from an implementation standpoint. It’s a one time cost of a couple of developer hours and that’s it. Now your users can login to their favorite OpenID sites as joe.yoursite.com and you don’t have to employ a team of developers to maintain your OpenID implementation and user management. Users also benefit because their OpenID endpoint is now a content rich place that actually describes them.

OpenID Personas = Cruft

steve918 — Thu, 20 Mar 2008 17:30:39 +0000

I use personas in the same way I think most people are using them in OpenID today. I don’t think of them as identity containers, but as address bundles. I have one very creatively labeled “Work” and another labeled “Home”. Hmm…. That sounds exactly like how I manage my identity in my address book except now the UI is more complex and spread out all over the place.

It seems to me that a good deal of OpenID providers today have translated multiple user accounts and/or online identities into OpenID “personas”. Which is essentially an attempt at replicating our mental picture of the semantic web. For users the web consists of many user-names for many websites; the correlation is typically one to one. The OpenID model draws a different picture where your authentication is now a one to many relationship which is why these methodologies don’t mesh well.

The point is with very few exceptions (mental case) we are all individuals with one personality or persona who happen to have multiple sets of data that describe us. The concept of personas only serves to confuse users in a failing attempt to replicate previous models.

This is how I want to manage my identity online: Easy and familiar.