[OpenID] Facebook support for OpenID. Where?

[Chris Messina]

On Wed, May 20, 2009 at 7:56 AM, Andrew Arnott <andrewarnott at gmail.com>wrote:

> 2009/5/19 Santosh Rajan <santrajan at gmail.com>
>
>>
>> That
>> is why Facebook has not implemented OpenID for sign in and sign up.
>> Because
>> they cannot without an email address.
>
>
> Really?  You say that sounding like you know.  Who have you heard this
> from?  Be careful what you say as if you know.
>

Indeed. There are other usability issues that must be addressed for OpenID
to show up on Facebook's homepage for account sign up for creation.
FriendFeed has come the closest so far, and they've resorted to the NASCAR
approach (the Google button launches the OpenID/OAuth hybrid flow):

http://www.flickr.com/photos/factoryjoe/3526058220/



> Technically speaking from a general perspective, I would say Facebook could
> absolutely work without taking a user's email address, however as Shade said
> perhaps their database schema assumes an email address as a primary
> identifier.  Even so, an OpenID URL with an email address as an attribute
> would certainly be adaptable by a database schema modeled after that.
>

Could work technically, of course, but that's not the issue here, in the
least.

OpenID is a *social* technology and must be implemented beyond what's
provided by the spec — that is, in a way that people who have never HEARD OF
OpenID can use it. And in a way that doesn't break people's expectations —
which is a hard thing to do, considering that the whole point of OpenID is
to do exactly that.

I think that over time, if we — as a community — can work with Facebook (and
others) to provide tested models and user experiences for making OpenID more
useful and understandable by regular folks, we'll see OpenID become more
visible. But it's not a technical matter. And it's not about keying
databases off of email addresses.


>
> Even if email addresses become a valid OpenID identifier, RPs will still
> have to perform email verification.  It may be an optimized process, or it
> may be *worse*. ... If on the other hand RPs choose to trust certain OPs'
> email attribute assertions, the solution can be applied today and without
> any special software or behavior on the end user's part.  And that's what
> I'm advocating for.
>

This is something that has come up quite often. Just because you can login
with an identifier that LOOKS like and email address doesn't mean that you
can receive messages at that address.

For example, user at domain.com might be how I gain FTP access to domain.com,
as in user:password at domain.com <user%3Apassword at domain.com>. There may be no
user at domain.com email address.

user at domain.com may also simply be a Jabber ID, with no capacity to receive
email messages.

I think it's important to separate the form of the identifier from the
function — just because it LOOKS like an email address doesn't mean that it
is one.

That said, for those cases where we're actually talking about a conventional
email address, I think that emails are primarily useful for use in directed
identity cases — where you lop off everything before the '@' and use the
domain to perform discovery.

We've talked about this for ages and even have a working prototype:

http://emailtoid.net/

...and spec:
http://eaut.org/

and I wrote about this last June, so Santosh, sorry, but you're not the only
one advocating for the use of email addresses in OpenID:

http://factoryjoe.com/blog/2008/06/22/announcing-emailtoid-mapping-email-addresses-to-openids/

...it's really just a matter of making more progress on XRD/LRDD (discovery)
— and then pushing forward with OpenID 2.1.

It'll happen in due time.

Chris

-- 
Chris Messina
Open Web Advocate

factoryjoe.com // diso-project.org // openid.net
This email is:   [ ] bloggable    [X] ask first   [ ] private
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090520/28f478e9/attachment.htm>