Feed Sign in with OpenID OpenID

Simon Willison’s Weblog

The point of “Open” in OpenID

TechCrunch report that Microsoft are accepting OpenID for their new HealthVault site, but with a catch: you can only use OpenIDs from two providers: Trustbearer (who offer two-factor authentication using a hardware token) and Verisign. "Whatever happened to the Open in OpenID?", asks TechCrunch’s Jason Kincaid.

Microsoft’s decision is a beautiful example of the Open in action, and I fully support it.

You have to remember that behind the excitement and marketing OpenID is a protocol, just like SMTP or HTTP. All OpenID actually provides is a mechanism for asserting ownership over a URL and then “proving” that assertion. We can build a pyramid of interesting things on top of this, but that assertion is really all OpenID gives us (well, that and a globally unique identifier). In internet theory terms, it’s a dumb network: the protocol just concentrates on passing assertions around; it’s up to the endpoints to set policies and invent interesting applications.

Open means that providers and consumers are free to use the protocol in whatever way they wish. If they want to only accept OpenID from a trusted subset of providers, they can go ahead. If they only want to pass OpenID details around behind the corporate firewall (great for gluing together an SSO network from open-source components) they can knock themselves out. Just like SMTP or HTTP, the protocol does not imply any rules about where or how it should be used.

HealthVault have clearly made this decision due to security concerns—not over the OpenID protocol itself, but the providers that their users might choose to trust. By accepting OpenID on your site you are outsourcing the security of your users to an unknown third party, and you can’t guarantee that your users picked a good home for their OpenID. If you’re a bank or a healthcare provider that’s not a risk you want to take; whitelisting providers that you have audited for security means you don’t have to rule out OpenID entirely.

I have a very simple rule of thumb for whether or not a site should consider whitelisting OpenID providers: does the site offer a “forgotten password” feature that e-mails the user a login token? If it does, then the owners have already made the decision to outsource the security of their users to whoever they picked as an e-mail provider. If they don’t (banks are a good example here) they should continue that policy decision and consider using an OpenID provider whitelist.

I’ve been using the example of banks potentially accepting OpenID only from security audited providers in my talks on OpenID for at least the past year. Now I can finally provide a real-world example.

This is The point of “Open” in OpenID by Simon Willison, posted on 24th June 2008.

Tagged , , , , , , , ,

View blog reactions

Next: Back to full-time employment

Previous: Debugging Django

23 comments

  1. To my point of view, this is a major drawback for people using openID.

    Let's go a bit further in your example. Company1 only wants A&B as provider, Company2 wants C&D...

    So I'd end up multiplying openIDs for different accounts.
    People (at least me, I'm so naive) not only wanted OpenId to make the web more secure, they also wanted OpenID to make it more simple.

    LeRenard - 24th June 2008 09:09 - #

  2. Well said. It's a shame correcting TC misinformation is such a full-time occupation.

    OpenID seems like personal certificates done right—let everybody have one, and then create a more advanced layer of trust for applications that need it.

    Issuers of personal certificates got this wrong by going straight for the money.

    Edd Dumbill - 24th June 2008 09:48 - #

  3. LeRenard: having two or three OpenIDs is still better than having dozens and dozens of username/password combinations. I'm willing to wait and see how this works out - I imagine there will be a small number of high quality, trustworthy OpenID providers that end up being trusted by virtually everyone so it should be easy to select a "secure" OpenID you can use as your principle SSO mechanism that works pretty much everywhere. OpenID will still have plenty of value for its other purposes - it's not just about SSO, it's also about being able to "prove" to site A that you own a specific account on site B. An OpenID from site A would let you do that even if you had no intention of using that OpenID for SSO.

    Simon Willison - 24th June 2008 10:02 - #

  4. I'd think if they were going to whitelist anyone, it would be JanRain's myopenid.net as one of the first ones. I mean, wouldn't they at least trust the security of the company who develops the most well known software/service for it?

    Devon - 24th June 2008 10:14 - #

  5. OK, I'm not saying Open ID is not better than user/password systems but one of the benefits is SSO and I see it as The main factor for the average user that can make OpenID adoption fast and an identification standard.
    At first, Wifi wasn't secure (it's maybe still not) but its convenience made its popularity.

    And about the "trustworthy OpenID providers", Microsoft chose two of them. If for any reason, I don't trust them
    (for example, Trustbearer and Verisign are US companies. Let's say I don't trust them because of the patriot act.) What can I do?

    LeRenard - 24th June 2008 10:29 - #

  6. Refuse to use HealthVault until they start accepting OpenIDs from a provider you trust, and let Microsoft know about your decision. In the end this stuff is going to have to be driven by user demand.

    Simon Willison - 24th June 2008 11:06 - #

  7. How nice that Microsoft is trying to decide what's good for me. Not that I'm the only one responsible for myself eh...

    That's one of the reasons I switched from Microsoft products, they don't know what's good for me & I won't let them enforce "things that are good for me".

    jinzo - 24th June 2008 11:10 - #

  8. Hmm. Is any provider issuing OpenIDs based on a public-key web-of-trust model?

    Michael R. Bernstein - 24th June 2008 22:35 - #

  9. I can't agree with this. The great thing about OpenID's openness is that the consumer has the choice. We don't want "embrace and extend" stuff.

    OpenID is great, but when everyone requires another provider, the problem OpenID solves (i.e. having to register at every site you visit) isn't solved anymore.

    I love OpenID. It enables great things, such as distribution instead of centralization. Imagine you don't need to be a facebook user to see pictures from last week's party: instead of people tagging your facebook username, they tag your openid (and your OpenID provider will send you an email about this - or you can view these messages on your OpenID page, whichever you want (and you can be sure this is possible, as it's part of the OpenID protocol standard. Of course you made sure your OpenID provider was certified to be compliant with OpenID v4 before you chose it - so no worries about that). And those pictures - you can access them after you've identified with your OpenID to facebook. You can see only the pictures you're tagged in, of course - no reason you could see the others. That is, unless your facebook-using friend has added your OpenID to his friends list, and has set up facebook so that pictures are viewable by friends). Everything gets done with openID. Instead of having an email address as a central contact point, you have an OpenID.

    OpenID could really do great things, if people used it more and were educated about it. Right now, I still need to sign up at tons of social websites, while most (all?) things could be done in a distributed way, if well-thought out (and if OpenID was extended a bit, I guess - though I don't know enough about OpenID 2 to make a decent guess about that).

    LudoA - 24th June 2008 23:27 - #

  10. you can't guarantee that your users picked a good home for their OpenID

    That's not your business you paternalistic dregs of society. Just do your job and stop trying to do mine.

    vsync - 24th June 2008 23:40 - #

  11. Only accepting OpenID's from trusted partners is a bit only accepting email from a whitelist, or HTTP requests from known IP addresses, o It's a valid usecase, but does significantly reduce the network effect of a distributed identity system, and for what value? A small sprinkling of PKI pixie dust. It's not like these providers vouch you are you or provide compensation for when things going wrong in the way you'd expect a regulated credit-card, bank or telco to.

    Paul Downey - 25th June 2008 18:06 - #

  12. I am not against openid white-lists, eg, for authenticate admins of a website that have access to all user data.

    But I don't see the point in that case; if their users pick bad providers, they only compromise their own data.

    They should instead recommend some providers or warm if they can't assure a user provider is not secure enough.

    Dinoboff - 25th June 2008 18:15 - #

  13. I will be waiting for http://myVidoop.com to be added to the white list, it is as secure as Verisign or Trustbearer and you dont need any tokens.

    myOpenID with their phone call jobby would be worthwhile to add as well.

    Kevin Fox - 25th June 2008 18:35 - #

  14. I get where you are coming from. But with this system I will need multiple OpenID's just like the multiple accounts I now have.

    Can't tell you how much that prospect pisses me off. If there was just one service that we would be confined to then let have clickpass at least. The idea of having multiple openID's will drive me away from it.

    Don Crowley - 25th June 2008 20:15 - #

  15. Do decisions about what ID provider need to be made at the relying party level?

    What if user Alice wants to sign in using the Alpha service, and Bob wants to sign in with Beta?

    Can't the system store that, and allow Alice to choose her own "identity prover"?

    Not speaking for my employer - 26th June 2008 16:42 - #

  16. I dislike this decision too, but I understand that when dumb user's privacy is compromised on Microsoft's site - it's all Microsoft's fault for 99% of people out there, only 1% knows that bad openid caused that.

    arty - 27th June 2008 09:38 - #

  17. Whilst having multiple ID's is annoying, assuming you choose a good provider you shouldn't need more than one - good providers shouldn't have a problem being whitelisted.

    What would be useful is a set of critera by which you can evaluate those providers. If you're selecting a provider surely one thing you'll look at is the overall security of the service, whether they are likely to be here in 5 years time etc.

    Tom - 27th June 2008 12:31 - #

  18. I think these kinds of decisions will call OpenID providers to join up and provide multi-OpenId (or not!). For example if I have an account with openid.net, i would be able to create an account on myopenid.net and join the two.

    However, Microsoft decision points in an interesting direction - competition in identity management is not only about being first in the market or having a good marketing campaign. It's also about features. It's like being able to choose a country of citizenship based on protective features of it's passport.

    If M requires provider B, and I have signed up with provider A, it is wise for B to try to team up with A. And if B charges money for membership, but A doesn't I should be able to decide whether I want to pay to 'enhance' my service on A with B's add-ons. This way A becomes a reseller of B's services and everyone is happy: I get access to the information AND keep A as a sole identity store. A doesn't loose me and gets commission fees from B. M and B get another customer.

    This explains why demand.openid.net lists some openid providers as lacking openid login - people want multiple profiles with single login.

    Andrei Railean - 30th June 2008 06:22 - #

  19. There are valid reasons for an RP to whitelist OpenID providers. For example a site focused on school age kids could insist on an OpenID from an accredited school district. When Sun issued OpenIDs to their employees, they said that this will simplify third parties that give "employee discount".

    Aswath Rao - 30th June 2008 17:13 - #

  20. Internet *is* decentralized and that's a luck. You are quite inconsistent :
    " accepting OpenID on your site you are outsourcing the security of your users to an unknown third party, and you can’t guarantee that your users picked a good home for their OpenID. "

    But, the provider that a web user can realy trust is... himself ! Also, it's better for privacy to host such private data by himself when possible. With a whitelist system, it's made imposible to use a self-hosted openid...

    So I think such a system is definitively domageable for privacy and security ...

    JocelynDelalande - 19th July 2008 16:32 - #

  21. Hello,
    I just wanted to say thanks because I managed to turn my domain into an Open ID thanks to your post here! :)

    Reb - 20th August 2008 05:09 - #

  22. Here is a question to ponder: suppose you use the same OpenID username / URL for all your Web sites, and you are already logged onto one of them.

    Given OpenID provides a single sign-on capability, can a malicious Web site discover other OpenID-enabled Web sites you have visited before (e.g., by examining cookies), transparently connect to them and steal your data or money? If so, would this mean that you would want to use a separate ID for trusted / sensitive Web sites like your bank? [Establishing, in a sense, different domains of trust.]

    Obviously this scenario is not specific to OpenID but could be made worse by OpenID's main premise.

    Igor Mironov - 1st September 2008 14:58 - #

  23. That's one of the reasons I switched from Microsoft products, they don't know what's good for me & I won't let them enforce "things that are good for me"

    Diora Baird - 10th September 2008 19:00 - #

Sign in with OpenID

Auto-HTML: Line breaks are preserved; URLs will be converted in to links.

Manual XHTML: Enter your own, valid XHTML. Allowed tags are a, p, blockquote, ul, ol, li, dl, dt, dd, em, strong, dfn, code, q, samp, kbd, var, cite, abbr, acronym, sub, sup, br, pre

A django site