[OpenID] New OpenID Customer Research Activity - Googleresearch on federated login

[Brandon Ramirez]

Bingo!  This silliness of arguing over what is the correct way to represent
a unique identity is like the classic data modeler's debate over natural or
surrogate primary keys (see
http://articles.techrepublic.com.com/5100-10878_11-1045050.html).  At the
end of the day, it depends on both preference and what makes sense for the
given scenarios.  And here we are, trying to dogmatically agree on a single
method that fits every scenario.

I also feel there is too much new stuff out there and not enough re-use of
existing technologies and methodologies.  For example, in regards to the
argument of centralized identity versus distributed identity, why not take a
page out of the DNS book?  The Domain Name System solved this problem many
years ago (granted, many would argue that DNS is a bit broken, but hey, at
the end of the day... it works and it works well).  I'm not referring to the
DNS from a technical standpoint, but from a modeling standpoint.  Resolution
is delegated in a distrubted manner that providers can setup as they see
fit.  But everything has to go through certain top-level registrars, who can
then place assurances on certain things and track accountability
information.

The same could be used for UCI - arbitrary OP's can have trust delegated to
them in a distrubted fashion by a central authority whom we all agree to
trust.  Of course, with a single point of failure, one must ensure that root
is truly trustworthy, but we all know that...

As for usability, I've always felt that usability becomes easier when the
technology is modeled well.  OpenID does not model identity well in my mind,
because it uses an identifier - namely an HTTP URI - as a way to uniquely
identify a human being.  There is inherantly no relationship between a URI
and a person, so OpenID creates one.  I think more research needs to be done
to determine what is the right way to do this, a lot like Eran suggests,
where users can use whatever type of identifier they want.

Do I agree that an email address it the correct identifier?  No... but it's
closer than a web page URI.  The argument that email addresses are a bad
identifier because people may have more than one (in other words, multiple
primary keys) breaks down because the HTTP URI identifier is the same thing!

People have a one-to-many relationship with email addresses and HTTP URI's.
That makes them poor identifiers (sometimes, many-to-many with email
addresses).  However, email addresses are in a format that is more conducive
to identification.  I suspect that is a big part of why Kerberos (network
single-signon) uses an email address-style identifier.  Specifically, it
uses userid at realm, where realm is a fully-qualified domain name.  That does
NOT mean that a Kerberos principal is an email address, but if one wants
them to be, they easily can be.

Because of this, Kerberos is easy to use because it conceals all of itself!
When you go to work in the morning, how many peole are aware of Activity
Directory and their Kerberos tickets?  None.  They type in their existing
usernames and passwords, or smartcards, or whatever, and the system figures
it all out.  When the system is modeled right, it can become automated and
easy to use.

- Brandon

On Thu, Sep 25, 2008 at 6:10 PM, Eran Hammer-Lahav <eran at hueniverse.com>wrote:

>  My proposal is for the OpenID foundation to take all the money it has,
> license as much porn as it can, and create the world's biggest porn site
> ever that uses OpenID as its exclusive, free, form of entry.
>
> Joking aside, people will learn how to use something new if they have a
> reason to. I wonder what the study result would have been if Google offered
> each test subject an extra $1000 if they figured out how to login using the
> more complex mockups. My fundamental problem with this discussion is that it
> assumes there must be a way to solve this problem that does not require user
> reeducation.
>
> Federated login requires two values: Identifier (username at OP) and
> Authority (OP domain). The proposals we have so far to collect these two
> values are:
>
>
>    1. Use email address in which the Identifier is separated from the
>    Authority using the '@' character.
>    2. Use URL which points to a document containing these two values.
>    3. Use XRI which is resolved into a document containing these two
>    values.
>    4. Ask for the Identifier and give pre-configured options for the
>    Authority (for example pull down menu).
>    5. Show a custom button which takes the user to the Authority and asks
>    for their Identifier there.
>    6. Ask for the two values separately (similar to how Windows Domain
>    login works).
>
>
> Let's face it, we are not going to agree on one solution. Why? Because this
> community consists of two many competing interests and we have been having
> this exact debate on and off for over 2 years. To me this calls for a
> radical change in approach and here are two half-baked ideas the
> demonstrate:
>
>
>    1. Deal with the usability issue directly: let the OIDF board make a
>    large and aggressive move to bring OpenID to the browser by either working
>    directly with the major browser providers or spec out the technical
>    requirements of how OpenID should work in the browser and offer $100K prize
>    for the best open source add-in that works with IE, Safari, and FireFox.
>    2. Deal with the underlying technology issue: break the OpenID
>    specification to completely separate the federation workflow from the
>    identifier. Everyone seems to think their identifier is superior to others
>    (email, URL, XRI, etc.), so why not let anyone create whatever identifier
>    they want as long as there is a way to go from the identifier to the two
>    values. This can be done by using a registry or resolver owned by the OIDF
>    (which of course will be redundant and can use many existing technologies).
>
>
> While this debate continues, business deals are being made to put those
> special buttons on partner sites which will eventually offer enough value to
> most users to make OpenID irrelevant.
>
> EHL
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080927/29f71af9/attachment-0001.htm>