Email Verification and Identity Federation

Most sites today, when registering a new user, invoke some form of email verification. They ask the user for their email address, send the user an email, and ask the user to click a link in the received email. This ensures the web site has a "valid" email address for the user.  While not ideal, this works today as the user is "registering" directly with the web site.

Now enter identity federation and the situation changes. If I can log into the web site using an identity I already have, what does this mean for the email verification process? Does the web site need to still send me through that out-of-band email verification process? Or can something better be done to improve the user experience?

The answer to that question is yes, but it takes the web site changing their perspective on email verification. Instead of verifying the email address, the web site needs to verify the user (via identity federation) and use the identity protocol's attribute mechanisms to retrieve a verified email address. The difference is subtle but important.

Let use the following scenario as an example. Using webfinger as a way to bootstrap from an email address to an identity provider...

1. Alice goes to a new web site (http://relyingparty.example.com)
2. Alice enters her email address (alice@example.net)
3. The web site (relyingparty.example.com) uses webfinger to discover Alice's OpenID Provider
4. The web site starts the OpenID authentication flow with Alice's OpenID Provider requesting an email address as a required element via Attribute Exchange (AX)
   
5. Alice authenticates to her OpenID Provider and consents to sending her email address (alice.smith@example.com) to the web site. Note that Alice's OpenID Provider always returns a verified email address via AX.
   
6. The web site receives the successful authentication response and retrieves Alice's email address

Note that the verified email address returned from the identity provider is different from the one Alice entered at the site. This is the subtle difference that web sites need to consider. It doesn't matter which email address the user uses when interacting with the web site. What matters is that the web site has a mechanism to associate a verified email address with authenticated users.

As identity federation grows, and web sites adopt this approach, the user experience will improve as there will be no out-of-band messaging required to start engaging with a web site.

OpenID 2.0 Provider support live @ AOL

I'm excited to announce that the AOL Identity Services team has fully deployed OpenID 2.0 Provider support. Directed identity flows are now enabled so just entering 'aol.com' into an OpenID field will start the authentication flow. In addition to directed identity, this release also supports "check immediate" flows, SREG, AX, UI (popup browser), PAPE (as required by the ICAM OpenID 2.0 Profile) and of course the ICAM OpenID 2.0 Profile itself.

We have also improved the UI making it much cleaner and easier to follow. One feature of this new UI is a page that allows the user to choose, when first visiting a new site, whether to use their public OpenID (http://openid.aol.com/<username>) or an opaque one. Of course, this choice isn't necessary if the user provides the relying party their full OpenID or the relying party specifically requests an opaque identifier (via PAPE policy). I'd really appreciate feedback on whether this "privacy" feature is helpful to users or just adds more confusion.

In addition to the existing SREG support, the same attributes will be supported via Attribute exchange. There is equivalent support for the http://axschema.org URIs but only partial support for the Information Card URIs as there weren't direct equivalents for all of the attributes. Here is what is currently supported.

http://axschema.org/namePerson/friendly
http://axschema.org/contact/email
http://axschema.org/birthDate
http://axschema.org/person/gender
http://axschema.org/contact/postalCode/home
http://axschema.org/contact/country/home
http://axschema.org/pref/language
http://axschema.org/pref/timezone

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country

Suggestions or requests for specific attributes are always welcome. One point of clarification regarding email addresses and verification. The current implementation defaults the email address to the user's AOL provided email address but does allow the user to change the value returned to the relying party.

While there is still a lot to do, it feels really good to finally reach this milestone.