User profile pages should not be OpenID identities

Any reason we don't want to support form 2) long term?

Form 2) is for users trying to authenticate with OpenID 1.0/1.1 consumers. The major consumers are switching but there are still bugs to iron out (eg. LiveJournal). In reality, dropping this might not be too much hardship.

Because Launchpad account identities are mutable. So if I desactivate or rename my account, somebody could rename their LP account to my old name and log in using OpenID under my identity in a third party OpenID site.

Francis J. Lacoste wrote:

> Because Launchpad account identities are mutable. So if I desactivate or
> rename my account, somebody could rename their LP account to my old name
> and log in using OpenID under my identity in a third party OpenID site.

Yes. People can shoot themselves in the foot. So don't do that. Most of the
big providers recycle ids and have this edge case, and the problem has been
around in similar forms since bulletin boards and in reality not really an
issue.

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

It looks like this hasn't been addressed with the latest rollout. Given that we're planning on announcing the OP soon, this is a problem if we decide to yank these identity URLs at a later point (if they are available, then people will use them). So what's the plan here?

We need to cherry pick, removing the tags before we announce and ideally before launchpad beta testers start using them. We can enable it again later if people decide my arguments hold water at all.

The plan is not to talk about it. If people discovers that they can login on 1.1 site using https://launchpad.net/~login, then they are using an undocumented, unsupported API, and they have no reason to complain if we remove those.

On the other hand, I kind of side with Stuart on this issue. Should we go out of our way to prevent our users from doing silly things?

We did want to NOT use the login id for privacy and security best practice reasons.

Mars found a good blog post too.. http://idcorner.org/2007/08/22/the-problems-with-openid/

From a usability standpoint this is awful.
When a user wants to log in a website through OpenID he must enter a URL.
I can remember launchpad.net/~myusername or launchpad.net/+id/~my_newly_picked_identifier but I won't even try to remember https://login.launchpad.net/+id/FHrCpfF (my current ID).

You should at least allow ONE change of the auto-generated ID (as Yahoo does).

I agree, that there is possible security holes using mutable user names.

But if I will comment some where, and all people will see my OpenID as: https://login.launchpad.net/+id/T84hNrE, it will look terrible. And I thing, that this solution looks like a workaround, and definitely not like a real solution.

Better idea would be if user names becomes immutable, because, I guess, that this is really rare case if some one decides to change his user name.

Well any way, I already have an OP, and I'm going to use LP as my OP only if it will be seen to the public as: launchpad.net/~sirex, because this URL I already use in wiki.ubuntu.com, in my email signature ant so on...

I agree with Mantas. Tie launchpad handles to a single user for all time, and allow changes only under special circumstances.

I'd like to see launchpad encourage folks to build reputation in human-friendly launchpad openids, based on handles.

And yes, you'll also want to provide privacy-protecting options, since there are privacy-sensitive use cases also. But there are many many use cases (blog posts, use by loco web sites, etc) in which users and sysadmins will prefer human-friendly openids to something opaque.

There are also many reasons for wanting launchpad handles to be immutable, since they show up in many contexts already. Yes, there will be some "good" handles that eventually go unused, but the handle namespace is big and people can be creative. Yes, you'll need to prevent people from making too many changes of handle so they don't spoil good handles.

But launchpad needs to support both the public and the private use cases.

Joey, that's the same security issue list I posted last fall to bug 1169. And yes, the phishing issue can be a problem since you support specific openid 1.1-style ids. But what additional security exposure are you seeing based on the user having a human-friendly 1.1 id vs the randomly-generated one you're offering already?

One quicky idea, which solves the "who is that person" issue, allowing a portion of the URL to be human-readable:

   /~USER/+id/HASH

I think that it's very important that the URL be easy for users to remember. If it isn't, they won't use it.

I think that perhaps we can solve this by using a simple count of the number of times the username has been used. For instance, if my URL today is:

    http://launchpad.net/~ted-gould/+id

Then if I was to give up the username and someone else to get it they would have a URL of:

    http://launchapd.net/~ted-gould/+id/1

the next person:

    http://launchapd.net/~ted-gould/+id/2

And so on. This way only one, probably very short, number would have to be remembered for a user. And, in the more common case that a username is not reused, no number is required.

Kees: what happens if the user changes their nickname?

Ted: we've got a very easy identifier for users to remember: "login.launchpad.net". For any OpenID 2.0 compliant relying party (which these days is pretty much anything but Livejournal), that's all you need to enter.

Also, the proposal I made at the start of the bug would let people type their Launchpad profile page into 2.0 RPs and have things work.

Logging in as a random unmemorable string is pointless, tbh.

http://secretlondon.livejournal.com/452016.html?thread=827568#t827568

What is the use case of identifying myself as that?

We'll do this once the new identifiers are in place as described in bug 236194.

Perhaps the user profile page can delegate to the non-human readable one?

The profile pages are currently delegating to the non-human readable identity URLs. The problem is that if you log in with your profile page, then the RP records your profile page as your identity rather than the identity it delegates to.

If you change your Launchpad nickname, anyone would be able to take over accounts you'd created on remote sites logging in with your LP profile page as an OpenID.

Even when we've switched to the human readable identity URLs (which should address Caroline's concerns), this bug will still be an issue.

I have a branch that has started this work. I will take this bug.

I have a branch that fixes this.

Fix committed in RF 7139.

Fix released in Launchpad 2.1.10.

Why not use both over intervals where the two are linked and the human readable one can be changed more often, while the mutable id is changed over random intervals and updated by the USER as they log in to the sites they use.
This will allow the account's to be linked with the non human readable id and updated trough user activity at a certain interval, thus the human readable id is only needed for this update.