allow customizable OpenID name

Bug #210908 reported by Lucian Adrian Grijincu
8
Affects Status Importance Assigned to Milestone
Canonical SSO provider
Won't Fix
High
Unassigned

Bug Description

Logging in with a launchpad OpenID leaves behind a username identical to the unique ID assigned to that user.
For example I posted something on a blogspot page and this is what blogspot generated

    <dt class="comment-author openid-comment-icon" id="c3248246332071663710">
        <a href="https://login.launchpad.net/+id/FHrCpfF" rel="nofollow">FHrCpfF</a>

Launchpad should allow users to select how they what to be "named" and should allow different usernames for different sites.

I may want to be identified as "lucian" when I post something on blogspot
        <a href="https://login.launchpad.net/+id/FHrCpfF" rel="nofollow">lucian</a>
but use my full name if I log on to a site where this would be better.
        <a href="https://login.launchpad.net/+id/FHrCpfF" rel="nofollow">Lucian Adrian Grijincu</a>

Anyway, if it's too hard to have one username per website, at least the default name should be customizable.

Tags: openid
description: updated
Changed in launchpad:
importance: Undecided → High
milestone: none → 1.2.4
status: New → Confirmed
Revision history for this message
Mantas Zimnickas (sirex) wrote :

Yes, I totally agree! Mostly OpenID providers gives you beautiful URL, like: myusername.provider.com

So launchpad should provide at least: https://launchpad.net/+id/myusername. There is no need for custom name, because all launchpad users already has their usernames: launchpad.net/~myusername

In my opinion it would be perfectly, that launchpad's OpenID, would look like this:

  launchpad.net/~myusername

Revision history for this message
Lucian Adrian Grijincu (lucian.grijincu) wrote :

The http://launchpad.net/~youraccount will be removed soon (see bug #199069 for the reasons).
For the same reasons https://launchpad.net/+id/myusername is not usable.
Furthermore https://launchpad.net/+id/myusername my be the same as a automatically generated https://launchpad.net/+id/xxxxx OpenID url, so that's not usable.

Revision history for this message
Francis J. Lacoste (flacoste) wrote :

Jamesh coudln't this be fixed by allowing the nickname sreg field to all Relaying Party?

OpenID has supports to request additional information from the OpenID Provider (Launchpad). (For example, nickname, displayname, email, etc.) Currently Launchpad will give that information only to "trusted" configured relaying party. - The exact information shared is always displayed on the OpenID approval page. (Currently, for most RP, only the identiy URL is shared.)

Revision history for this message
James Henstridge (jamesh) wrote :

Francis: sending openid.sreg values to other sites is where we should aim. What we need to implement before doing that is allowing the user to select which items they wish to reveal to the RP (handing out the user's email address to every site that wants the user to authenticate would be bad).

Once that is implemented, we should remove many of the restrictions on that code.

Revision history for this message
Francis J. Lacoste (flacoste) wrote :

Jamesh, right, that's the correct fix, but do you think it's a real problem to always send the nickname? Which is an easy fix for now.

Revision history for this message
Lucian Adrian Grijincu (lucian.grijincu) wrote :

FWIW, this is how Yahoo do it:
they autogenerate an ugly unrememberable unique ID
    https://me.yahoo.com/a/Ve7giSMuverd1i.DwyyuXmYxvpiXvby2
and they let you pick (ONLY ONCE!) a more userfriendly identifier:
    https://me.yahoo.com/lucian.openid
When I tested this on blogspot it left behind lucian.openid as the user's name (I'm not familiar with OpenID naming conventions).
Btw, as you see Yahoo keeps the autogenrated IDs in a different namespace from the user's hand picked ones.

Leaving the user's nickname is not a security issues: there's a link left behind which indirectly points to launchpad.net/~nickname.
This would be a lot better than leaving the ugly autogenerated ID.

Revision history for this message
James Henstridge (jamesh) wrote :

Francis: that would probably be okay. Until we've got an appropriate UI, I'd prefer not to expose too much data about users.

Lucien: We semi-regularly get requests from people who want to use a nickname that is currently used by an inactive user (maybe someone who created an account purely to order shipit CDs or use shop.canonical.com). I doubt this is likely to decrease, and there is value in letting active Launchpad users have recognisable nicknames.

Having immutable identities is important for a number of things we're doing with OpenID single signon, which made the random identifiers the best solution.

Revision history for this message
Mantas Zimnickas (sirex) wrote :

LP nickname could be mutable until an action will be performed. That action would be OpenID authentication request and so on... So when this action will be performed, nick name becomes immutable. This solution at least solves problem with active LP users, who wants to own nickname from an inactive LP user, who probably never will use LP's OpenID feature.

Revision history for this message
James Henstridge (jamesh) wrote :

Note that you can use alternative identity URLs: just delegate your home page or blog to Launchpad as described on https://help.launchpad.net/OpenID.

Revision history for this message
Francis J. Lacoste (flacoste) wrote :

I'm marking this bug Won't fix. Unique random identifier suits our requirements regarding the trust we can put in a LP OpenID.

I opened bug 211784 about sending the launchpad nickname using the sreg to all RP. This should solve the problem on RP supporting that part of the protocol.

RP coded using OpenID best practice should also allow you to customize your accounts on their site, (and thus allow you to choose a local nickname). For other purpose, OpenID delegation is always a work-around.

Changed in launchpad:
milestone: 1.2.4 → none
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.