[OpenID] Combining Google & Yahoo user experience research

[Nate Klingenstein]

Chris,

> It's unclear what you're proposing or suggesting...! Still, I have  
> some feedback...

I was emphasizing why the proposed best practices wouldn't work for  
us.  My own position is there are lots of mechanisms, none of which  
is inherently globally superior to the others, or the inevitable one  
way.  It depends on application design and integration, security  
requirements, and user base, among others.

> Nothing about including email identifiers as valid OpenID  
> identifiers requires you that you use email as your primary  
> identifier. It simply enables the use of email addresses for  
> signing in to services. So many sites (in the wild) now immediately  
> ask you for your email address after you sign up with OpenID that  
> it seems counter-productive NOT to support email addresses...  
> especially since they often require you to confirm your email  
> address via token (which, if it were part of the OpenID spec, could  
> be done entirely within the browser).

> It's also conceivable that someone could delegate an email address  
> to a third-party OpenID provider, rather than their email  
> provider... so if were to use chris at example.com as my email  
> address, example.com would be able to redirect (302) to my actual  
> OpenID URL: realopenid.com/chris.

Email is certainly the primary identifier by which users know  
themselves today, which made us strongly consider the kind of  
discovery you mention.  There are at least 3 reasons we reluctantly  
turned it down from major consideration.

We don't want to be the only provider of identity data a user might  
have.  If they're trained to always enter their email address on all  
federated sites, and that email address always comes to us, then we  
have to be.  We'd rather supply the data we're authoritative for, and  
let other sites handle the data they want to.

We also then must rely on the identification and general data  
stewardship of the email provider (e.g. they do the redirect right  
every time, and don't track personal usage patterns, etc.).  With  
current business models, and the preponderance of email providers out  
there that students like to pick from, it'd be a leap of faith at  
this point.

And, again, immediately asking for email can give away a user's  
identity immediately, which for us (FERPA) is just not acceptable.

That said, I've long seen the "tacking on" of additional data by a  
provider to another IdP's assertion a key future use case that would  
be a quantum step forward for federated identity.  I know people will  
work hard on it when the time comes, so I want protocols that will  
support it without too much modification.

> I think you bring up some useful experiences in the wild, and I'm  
> just trying to focus your feedback... can you be specific about  
> what of the research is good and useful and what of it would not  
> work given your restrictions?


As one example, applications that have login systems already often  
just want to graft a link to the federated SSO system right next to  
existing login boxes.  We've pushed back at this half-measure, and  
now we have solid data that it was the right choice to do so.  The  
link is often not noticed, or the user enters their campus ID/ 
password directly into the text boxes.  For these systems, presenting  
instead a list of acceptable IdP's and nothing else has been pretty  
successful.

Many applications that have a preponderance of access from one IdP  
will have a button, or a default page.  Placing the logo of the  
primary IdP -- usually a university -- along with a "Not from Podunk  
University?  Select your school from this list." option has been  
successful.  Thanks to college sports, many students would sooner die  
than use a login page or button branded by a rival. ;D

These aren't good interfaces, but more importantly, they're not  
dangerous interfaces.  We can afford a little more frustration from  
users because the trusted identity data we're able to deliver has  
high value to applications.  We'd still like to improve the situation  
with better alternatives, and give deployers a more comprehensive  
guide as to which to pick in any given situation.

Hope this clarifies things,
Nate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081014/7472e633/attachment-0002.htm>