One very sad story

This article by ZDnet's Mitch Ratcliffe on Identity Rape and Mob Mentality sends shivers down the spine.  Partly because a bunch of our friends are involved.  Partly because the dynamics are just scarey.

Allen Herrell, one of the accused attackers in the Kathy Sierra controversy, has written a long email to Doc Searls explaining that his entire online identity has been compromised. If true, and I believe it, because I have known Allen for many years, it appears there have been many more victims here than Ms. Sierra.

I am writing this from a new computer, using an email address that will be deleted at the end of this.

I am no longer me. My main machine despite my best efforts has been hacked, my accounts compromised including my email. and has been disconnected from the internet.

How did this happen? When did this happen? shit doc, i don't have a fucking clue. I thought i was pretty sharp. I guess not.

just about every online account that i have has been compromised. Most importantly my digital identity and user/password for typepad and wordpress. I have been doing damage control, for my clients. How the fuck i got to be part of this mess is revolting.

The Kathy Sierra mess is horrific. I am not who ever used my identity and my picture!!

I am sick beyond words over this whole episode. Kathy Sierra may not be on my top 10 list , but nobody deserves this filthy character assaination (sic). 

A lynch mob mentality has come over the Blogosphere. Kathy Sierra has ever right to be angry about the messages directed at her, but her allegations appear to have been misdirected and misinformed, because they relied on simplistic analysis of the sites and assumed that appearance and reality were identical. And she's making it worse, writing today:

You're damn right I'm *linking* these folks to these posts. You're wrong about their involvement. The posts and comments were NOT made by–as you said–heinous trolls.

Whoever made the posts was a registered member, and they *know* who made the comments — he was one of their participants. I never said Jeaneane was the one creating the noose picture or comment. I said she was a participant in and “celebrated” and encouraged meankids.org. I believe that when prominent people encourage this kind of behavior, they don't get to wash their hands of it, ethically.

I should be more clear, though, that while *someone* broke the law with the noose photo/comment, I'm definitely NOT suggesting that anyone else did anything legally wrong.

But I think Hugh put it better than I can:

–You might not be the guy raping the cheerleader, but if you're the one standing by saying, “go go go!” you share some responsibility.–

Not legal, but ethical. I don't believe any of these folks should be able to create these forums, *celebrate* them, send people there, and actively participate… and then claim complete innocence. If you hand someone a loaded gun. and encourage them to shoot…

The rape metaphor applies to everyone involved who had words and images they find deplorable attributed to them. But it is far more important to understand that the rape claimed attributed to them probably didn't happen wasn't their doing in the first place. The gun shoved in Chris Locke, Jeneane Sessums, Frank Paynter and Allen Herrell's hands is as likely to be illusory as not. We need proof, not accusations, just like in the physical world.

Trolls created the impression of a crime and sat back to watch human nature show its worst side. They are still enjoying it.

As Chris Locke explained in his email to me yesterday, he took the offensive postings down “shortly after it appeared.” Nevertheless, Bert Bates, Kathy Sierra's Head First Java co-author has commented on this blog, saying “By definition, these ‘posts’ were made by the author(s) of the site – it IS a small circle of candidates.” When you factor in the possibility that accounts were co-opted, according to this definition, anyone who has ever had their email address spoofed is responsible for the content of the messages sent under their name.  (Post continues here…)

There are so many things to be learned from this story that it boggles my mind. 

It brings back a conversation I had with Allen (The Head Lemur) at Ester Dyson's Release 1.0 conference, years ago, where we first talked about identity.  He was skeptical (as is his wont) but I had good fun talking to him.  And there is no doubt in my mind that we should, as our civilization has learned to do, consider Allan innocent until proven guilty – and there doesn't seem to be any sign of that. 

The worst is that I hear stories like this all the time.  Not just in my work, but from my family. 

My daughter tells of a lady friend who's gmail account was broken into – resulting in pandemonium that – if it weren't so unbearable – would be the stuff french farces are made of. 

My son's instant messaging account was hacked by the ex of a ladyfriend he wasn't even dating.  Again, he was dragged through weeks of confusion and reconnection. 

So one of the things that separates this story from all the others happening all over cyberspace is just that we know the people involved.  The broad strokes are common today given the randomness of web security and identity.

To make matters worse, imagine technical people saying, in a world of passwords and keystroke loggers, “these ‘posts’ were made by the author(s) of the site – it IS a small circle of candidates…”  Help me.

It's a great proof point that even though blogs don't involve high finance, they still need high quality security.  The loss of privacy and loss of dignity we have witnessed here can't really be undone, even if one day they can be forgotten.  Protecting identity and protecting access is not a joke.

Some days, when I'm really tired, I look at the vast job ahead of us in fixing the internet's identity infrastructure, and wonder if I shouldn't just go and do something easy – like levitation.  But a story like this drives home the fact that we have to succeed. 

Maybe next time Allan and colleagues will be using Information Cards, not passwords, not shared secrets.  This won't extinguish either flaming or trolling, but it can sure make breaking in to someone's site unbelievably harder – assuming we get to the point where our blogging software is safe too.

Name that scam

Received this email from a reader.  Has anyone any idea what was going on? 

Yesterday afternoon, at approx 2:10pm, I started receiving emails (and phone calls) from a variety of websites, mostly financial (home loans, car loans, debt consolidation) but also other services (BMC music, TheScooterStore, Netflix).. claiming to be responding to requests from me (at their websites) for services or information. 

I’ve received about a dozen emails over the past 24hrs, and about the same number of phone calls at home and about half a dozen at work. 
So somebody is entering my name and personal information (home & work phone, work email, home address & home value – all relatively public info – so far nothing worse like SSN or other credit info) into a variety of websites and signing me up for various services. 

Some of these websites (I have spoken with several sales people on the phone) are part of marketing networks that either share or sell such information (leads) and I have tracked several of these down to a common source.. although it appears that are at least several root sources involved. 

My question is this: what is the scam? 

Its possible its just personal harassment and there is someone out there that is trying to give me a bad time or is playing a not-so-funny joke. 

It doesn’t feel like identity theft – they don’t seem to have private info, but instead seem to have assembled some relatively public info and are inputting that into a bunch of websites. 

Could this be someone trying to defraud a marketing network? If so, do you know how that works? 

Ever heard of anything like this before? (maybe this is a common thing?) 

Btw, at least some of the companies contacting me are legit (QuickenLoans for example, and they were quite helpful on the phone) so it seems the “fraud” is on the input side?

I asked the person who was the target of this attack how he knew for sure he had been speaking with people from QuickenLoans, for example.  It seems they just seemed credible, and helpful, so he never questioned their claims or asked to call them back.

It all reminds me of this.

The umpire delegates back

Pete Rowley of RedHat has to win the Witty Title Award for “The umpire delegates back“:  

Recently Kim Cameron has been defending CardSpace against various assertions that it won’t work offline. As I pointed out some while back, that is pure nonesense. I’ll let you read Kims blog for the details of how such a system might work with CardSpace, but I’ll just say it has to do with delegation. And that’s just a big word for access control, in this case user centric decentralized access control.

There really is no big secret to how this stuff is possible – at some point in time an offline user will be online, and during that time instead of ceding their credentials to the service in the sky (or worse, it happens without choice), they spend the time granting access specific to the service that needs access. That’ll be a statement along the lines of “Pete’s blog is allowed to view this flickr photoset.”, not “here’s my password dude, do as you will”, or indeed “hey, IdP, see that service? That’s me that is.” I have to agree with Kim on the notion of impersonation – at no time should anybody give the required access level for impersonation of themselves, on or offline.

There be dragons.

Pete has a fascinating blog and it's really worth following his People In The Policy series.  This is good stuff.

Services should use their own credentials, not mine

Dave Kearns, who is usually not without wisdom, takes on my “bold and forceful” assertion: 

Aided by Jim Kobielus, Kim Cameron and Eve Maler are having a snit. Well, Eve's taking potshots at CardSpace and Kim's defending his baby….

As part of the exchange, Cameron states categorically: “No one and no service should ever act in a peron’s [sic] identity or employ their credentials when they’re not present. Ever.” Bold and forceful, certainly. But also as wrong as wrong can be.

We all (even Kim) often ask services to do things on our behalf – and don't sit around watching to be sure they do it! The most obvious example is my email inbox – it patiently logs in (as me) to multiple servers periodically 24 hours a day, seven days a week, 52 weeks a year. From time to time I visit the inbox to see what's there, but no way can I be said to be “present” at all times it's acting for me.

Dave is missing the point – maybe I wasn't clear enough. 

I'm not saying you have to “stand around and watch” while your mail client picks up your mail.  I'm saying your mail client should identify itself as a particular instance of a mail client, and present an authorization from you allowing it to pick up your mail. 

They're all ME 

If you share identity (even, in some cases, secrets and credentials) the way Dave is proposing,  we don't know what process is accessing what resource because all the the services I run are ME. 

That's really the computing model we have had until now.  Where has it led?  Well, for example, my email client is ME, and a trojan on my desktop is ME,  and the resources they access can't tell the difference, because they're all ME.

So any trojan that gets into my environment can get my email addresses and send worms to my friends, or pick up my mail and feed it to spam machines.  My mail server and other resources don't know the diffference.

Things don't have to be this way

We can instead build systems where my mail client will identify itself as my email client (e.g. be iteself), and present an authorization token from me saying it can pick up my mail.  

On such a system, my trojan will have to identify itself as “trojan”, and will thus have no authorization coupon to present at all!  It is harder to build systems that behave this way, but given what we now understand, it is doable.  Wouldn't we want actual auditability and proper factoring?

That's why I say:

No one and no service should ever act in a peron’s identity or employ their credentials when they’re not present. Ever.”

The approach Dave describes was fine when we all lived in the Garden of Eden.  But we've been sent out of it into the grown-up world of virtual reality, where there are evil processes as well as good ones, and we need to be able to distinguish one from the other.  This metaphor – and the whole discussion – doesn't come from a “snit with Eve”…  It results from the vulnerabilities of the current generation of software and distributed architecture – regardless of platform – and a desire to make sure we don't repeat the same mistakes going forward.  

AOL and “63 Million OpenIDs”

First Microsoft's announcement with JanRain, SXIP and Verisign at RSA.  Now news that AOL has launched an experimental system and announced it will support the next version of OpenID. 

The world streams by at breakneck speed.  We're getting some real momentum on this convergence thing.  I hear the identity big bang coming towards us.  Here's a fascinating post by panzerjohn at dev.aol.com

Yesterday, I blogged about AOL's work-in-progress on OpenID. It generated a lot of positive commentary. I realized after reading the reactions that I buried the lead: There are now 63 million AOL/AIM OpenIDs. Anyone can get one by signing up for a free AIM account. This is cool.

To address Paul's concern in Please delete my aol OpenID: We definitely want the user to be in control of their online presence. At the moment, the OpenID URL at openid.aol.com redirects you off to an AIM Profile. That's not necessarily the long term experience, though I think it should be one of the default options. George Fletcher has pointed out that it would be even better if we could redirect people off to whatever page they wanted, as long as they could verify that they owned the page. My take is, if you don't actually use the OpenID URL, it doesn't really exist. The same way a Wiki page doesn't exist until you edit it. On the other hand, having people go in and kick the tires to uncover issues is exactly why we're talking about this. So let us know what you think.

Another important point is that you can point at the AOL OpenID service from any web page you own in order to turn its URL into an OpenID. The minimal requirements are basically that you have some AOL or AIM account, and that you add a couple of links to your document's HEAD:

link href=”https://api.screenname.aol.com/auth/openidServer” mce_href=”https://api.screenname.aol.com/auth/openidServer” rel=”openid.server” 

link href=”http://openid.aol.com/screenname” mce_href=”http://openid.aol.com/screenname” rel=”openid.delegate”

We added this to our blogs product in a few minutes minutes and it's in beta now. You can also support YADIS discovery which gives additional capabilities. See Sam Ruby's OpenID for non SuperUsers for a good summary.

The detailed status from yesterday's post:

  • Every AOL/AIM user now has at least one OpenID URI, http://openid.aol.com/screenname.
  • This experimental OpenID 1.1 Provider service is available now and we are conducting compatibility tests.
  • We're working with OpenID relying parties to resolve compatibility issues.
  • Our blogging platform has enabled basic OpenID 1.1 in beta, so every beta blog URI is also a basic OpenID identifier.  (No Yadis yet.)
  • We don't yet accept OpenID identities within our products as a relying party, but we're actively working on it.  That roll-out is likely to be gradual.
  • We are tracking the OpenID 2.0 standardization effort and plan to support it after it becomes final.

(I should clarify that I really work in the social networking / community / profile / blogging groups at AOL rather than the identity group per se. You can look to see what I actually do on a day to day basis over at my personal blog.)

This is amazing stuff.

Can browser-based plugins solve OP phishing?

Dready blog writes about OpenID phishing and proposes a browser plugin that introduces a delay in the dialog box before it can be dismissed.

“The OpenID phishing issue is a hard one to solve, particularly because it aims to:

  1. be user-friendly, i.e. it should pass the mother-in-law test; and
  2. work on the web platform without special software or browser plugin

“So, why is this suddenly a problem?

“Not really, phishing is a perennial problem on the Internet that researchers and developers have been trying to solve for many years now. OpenID just accentuates it because RPs are unregulated. You don’t need any agreement with any OP, essentially anyone can set up a web site and put the OpenID login button. If OpenID takes off, RP sites will grow like ’shrooms and user will get used to the idea that if they see the OpenID logo, they can type their URL to login. This only makes it harder for users to discern the good RPs from the bad ones.”

Actually, the problem is worse than the one we currently face.  We are not just dealing with “the perennial problem”.  If you use one OpenID account to go to two hundred sites, the thief who steals your OpenID credentials gains access to any of the 200 sites.  That's new. 

“This is really a social problem, and not a fault of the OpenID protocol. Users need only to trust their OP, and not the RPs that they interact with. If a rogue RP sends you to a page the poses as your OP but the URL doesn’t match your OP’s, you bail out. Doesn’t that sound simple? Well, the cold hard fact is that phishing works and there is research1 to prove that people get tricked very easily.”

Dready's right about the research.  But rather than calling it a “social problem” I'd call it a “social engineering attack”.  Further, there is a protocol problem.  The protocol is based on telling the RP where the OP is located – such that an evil site can automate a “man in the middle attack”.  Some other protocols, including the one used by CardSpace, do NOT have this problem.  That's why combining CardSpace and OpenID is useful. 

“Numerous ideas to mitigate phishing attacks have been floating around the OpenID list and on the OpenID mini-blogsphere. Ben Laurie argues for a client-side solution:

‘Authentication on the web is broken, and has been for a long time. The OpenID fanboys want OpenID to work on any old platform using only standard software, and so therefore are doomed to live in the world of broken authentication. This is fine if what you protect with your OpenID is worthless, but it seems clear that these types of protocol are going to be used to authenticate for things of value.    

…

'This is the root of the problem: if you want to protect anything of value, you have to do better than existing Web solutions. You need better client-side software.’

“The picture is not so sunny, however, because most users:

  • won’t know / bother to install specialized plug-in or upgrade their browsers unless they’re forced to
  • won’t know the difference between citibank.com/signon and citibank.com-banking-foobar.com

“And even if they installed those anti-phishing toolbars and what not, they still fall for it!

“While I can’t decipher the wirings of the mums-and-dads who fall prey for phishing attacks, I know that I get lazy sometimes and just don’t bother. Then I remember this little trick that Firefox introduced to ensure that users get the warning before installing extensions — Introduce a delay in the dialog box before it can be dismissed. That sort of worked for me, at least for that 5 seconds I can’t click so I might as well read a little.”  (Code follows here…)

This may help Dready and in that sense it may be a welcome finger in the dike.  But as OpenID becomes successful and is used for sites of value, this kind of solution clearly won't stand up to attack or scale to embrace the population.

People really need to think about what it will mean to actually have “single signon”, rather than just talk about it. 

You cannot overestimate the value of your single signon credentials, or the extent to which they will attract attack.

I don't think browser-based solutions will do anything for us long term – the whole point of browsers is to make it easy to introduce cool new behaviors and empower the RP to give the user great experience.  They are vulnerable because they put the RP in control – by design

This doesn't mean plugins can't play a role in getting us to our destination.  But ultimately, you need defense in depth, many layers of defense.  If we think of the browser as a “broadband communications channel” inundating the user with information, we also need a “narrowband communications channel” honed to protection of the user.  The CardSpace work represents an attempt to create this.

 

Drummond Reed on CardSpace and OpenID

Amongst other things, Drummond is CTO of Cordance and co-chair of the OASIS XRI and XDI Technical Committees.  He's playing an important role in getting new identity ideas into the Internet Service Provider world.  Here he responds to my first convergence post:

Earlier this month Kim Cameron starting blogging about some of the phishing concerns he’s had about OpenID that he and Mike Jones have shared with myself and other members of the OpenID community privately since Digital ID World last September. Given that anti-phishing protection is one of the greatest strengths of CardSpace, one of Kim’s and Mike’s suggestions has been for OpenID providers to start accepting CardSpace cards for customer authentication.

Today Kim blogged his proposed solution for integrating OpenID and InfoCard in detail. He does a wonderful job of it, making it very clear how using CardSpace and OpenID together can be a win/win for both. With Windows Vista shipping to consumers at the end of the month, and the CardSpace upgrade now available to XP users, this is a very practical solution to increasing OpenID security that I expect all XDI.org-accredited i-brokers (who all provide OpenID authentication service for i-name holders) to implement as soon as they can.

Kim closes his post by saying, “That said, I have another proposal [for integrating OpenID and CardSpace] as well.” That’s good, and I await it eagerly, because I too believe the integration can go much deeper, just as it can for OpenID and SAML. The heart of it is individuals and organizations being able to assert their own resolvable, privacy-protected digital identifiers. That’s the foundation of the OpenID framework, and the job for which we’ve been designing XRI i-names and i-numbers for the past five years. Microsoft’s current default CardSpace schema does not yet natively support XRIs as digital identifiers, but adding them could increase their power and utility and be another big step towards convergence on a unified Internet identity layer.

I'm going to clone myself so I can find more time to write up my second proposal.  Meanwhile, just a small clarification.  Drummond talks about the “default CardSpace schema”.  He's really talking about the “default Self-Issued Card schema.” 

CardSpace itself handles tokens of any type, containing claims of any type.  There are no limitations on your schema if you create a managed card.  I'll make that clearer in my next post. 

Further, we tried to keep the “bootstrap” Self-Issued Card provider down to a minimal set of initial schema choices – precisely to leave room for a managed card ecology.  But one of those initial claims is a URL…  I thought an i-name or i-numbers would be able to go there.  Is more needed?

 

Scary phishing video from gnucitizen

Here's a must-see that punctuates our current conversation with – are you ready? – drama and numerous other arts.

Beyond the fact that it's just plain cool – and scary – as a production, it underlines one of the main points we need to get across.  The evolution of the virtual world will be blocked until we can make it as safe as the physical one. 

As Pam says, “this video really captures the panic involved in being hacked…”.  That's for sure.

Integrating OpenID and Infocard – Part 1

Let's start by taking a step-by-step look at the basic OpenID protocol to see how the phishing attack works.  (Click on the diagrams to see them on a more readable scale.)

The system consists of three parties – the relying party (or RP) which wants an ID in order to provide services to the user;  the user – running a browser;  and the Identity Provider (OpenID affectionados call it an OP – presumably because the phrase Open Identity Identity Provider smacks of the Department of Redundancy Department.   None the less I'll stick with the term IP since I want to discuss this in a broader context).

OpenID can employ a few possible messages and patterns, but I'll just deal with the one which is of concern to me.  An interaction starts with the user telling the RP what her URL is (1).  The RP consults the URL content to determine where the user's IP is located (not shown).  Then it redirects the user to her IP to pick up an authentication token, as shown in (2) and (3).  To do the authentication, the IP has to be sure that it's the user who is making the request.  So it presents her with an authentication screen, typically asking for a username and password in (4).  If they are entered correctly, the IP mints a token to send to the RP as shown in (5) and (6).  If the IP and RP already know each other, this is the end of the authentication part of the protocol.  If not, the back channel is used as well.

The attack works as shown in the next diagram.  The user unwittingly goes to an evil site (through conventional phishing or even by following a search engine).  The user sends the evil RP her URL (1) and it consults the URL's content to determine the location of her IP (not shown).  But instead of redirecting the user to the legitimate IP, it redirects her to the Evil Scooper site as shown in (2) an (3).  The Evil Scooper contacts the legitimate IP and pulls down an exact replica of its login experience (it can even simply become a “man in the middle”) as shown in (4).  Convinced she is talking to her IP, the user posts her credentials (username and password) which can now be used by the Evil Scooper to get tokens from the legitimate IP.  These tokens can then be used to gain access to any legitimate RP (not shown – too gory).

The problem here is that redirection to the home site is under the control of the evil party, and the user gives that party enough information to sink her.  Further, the whole process can be fully automated.

We can eliminate this attack if the user employs Cardspace (or some other identity selector) to log in to the Identity Provider.  One way to do this is through use of a self-issued card.  Let's look at what this does to the attacker.

Everything looks the same until step (4), where the user would normally enter her username and password.  With self-issued cards, username and password aren't used and can't be revealed no matter how much the user is tricked.  There is nothing to steal.  The central “honeypot credentials” cannot be pried out of the user. The system employs public key cryptography and generates different keys for every site the user visits.  So an Evil Scooper can scoop as much as it wants but nothing of value will be revealed to it.

I'll point out that this is a lot stronger as a solution than just configuring a web browser to know the IP's address.  I won't go into the many potential attacks on the web browser, although I wish people would start thinking about those, too.  What I am saying is the solution I am proposing benefits from cryptogrphy, and that is a good thing, not a bad thing. 

There are other advantages as well.  Not the least of these is that the user comes to see authentication as being a consistent experience whether going to an OpenID identity provider or to an identity provider using some other technology. 

So is this just like saying, “you can fix OpenID if you replace it with Cardspace”?  Absolutely not.  In this proposal, the relying parties continue to use OpenID in its current form, so we have a very nice lightweight solution.  Meanwhile Cardspace is used at the identity provider to keep credentials from being stolen.  So the best aspects of OpenID are retained.

How hard would it be for OpenID producers to go in this direction? 

Trivial.  OpenID software providers would just have to hook support for self-issued cards into their “OP” authentication.  More and more software is coming out that will make this easy, and if anyone has trouble just let me know.

Clearly not everyone will use Infocards on day one.  But if OpenID embraces the  alternative I am proposing, people who want to use selectors will have the option to protect themselves.  It will give those of us really concerned about phishing and security the opportunity to work with people so they can understand the benefits of Information Cards – especially when they want, as they inevitably will, to start protecting things of greater value.

So my ask is simple.  Build Infocard compatibility into OpenID identity providers.  This would help promote Infocards on the one hand, and result in enhanced safety for OpenID on the other.  How can that be anything other than a WIN/WIN?  I know there are already a number of people in the milieux who want to do this.

I think it would really help and is eminently doable.

This said, I have another proposal as well.  I'll get to it over then next few days.

Ben Laurie and the “Kittens” phishing attack.

Here's a post about potential OpenID phishing problems by Ben Laurie, long-time security avocate who played an important role in getting SSL into open source.  He's now at Google.  Don't misinterpret his intentions despite his characteristically colorful introductory sentence – in a subsequent piece he makes it clear that he too wants to find solutions to these problems.

OpenID announced the release of a new draft of OpenID Authentication 2.0 today. I’m reluctantly forced to come to the conclusion that the OpenID people don’t care about phishing, since they’ve defined a standard that has to be the worst I’ve ever seen from a phishing point of view.

OK, so what’s the problem? If I’m a phisher my goal is to be able to log in to some website, the Real Website, as you, the Innocent Victim. In order to do this, I persuade you to go to a website I control that looks like the Real Website. When you log in, thinking it is the Real Website, I get your username and password, and I can then proceed to empty your Paypal account, write myself cheques from your bank account, or whatever fiendish plan I have today.

So, why does OpenID make this worse? Because in the standard case, I (the phisher) have to make my website look like the Real Website and persuade you to go to it somehow – i.e. con you into thinking I am the real Paypal, and your account really has been frozen (or is that phrozen?) and you really do need to log in to unphreeze it.

But in the OpenID case I just persuade you to go anywhere at all, say my lovely site of kitten photos, and get you to log in using your OpenID. Following the protocol, I find out where your provider is (i.e. the site you log in to to prove you really own that OpenID), but instead of sending you there (because, yes, OpenID works by having the site you’re logging in to send you to your provider) I send you to my fake provider, which then just proxies the real provider, stealing your login as it does. I don’t have to persuade you that I’m anything special, just someone who wants you to use OpenID, as the designers hope will become commonplace, and I don’t have to know your provider in advance.

So, I can steal login credentials on a massive basis without any tailoring or pretence at all! All I need is good photos of kittens.

I had hoped that by constantly bringing this up the OpenID people might take some step to deal with the issue, but they continue to insist on punting on it entirely:

The manner in which the end user authenticates to their OP [OpenID provider] and any policies surrounding such authentication is out of scope for this document.

which means, in practice, people will authenticate using passwords in forms, as usual. Which means, in turn, that phishing will be trivial.

Like me, Ben was struck with how readily the system currently lends itself to automation of phishing attacks.  His second post on the subject is also interesting.