HeresTomWithTheWeather

This year, I had the fortune of waking up to the ring of my cellphone several dozen mornings. Each time the conversation was the same:

Hello?

May I speak to Jennifer Such and Such? This is the Acme Corporation.

Nobody named Jennifer lives here. You called yesterday and I asked to have this number taken out of your database.

Are you sure?

Yes, I've had this number for many years and I can assure you that no one by that name has ever had this number. Please remove my number from your list.

The calls went on for a few weeks and then, like weatherman Phil Connors in Groundhog Day, I finally woke up one morning without a wakeup call from the Acme Corporation.

But, then they came back for another week. The exact same conversation each time.

The relying party (Acme Corporation) trusted that the phone number was correct even though the identity provider never validated the number. The cost to the relying party and the identity provider was negligible. Apparently, it was cheaper for them to call me for weeks on end than to delete the nonvalidated erroneous data.

What does this have to do with OpenID?

If an identity provider doesn't validate an email address, some sucker like me is going to be getting Jennifer Such and Such's emails from the Acme Corporation. I presumably can't complain to the identity provider because that's Jennifer's data, after all. I can't go to the relying party to fix the problem, either. Unless the relying party knows that Jennifer's identity provider doesn't validate email addresses and requires the validation itself, I'm going to be receiving these emails for the rest of my life.

So, if Jennifer signs up to a website that doesn't possess this special knowledge of her identity provider and take corrective action, guess what? Yeah. Rise and shine, campers, and don't forget your booties!

It turns out that a month ago, the draft OpenID Assertion Quality Extension was published. Among other things, this

provides means for a Relying Party to request additional information about the specifics by which a user enrolled

In particular, there is the enroll.verified.email property.

This is the feature I thought out loud about yesterday in the comments of my previous post:

it's something i would be willing to do if there was an easy way for me to query the provider for the integrity level of the data (in this case, was the email address validated? the provider would have the option to say "don't trust this email address." of course, if he didn't say that, the data could still be invalid, but such an option would let the website know that it needed to do the validation itself.)