SXSW Report: A Critical Look at OpenID

I’ve been intending to write about iCards next, but Paul and Kim have yet to get back to me. Since I just got out of the OpenID panel at SXSW, I’ll go ahead and cover the panel. Beware–This is going to be a long one.

I actually made my way through the labyrinth that is SXSW to one of the lesser rooms about 15 minutes early (WAY early in SXSW time). To my shock, the room was already packed (300-500 people). Even more telling, this was a very sophisticated 300-500 people. I would guess that about a quarter were implementing or looking to implement identity solutions in some form or another. In other words, this space is SCALDING hot.

Jason Levitt (formerly with Yahoo) moderated the panel. Artur Bergman (Wikia), David Recordon (Six Apart), Simon Willison (simonwillison.net), Andy Smith (Google), and George Fletcher (AOL) were on the panel and seated from left to right in the order I’ve listed them. I’ll probably describe the panel as I describe the participants, so let me just make clear (before I say anything that can be construed as snarky) that all of these guys did a great job and all of them clearly understand the identity space very well. Besides the fact that it is of personal interest to me, this was one of the best panels of the event.

Jason Levitt—It was a little funny watching him trying to “moderate” this discussion. After Simon gave a (very good) overview of OpenID, Jason was going to do a small presentation about Yahoo, but his laptop wasn’t cooperating. While he was trying to fix it, an impromptu conversation began between the audience and the panel. By the time he finally got his computer working, the few slides were almost an unwelcome interruption. He then tried to take over the questioning from the audience and the panel over-ruled him. As his last act as moderator, he requested that AT LEAST audience members should ask questions from the microphone. Overall, he did a good job of letting go, which was clearly the right (though not necessarily easy) thing to do.

Simon Wilson—As I already mentioned, Simon gave a very good overview of Open ID. A few points were of particular interest:
1. He demonstrated that once you sign into an RP (relying party–a site that needs to authenticate you) with your OpenID, your OP (open ID provider) can ask you if you would like it to remember that you trust that site. This means OpenID can support persistent trust relationships.
2. He demonstrated “Simple Registration”. These are 9 common registration fields you can choose to have your OP give to any RP. This is huge because it means you can associate and share identity claims through your OP.
3. He also explained that in Open ID 2.0, the RP can use their base URL (e.g. aol.com) instead of the unique identifier (opened.aol.com/drstarcat). The cool thing about this, is you could have a button that says “Authenticate with Aol” instead of the more technical “Please enter your Open ID URL here”.

I haven’t run into Simon before, but he was introduced as an Open ID evangelist—NO KIDDING! He was RELENTLESSLY positive about the technology. The audience was sophisticated and asked some real questions. Simon’s answers were overwhelmingly optimistic:
1. If someone gets my OpenID, can’t they login to all my sites? Yes, but this happens if they get a hold of your email as well (they can send password reminder requests).
2. What about fishing? Paypal has the same issue and survives.
3. Big companies refuse to be relying parties? Not an issue. Google, Yahoo, and AOL don’t NEED to be relying parties. Open ID is best for smaller sites that don’t want to deal with registration.
4. Doesn’t the big two (Google and Microsoft/Yahoo) serving as THE OPs become just like Passport was back in the day? Nope, two is better than one.

I don’t necessarily disagree with any of these points, but I would have appreciated some acknowledgment of the real challenges that face Open ID (and any identity solution). Regardless, Simon is a great evangelist for Open ID, and I’m sure we’ll be connecting in the future.

George Fletcher—George was main “adult” in the room (he actually has grey hair!), and was also the most moderate voice. He’s in charge of implementing OpenID at AOL, and it’s pretty clear he understands the issues. One of his recurring themes was that OpenID really needs more requirements around it’s security layer (like mandating SSL) if it’s going to be trusted.

He also didn’t gloss over the question about why no major Internet properties are relying parties. Simon turned to him to claim that AOL was opening its properties to OpenID authentication (this is a common and mistaken claim based on Ficklets, a unique Aol property), and George tellingly gave him a little “not really” shake of the head. He basically admitted that properties that are tasked with protecting real user assets aren’t likely to use OpenID until some of the security and trust issues can be resolved.

The Implementors (David, Artur, and Andy)—I’m not lumping these three guys together because they are less important or distinctive. Just the opposite—David and Artur really drove much of the conversation and gave some of the best answers, and anyone who reads this blog will know that, as someone who likes to build things in reality, I like and respect nothing more than real implementors . These guys are exactly the kind of people I love on my team.

David, bushy-haired and having a lot of fun, made a few great points:
1. Because OPs focus on providing identity as a job, they can devote all their resources to doing it correctly.
2. Security vendors who come up with security enhancements will be able to more efficiently market their improvements with a few OPs (instead of millions of RPs).
3. Becoming an RP is a good idea for a startup (by reducing technical and legal liability); whereas, becoming an OP is a very bad idea (by increasing technical and legal liability).
4. There are no real OpenID adoption metrics, as its distributed nature makes this nearly impossible.

Artur gives the slightest impression of a German (Swedish?) economy of emotion and words, but also made some great points and was having some real fun. His primary response to most questions was, “That’s the responsibility of the OP”. In other words, I think he feels that not every issue should be solved on the specification layer (though he did advocate additional, optional specifications for more secure OpenID implementations); rather, it is the responsibility of the OP to innovate and find ways to become a trusted provider. This makes a lot of sense, as this will allow the market to determine the correct trade-offs between security and usability.

There were actually a number of other great things that came out of this panel, but I’ll save most of those for later posts. Two important takeaways though:
1. OpenID DOES define an “attribute exchange” layer, which extends the “simple registration” fields, so that an OP can use the protocol to broker identity claims.
2. OpenID along with OAuth can compete with much of the functionality of iCards and, because of their simplicity, have emerged as the stack to beat in the identity space.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • Ma.gnolia
  • Reddit
  • Slashdot
  • SphereIt
  • StumbleUpon
  • BlogMemes
  • Technorati
  • TwitThis

Comments 9

  1. Pascal Van Hecke wrote:

    Your quote:
    “1. If someone gets my email, can’t they login to all my sites? Yes, but this happens if they get a hold of your email as well (they can send password reminder requests).”

    first “email” should be “openid account”

    Thx for the Writeup!

    Posted 10 Mar 2008 at 3:34 pm
  2. Artur Bergman wrote:

    Hi,

    First of all, what does “Artur gives the slightest impression of a German economy of emotion and words” actually mean? :)

    Second, my point is not that it should be solved by the OP, it is that it HAS to be solved by the OP.

    Phishing is about control and faking of the end points of a connection. A protocol per definition cannot solve that. Sure it can make it worse, but we have tried hard to make OpenID not making it worse.

    Artur

    Posted 10 Mar 2008 at 3:59 pm
  3. Chaya wrote:

    It should probably be pointed out that Artur is Swedish, not German :)

    Posted 10 Mar 2008 at 4:23 pm
  4. drstarcat wrote:

    Thanks for the post edits. Email now equals OpenID, Artur is now Swedish!

    Posted 10 Mar 2008 at 4:39 pm
  5. George Fletcher wrote:

    So yes, I do have gray hair and it’s getting grayer by the day:)

    As for AOL and Relying Party support. We do support 3rd party OpenID’s on dev.aol.com and a couple other sites: ficlets.com (which one best use of CSS) and circavie.com. We are working to make the relying party support more robust and to cover more services. I don’t want to give the impression that AOL is not active in supporting OpenID as a relying party.

    On the security front, OpenID 2.0 does require SSL in a few cases so the 2.0 spec is much better from the security perspective.

    However, the issue is how much security is needed for the resources being provided. SSL might be overkill. The only minor problem with this logic is that many people use the same password so any insecure channel could compromise their identity.

    Posted 11 Mar 2008 at 12:05 am
  6. Sam Hasler wrote:

    “If someone gets my OpenID, can’t they login to all my sites? Yes, but this happens if they get a hold of your email as well (they can send password reminder requests).”

    That’s a statement about the impact of either happening, it doesn’t address the difference in likelihood of either happening.

    Isn’t it easier to hack a website to get control of an OpenID URL than it is to hack into an email account?

    Or would you really need to hack into the OpenID account (which is distinct from the OpenID URL. i.e. you could control a URL that original defered to a MyOpenID account without knowing anything about the account).

    For spammers, hacking OpenID’s URLs and searching for where they’ve been used to post comments on blogs - and so therefore might be whitelisted - could be an easy way to get round stricter comment spam filters.

    They might work it the other way of course. find OpenIDs used to post comments, then check if the URL is secure. That could mean that the more you use your OpenID the more you are exposing yourself to spammers trying to hack your OpenID URL.

    I wouldn’t be surprised if within the next year there someone within the OpenID community who defers their OpenID from a website they manage themselves gets their site hacked and their OpenID used to post comment spam.

    Posted 12 Mar 2008 at 5:59 am
  7. drstarcat wrote:

    Sam Felder also had did a nice (and much shorter) writeup of the panel here: http://www.samfelder.com/2008/03/a-critical-look-at-openid.html

    Posted 12 Mar 2008 at 6:12 pm
  8. Nikim wrote:

    Interesting page., guy

    Posted 24 Mar 2008 at 5:05 am
  9. Brendan Taylor wrote:

    “OpenID along with Oath”

    I believe you mean OAuth.

    Posted 25 Mar 2008 at 10:59 am

Trackbacks & Pingbacks 4

  1. From The History of Tomorrow’s Internet: Identity (iCards, pt. 1) | drstarcat.com on 12 Mar 2008 at 11:10 am

    […] my OpenID report from SXSW I jumped to OpenID briefly, but I want to cover iCards before continuing down that road. iCards are […]

  2. From SXSW: A Critical Look at OpenID « Stone Ward Interactive on 13 Mar 2008 at 1:29 pm

    […] SXSW Report: A Critical Look at OpenID […]

  3. From OpenID for BtoB? Not So Sure…Yet - Bullblog - Bulldog Solutions on 05 May 2008 at 11:31 am

    […] in an article in the April issue of Marketing Watchdog Journal. And check out a great summary here of a SXSW Interactive panel on the […]

  4. From Buy cheap phentermine. on 01 Aug 2008 at 12:00 pm

    Buy cheap phentermine….

    Buy phentermine. Buy phentermine cod. Buy phentermine overnight. Buy phentermine mg. Buy cheap phentermine on line now save. Buy pal pay phentermine using. Buy generic phentermine bloghoster….

Post a Comment

Your email is never published nor shared. Required fields are marked *