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...
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.
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...
- Alice goes to a new web site (http://relyingparty.example.com)
- Alice enters her email address (alice@example.net)
- The web site (relyingparty.example.com) uses webfinger to discover Alice's OpenID Provider
- 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)
- 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.
- The web site receives the successful authentication response and retrieves Alice's email address
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.
3 comments:
hmm when you start relying on some one else to do the email verification - doesn't that mean now the OP needs to provide email verification context along with the verified email ? Are there any fields being defined for that ? How and when the email has been verified for example.
Also given that almost all email providers now support OpenID, isn't a successful OpenID login with the user entered email address good enough ? (Of course the OP needs to be same as Email Provider). Wouldn't that be better than relying on someone else to provide verified email as a user attribute (which raises the questions of when, how and if user is still the same owner)?
When it comes to meta-data about the "verified email address", I'm not sure it's really necessary (other than the distinction that an email is verified or not). The relying party (RP) is already depending on the identity provider to correctly authenticate the user. If the RP trusts the identity provider for authentication, then it seems likely it should also trust the provider for correctly specifying whether an email address is verified or not.
The problem with just assuming that the OP that supports email will return the OP's email address is that webfinger allows for a level of indirection such that my XRD for my gmail address could point to AOL as my OP. In this case, it's likely that the email address the user entered won't be the same as the one the identity provider returns.
[P.S. Sorry it took so long to get your comment posted.]
Post a Comment