Digital Identity – Page 7

OpenID is for small business

I’ve had this opinion for some time but felt that it was time to memorialize it: OpenID is not only the domain of grassroots developers, but it also (and should be more so) is the domain of small and independent businesses.

What better way to know and serve your customer than to be able to both identity who they are consistently and, where appropriate, hook up complementary services between sites through on uniform authentication experience?

Blinksale announced its support for OpenID today, only two weeks after 37 Signals upgraded Basecamp, their flagship collaboration app, to support the protocol following a successful trial on Highrise, their contact management web app. In the comments, Jason pointed out that the Open Bar feature of Basecamp enabled by OpenID will eventually be present in all their apps, hinting at how OpenID helps you better serve your customers across disparate applications.

I think that this is where OpenID will really shine — where you can have web applications like Basecamp, Highrise, Harvest, Blinksale, Freshbooks, Pownce and others all working seemlessly together even if they’re provided by different vendors, simply because they’re able to treat you as the same person as you move from one to another.

Screw big business adoption; the place where OpenID wins is with the little guys in small business — and with the grassroots folks who are agile, who can move to adopt this technology and who realize that this is the best chance they’ve had to really start treating their customers like real people instead of isolated records in their user database like all the big guys have for so long.

And I’m absolutely thrilled that business likes Blinksale and 37 Signals are starting to see this and turn this into a reality.

OpenID on the iPhone

I helped lead a session on Saturday at iPhoneDevCamp on the topic of OpenID and Oauth (a new protocol a group of us have been developing) to a packed room of developers, designers and interested parties.

My basic premise was that if you’re going to be developing an application for the iPhone that has any kind of account or social functionality that you should dispense with creating yet another identity silo and instead make use of OpenID. Among the reasons I cited:

Safari on the iPhone doesn’t have a password manager like 1Passwd and won’t be able to import all the Firefox passwords you’ve been recording for years. And, as mobile web browsers become more powerful, remembering web service account credentials will become more important (and more of a burden). Better to make it easy on your customers — one OpenID url, one username and password.
if you’ve logged in with OpenID on a web service on your desktop or laptop and have set your provider to always allow you to login in automatically, logging in on the iPhone will require you to only login to your OpenID provider and then enter your URL once for every web service that you want to login to. This means that you avoid the challenge of invisibly typing in your password over and over on the error prone touchscreen keyboard.
The ability to cross-polinate authenticated data using a combination of OpenID and Oauth while remote will be increasingly valuable, especially if the expectation is that applications are going to be entirely web-driven. When you’re dealing with desktop apps, you’re operating off a harddrive with known permissions; when you’re passing between web apps, the permission model is radically different and, just as when you go to check out from Amazon you always have to authenticate, developing patterns for this experience between web apps needs refinement. OpenID can help smooth out that interaction.

Lastly, there is work going on (okay, I’m doing it so far) to make the OpenID login experience on the iPhone (and elsewhere) trump any kind of old school login system available. This obviously needs a lot of work and new thinking (maybe instead of authenticating by typing a password you have to SMS a unique shortcode, etc) but I think your money should be on OpenID if you’re going to be developing account-based web applications on the iPhone — or — generally.

Raising the standard for avatars

Not long ago, Gravatar crawled back out from the shadows and relaunched with a snazzy new service (backed by Amazon S3) that lets you claim multiple email addresses and host multiple gravatars with them for $10 a year.

The beauty of their service is that it makes it possible to centrally control the 80 by 80 pixel face that you put out to the world and to additionally tie a different face to each of your email addresses. And this works tremendously well when it comes to leaving a comment somewhere that a) supports Gravatar and b) requires an email address to leave a comment.

Now, when Gravatar went dark, as you might expect, some enterprising folks came together and attempted to develop a decentralized standard to replace the well-worn service in a quasi-authoritarian spec called Pavatar (for personal avatar).

Aside from the unnecessary invention of a new term, the choice to create an overly complicated spec and the sadly misguided attempt to call this effort a microformat, the goal is a worthy one, and given the recent question on the OpenID General list about the same quandary, I thought I’d share my thoughts on the matter.

For one thing, avatar solutions should focus on visible data, just as microformats do — as opposed to hidden and/or spammable meta tags. To that end, whatever convention is adopted or promoted should reflect existing standards. Frankly, the hcard microformat already provides a mechanism for identifying avatars with its “photo” attribute. In fact, if you look at my demo hcard, you’ll see how easy it would be to grab data from this page. There’s no reason why other social networks couldn’t adopt the same convention and make it easy to set a definitive profile for slurping out your current avatar.

In terms of URI locating, I might recommend a standard convention that appends avatar.jpg to the end of an OpenID as a means of conveniently discovering an avatar, like so. This concept follows the favicon.ico convention of sticking the favicon.ico file in the root directory of a site, and then using this icon in bookmarks. There’s no reason why, when URLs come to represent people, we can’t do the same thing for avatars.

Now, off of this idea is probably my most radical suggestion, and I know that when people shoot me down for it, it’s because I’m right, but just early (as usual).

Instead of a miserly 80 pixels square, I think that default personal avatars should be 512 pixels square (yes, a full 262,144 pixels rather than today’s 6,400).

There are a couple reasons and potential benefits for this:

Leopard’s resolution independence supports icons that are 512px square (a good place to draw convention). These avatars could end up being very useful on the desktop (see Apple’s Front Row).
While 80 pixels might be a useful size in an application, it’s often less than useful when trying to recognize someone in a lineup.
We have the bandwidth. We have the digital cameras and iSights. I’m tired of squinting when the technology is there to fix the problem.
It provides a high fidelity source to scale into different contortions for other uses. Trying blowing up an 80 pixel image to 300 pixels. Yuck!
If such a convention is indeed adopted, as favicon.ico was, we should set the bar much higher (or bigger) from the get-go

So, a couple points to close out.

When I was designing Flock, I wanted to push a larger subscribable personal avatar standard so that we could offer richer, more personable (though hopefully not as male-dominated) interfaces like this one (featuring Technorati’s staff at the time):

In order to make this work across sites, we’d need some basic convention that folks could use in publishing avatars. Even today, avatars vary from one site to the next in both size and shape. This really doesn’t make sense. With the advent of OpenID and URL-based identity mashed up with microformats, it makes even less sense, though I understand that needs do vary.

So, on top of providing the basic convention for locating an avatar on the end of an OpenID (http://tld.com/avatar.jpg), why not use server-side transforms to also provide various avatar sizes, in multiples of 16, like: avatar.jpg (original, 512×512) avatar_256.jpg, avatar_128.jpg, avatar_48.jpg, avatar_32.jpg, avatar_16.jpg. This is similar to the Apple icon .icns format … I see no reason why we can’t move forward with better and richer representations of people.

Onward!

Problems with OpenID on Highrise

Turns out that 37 Signals’ implementation of OpenID could use some… getting real.

Let me go over these issues and provide either resources or remedies.

Normalization of OpenIDs URLs

Look at these three URLs and make a note to yourself about any differences you see:

To a lay person (or even your average geek), these URLs all represent the same thing — especially if you type any of them into the address bar, they’ll land you on my out-of-date homepage.

But, in the land of OpenID and URI evaluation, these differences can be very significant, especially when you get into the differences between OpenID v1.1 and the forthcoming v2.0 (which adds support for inames).

To the contrary of some discussion on the OpenID list, the way in which you normalize an identity URL very quickly becomes a usability issue if the cause of OpenID login failures are not immediately obvious.

Remedy: Given some of the issues folks have had with OpenID at Highrise, DHH decided to make usability the priority:

I’m going to fix the trailing slash issue on URL-based OpenIDs. We’ll be more liberal in what we take.

This should mean that folks logging in with OpenID shouldn’t have to guess at what their appropriate identity URL looks like, instead only substantively know what the important parts are (i.e. the domain and any sub-domain or path(s)).

Outstanding issues: Of course, 37 Signals can do this, but what happens when the identity URL that someone uses on Highrise doesn’t work elsewhere because other consumers aren’t as liberal with what they accept?

Lack of support for i-names

One of the issues (features?) that OpenID v2.0 brings is the support for i-names, a controversial schema for representing people, businesses and groups using non-familiar formatting codes.

I’ve heard that there’s somewhere in the ballpark of 20,000 i-names users in the wild (I happen to have =chris.messina but never use it), but compared with the over 70 million (and growing) URL-based OpenID users, this is an incredibly small minority of the overall OpenID landscape.

Nevertheless, one potential point of frustration for these users is in the lack of standardization in implementing or indicating support for i-names, as Rod Begbie pointed out in the Highrise forum, to which DHH replied, . We don’t support iname OpenIDs for now, though. We’re just supporting OpenID 1.1.

And this, I imagine, is going to be a common issue, for both OpenID implementors (dealing with support requests for support of i-names) and for i-names users, such that I question, as others have, the wisdom of offering support for i-names identifiers, when issues still clearly remain in the usability of basic URLs.

Remedy: Once the OpenID v2.0 spec has been finalized, there will need to be a new logo to indicate which version of OpenID a consuming site supports; this will hopefully work to set expectations for i-names users.

Outstanding issues: At the same time, the addition of i-names to OpenID v2.0 has caused a lot of concern for folks, many of whom have simply decided to stick with v1.1.

Personally, I don’t see the long term value in fragmenting the OpenID protocol away from more familiar URL-based identifiers. I want something simple, straightforward and obvious. Otherwise, v2.0 is going to be a headache to advocate, to implement and to support that a lot of folks with just stick with v1.1.

Double delegation aka the Sean Coon Problem

My buddy Sean Coon pinged me the other day to see if I could help him debug the problems he was having signing into Highrise with his OpenID account. When he had signed up, he had used seancoon.org as his OpenID URL. He’d started playing with it, but then left it, only to return later, unable to login.

His problem was three-fold, but I’ll first address a basic issue with delegation that some folks might not be familiar with.

As it turned out, Sean had delegated seancoon.org to resolve to ClaimID as his identity provider. The problem was that he used http://claimid.com/spcoon as his identity URL instead of http://openid.claimid.com/spcoon, which is where his OpenID was actually stored.

Typically when people use claimid.com/[username] as their OpenID identity URL to login to sites, this transformation takes place invisibly. This is because ClaimID delegates to themselves.

The problem lies in that Sean delegated seancoon.org to his ClaimID profile, which in turn was delegated to ClaimID’s OpenID server. If this sounds confusing, it is, and that’s why it’s not allowed in OpenID.

As I understand it, delegation can only be done once, or else you might end up in an infinite chain of delegations that may end in some grandious infinite loop. By restricting your delegation hops to one, a lot of problems are avoided.

Remedy: In this case, Sean only needs to re-delegate to openid.claimid.com/spcoon, and fortunately, there’s a handy WordPress plugin that can handle this for him.

Outstanding issues: Delegation is probably one of the coolest aspects of OpenID, since it allows you to use any URL of your choosing as your OpenID and then let someone else deal with the harder part of actually talking to all your services. Furthermore, you can delegate any number of services and set up fallbacks in case your primary identity provider is taking a nap. Communicating how this works and how to resolve and communicate errors when things go wrong is one of the biggest holes in the OpenID offering, and with user experience experts like 37 Signals joining up, I hope that these issues get the amount of due diligence and attention that they deserve.

Untested assumptions

Finally, I discovered a serious mistaken assumption in the Highrise sign-up process. To test out this issue, I created a test account, using http://google.com as my OpenID:

Now, here’s the problem: they didn’t force me to login to that OpenID when I signed up; instead they just assumed that I knew what I was doing and that I was using a valid OpenID.

So here’s the email that I got confirming my account. Note my username:

Of course when I go to login, I can’t, and I’m locked out of my account — since I can’t login and prove that I own google.com — which, notably, is the same result as if I’d mistyped my OpenID. Fortunately, 37 Signals gave me a backdoor, but it kind of defeats the whole purpose of using OpenID and suggests that you shouldn’t let folks arbitrary set their OpenIDs without having them prove that they really have control of their stated identifier.

Remedy: For implementors, you must get proof that someone controls or owns an OpenID if you’re going to rely on it as their primary identifier. You can’t assume that they’ve typed it correctly or even that they’ve even used a proper OpenID. And, most importantly, you’ve got to stress test such a new system to make sure issues like this are avoided.

Oh, and it does appear that MyOpenID.com OpenIDs are totally not working at this time; I’ve put Scott Kveton and Jason Fried in touch, so hopefully they can resolve the matter. Interestingly, if you’ve delegated to more than one identity provider and you’re using your own OpenID URL to login to Highrise, you should be able to get in.

Conclusion

It’s still promising to see folks like 37 Signals get on board with OpenID, but we clearly have a long way to go.

I hope I’ve clarified a few of the current issues that people might be seeing, or that are generally confusing about OpenID, and I admit that while I’m trying to clarify these things, a lot of this will still sound like Greek to most folks.

Given that, if you’re having issues getting OpenID, feel free to drop me a note and I’ll see if I can’t help resolve it.

Netscape will add support for OpenID

Alex Rudloff from Emurse just pinged me that Netscape will formally launch their support for OpenID on Monday:

One of the most consistent pieces of feedback that we have received thus far is that we should look into allowing people to log in using their AOL accounts that are currently used for Netscape/AOL mail, were once used for the previous My.Netscape site, and are used throughout the AOL network.

You sent this feedback, and we have been listening. In conjunction with AOL announcing its role as an OpenID provider, and spurred by the rapid pace by which OpenID is being adopted on the Web, on Monday, March 26th, Netscape will not only support signing in with your current AOL screen name, but also OpenID as a way of accessing Netscape.com and My.Netscape.

This comes as no surprise given that Netscape’s parent company, AOL, is an OpenID identity provider and is building out places where you can use your AIM screenname to login.

Reporting on OpenID implementations lately has become akin to reporting that companies have discovered and are now starting to use HTML… there’s still a long way to go, but clearly this is the future foundation of identity-based services.

Highrise follows trend with OpenID signups at 9%

In announcing a number of welcome changes to their pricing plans on Highrise, their new CRM tool, 37 Signals also provides some welcome figures on the uptake of OpenID:

Another interesting stat is that 9% of the people signed up are using OpenID. Lots of early adopters on board!

This is more or less consistent with Ma.gnolia’s rate of uptake:

So far, over 15% of new Ma.gnolia members are seeing the advantage and getting their OpenID when they join Ma.gnolia. Considering how new OpenID is, and that it takes a bit of un-learning of old sign-in habits, we’re really delighted to see this adoption rate.

Jason Fried has also suggested that OpenID will be making its way to their other products soon:

We’re still learning about OpenID and OpenID implementations with Highrise. There are still some bugs to work out. Once we feel we’ve really nailed that we’ll look into spreading it across the rest of the product line.

As we see more mainstream coverage, like the USA Today article suggesting that OpenID “cuts down on Web registrations”, it’s likely that we’ll easily surpass 100 million OpenIDs by the end of the year as more and more small businesses reap the benefits of the advance of this technology in how it reduces the greatest barrier to attracting and retaining new customers: signing up for yet another account!

All in all, good news for OpenID and for 37 Signals customers.

ClaimID adds social networking

In spite of previous disavowals of having social networking aspirations, identity link aggregator ClaimID has now added the ability to add other ClaimID members to your profile as contacts.

Interestingly, they restrict you to adding friends who have OpenIDs (since every ClaimID profile URL is an OpenID) and use the XFN microformat to define your relationship.

This is a significant decision because, presumably, every OpenID has an owner. As such, adding one of these “verified” OpenID URLs as a contact to your verified OpenID URL could represent a higher trust level — a stronger “claim” as the lingo goes — than simply using the XFN rel-me attribute to create a “weak” relationship claim. Or so goes the theory.

Meanwhile, I’ve recently been reordering my Flickr screenshot collections and have created a set devoted to adding friends interfaces. If you have examples of similar interfaces, leave me a link to the source and I’ll get them added!

37 Signals’ new app Highrise launches

With narry a word on the 37 Signals’ blog SvN, the veil has been lifted on their long awaited CRM tool called Highrise.

There are a number of posts that capture some of the many features of Highrise on the SvN blog and are worth a look:

In the meantime, I’ve collected a bunch of screenshots (nice catch Allen) — in addition to their great tour — that will give you a sense of what the app is all about.

I’m totally excited about their adoption of OpenID, but I have to admit, their implementation — especially in the forum — is a little odd. I love the auto-adapting interface for inputing your OpenID, but the fact that I can’t sign in to the forum with the OpenID that I created my Highrise account with kind of misses the point.

And still no sign of microformats either, but a guy can hope right?

Anyway, it is exciting to take a look at all the interface greatness in this app — definitely some fine work. Whether I’ll become a paying customer is up in the air, especially as open source solutions like CiviCRM exist (though without the interface trappings that make 37 Signals products so attractive). I do like what I see so far, though — and if I can find a way to fit it into my workflow, I’ll likely end up a pretty satisfied user.

i use this adds support for OpenID

I’ve give credit to Tara for provoking this one.

i use this, one of my favorite Mac OS X software sites, has enabled OpenID consumption using miyagawa’s OpenID plugin for Catalyst.

Note: I hadn’t realized, but despite its Rails-like trappings, i use this is actually a Perl app powered by Catalyst. One issue that was revealed in using the Catalyst library concerned Yadis discovery of delegated OpenIDs. Until I hear from Marcus, you’ll either need to use your direct OpenID URLs or the traditional meta-tag method of delegation until support for Yadis is baked into the library.

IconBuffet and Shopify add support for OpenID

Two more announcements for OpenID adoption — but this time on the consuming side (as opposed to my originally incorrect report about WordPress.com — for now, they’re only serving as an identity provider).

The first is Shopify, a great Rails-based custom store application. As Alex points out, these guys really get it right — and make it super easy to create compelling marketplaces. And now, it’s super easy to log in with OpenID.

Meanwhile, IconBuffet has gone through a major overhaul, becoming something of a social network for … icon enthusiasts! (Sweet!) One of the more existing aspects of the relaunch (at least for me) is their use of OpenID: you can either create a new account with an existing OpenID (say, your WordPress.com blog URL) or you associate your existing account with an OpenID. Either way, they too’ve made it really easy to get going with OpenID.

I imagine that these won’t be the last of the increasing deployments of OpenID in the medium- to long-tail (read: not Google or IBM, but small business community). What’s so existing about these recent additions is their proximity to commerce — and how folks like Shopify could eventually weave a web service that allows you to check out — entirely by way of logging in to your OpenID provider. If you choose a good OpenID provider, you can start to see how the CardSpace metaphor makes sense — just like when you go out to eat and depending on whether it’s a business meal or a personal expense, you’ll use a different credit card to pay.

The same thing is true for OpenID — where you can have as many OpenIDs as you like and you can pick among them for different uses or purposes. It’s only a matter of time before I go to check out at IconBuffet, I login with my WordPress.com OpenID and I’m able to use credits that I’ve purchased on WordPress.com to pay for my icons — with no need to reach for the credit card, to fill in my address info or any of that ever again!

Now, if that doesn’t sound exciting, you might want to check your pulse. 😉