Unique Usernames vs. Email Addresses - What does this mean for OpenID?

Brad Topliff brad.topliff at ootao.com
Tue Nov 7 20:09:45 UTC 2006


I think that i-names (www.inames.net <http://www.inames.net/> ) should be
mentioned in this discussion, as they are accepted as an OpenID identifier
and offer more possible solutions as well as UX challenges.

 

Briefly, for the uninitiated, inames are a globally unique namespace that
start with an "=" (recommended for individuals) or an "@" symbol (for
communities).  The names can also have delegation character (a "*") so that
you might end up with =example, @exampleco or =example*name and
@exampleco*marketing*marketingguy and so on.  = and @ names are owned (read
cost the user) while delegated names might be given away, much like email
addresses.

 

The syntax of these names can be a migration path for sites that have unique
names already. A site that could (and I am thinking outloud here) have a
place to put this unique name that maps onto the site's @ name and doesn't
initially have to explain the user that they just used an OpenID at all.
This would probably change the user's experience in some way, however.

 

For i-name users, there are services available now (and more coming) that
may help those registration concerns.  For instance profile sharing
capabilities that may or may not find themselves into an OpenID spec are
integral to the i-names plan. 

 

Inames can also be reused to keep in contact with members.

 

The biggest challenge (I hope) here is the user education.  URI's set up as
OpenIDs and XRIs (Inames) which are by nature set up as OpenIDs, all fall
under the same umbrella and this might be confusing, if not handled
properly.

 

Hopefully this was less disjointed than it seemed writing it and will help
frame the discussion.

 

Best,

 

Brad Topliff

=brad.topliff

 

 

  _____  

From: user-experience-bounces at openid.net
[mailto:user-experience-bounces at openid.net] On Behalf Of Joshua Viney
Sent: Monday, November 06, 2006 11:56 AM
To: OpenID user experience
Subject: Unique Usernames vs. Email Addresses - What does this mean for
OpenID?

 

As mentioned in a previous email
http://openid.net/pipermail/user-experience/2006-November/000028.html ,
there was recently an active discussion in the IxDA mailing list re:
usernames vs. email addresses for sign-in (thread found at
http://lists.interactiondesigners.com/pipermail/discuss-interactiondesigners
.com/2006-October/012228.html ). There wasn't much of a conclusion. The more
hardcore usability people tend to lean towards empowering the users by
letting them enter whichever they prefer. From my experience working in the
online personals/social networking and MMOG worlds, I would tend to lean
away from using usernames because:

 

1. unique usernames don't scale (how often to you see implementations of
"check availability" because of this problem?)

2. email addresses have a known format/structure which makes it easier for
users to fill in the form during registration and after being away for a
while 

3. email addresses can be reused to keep in contact with members

 

The issue of users having multiple email addresses is largely solved by the
site keeping in contact with the user using the email address provided. It
would be very difficult for me to forget my Amazon email sign-in because
they send me emails every week. 

 

OpenID seems like it could be a very compelling replacement. UX and product
folk have been struggling with this issue for a while (Here's the link to
Jakob Nielsen's Useit Alertbox from 1999 that addresses this issue:
http://www.useit.com/alertbox/990711.html ), what lessons can be learned
from existing authentication implementations? 

 

The core issue for product and marketing folk is to authenticate users with
as little disruption to the user process as possible. Every step that a user
must take in order to achieve a goal on a site increases the likelihood of
abandonment (think initial registration not sign-in). I would argue that any
process that wants to replace existing systems should attempt to be more
efficient in this regard. Placing control of user data in the user's hands
is one piece to the puzzle, but it will be a lot easier to convince
potential relying parties if we can show increases in conversion and
decreases in support related issues re: lost sign-in information.

 

I believe there is some risk in attempting to change the way users sign into
sites. What happens in the future when OpenID is supported on sites where a
person already has a membership? Is there any way to connect that user's
previous account/membership to their OpenID account? Has this been
discussed?

 

 

Josh Viney

 <http://www.eastmedia.com/> http://www.eastmedia.com -- EastMedia

 <http://identity.eastmedia.com/> http://identity.eastmedia.com -- OpenID,
Identity 2.0

 

 





 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-user-experience/attachments/20061107/269429a7/attachment-0002.htm>


More information about the user-experience mailing list