Launchpad only permits user authentication via the Ubuntu single-signon OpenID server

There is no current plans to become an OpenID relaying party.

I don't think that he's asking to be a relaying party. But, it would be nice if people could file or comment on bugs by only using their OpenID account and not having to create a Launchpad account. If they don't want to create one, that shouldn't be a blocking factor to them participating in projects on Launchpad.

To be able to login using another site's OpenID, means making Launchpad implements the Relaying Party part of the protocol.

I'm changing the status because it seems that may consider implementing this in the future.

At this point, there are plenty of OpenID providers out there. We need more sites to actually use the IDs. Personally (and I'm sure I'm not alone on this), I'm more likely to just skip using a site altogether than create yet another account (where I'll probably just re-use a password anyway). Please make Launchpad and other Ubuntu sites accept OpenIDs.

I don't think that it is required to be able to log in LP using OpenID.

Rather you should be able to add comments, file bug reports, or adding suggestions to a transaltion using your OpenID.

The users who want full functionality (ex approving translations, or beeing able to be part of a group) should create a LP account.

But the other users who are not using LP intensively can use OpenID to add comment and will have a LP account similar to the ones created while importing translations from upstream.

I think that we all have OpenID providers and is the comsumers that is missing.

Adi Roiban wrote:
> I don't think that it is required to be able to log in LP using OpenID.

I, for one, would like to log into my LP account using OpenID, thus not having to remember my password from machine to machine.

I'd like to have this too, as several of our users have complained that they already have many accounts, do not wish to create another for Launchpad, and see it as somehow unbalanced that we are only a producer not a consumer.

As further information: I've been told one blocker to doing this is that Launchpad really wants to have an email address for the user, and openid does not(?) directly provide one.

Launchpad is said to need an email address because the most common beginning-user interactions are to file a bug or ask a support question. It is common for bugs to need more information from the reporter to be usefully processed; kiko asserts that it is not worth getting reports if the original reporter is uncontactable. (I agree it is much more useful if they are, but some bugs may be worth getting anyhow.)

Also, once the question or bug is answered, email lets us tell the user so, though it's possible they would notice it was changed by some other means, such as an RSS feed or simply polling the page. Some developers might not want to answer a question if they perceive an increased risk the reporter will never see the answer.

Some reporters of this bug would like to avoid giving Launchpad an address. Some don't mind giving an address but want to avoid having yet another web password.

There is a proposal to allow users to enter their email to specify their openid identity (see http://siliconflorist.com/2008/06/20/email-to-id-my-openid-is-an-email-address/).

The options then seem to be
 - allow use of openid but require the user to also provide an email address before they can do anything
 - allow accounts with no email address
 - regularly prompt the user to give an address but don't require it

I think #1 is correct. OpenID authentication has little to do with having an account or with authorization to do things. It's merely proof that you own a URL, not automatic accounts on every system that uses OpenID.

Log out of Launchpad and see the log-in screen; you're asked for a username and password if you already have an account, and an email address for when you don't. The only part that should change is whether you use a username and password or an OpenID URL.

One should create an account as normal, except for the password part.

If one authenticates an unbound OpenID URL, then that should be a signal to start the new user registration or binding of that OpenID URL to an existing account.

There are no blockers to this. It has already been discussed with higher powers, and it is just another authentication mechanism. We just have to spec and code it. This means registration screens for creating your account using OpenID for authentication instead of (or in addition to) a password, and the authentication for Launchpad itself.

Like many OpenID consumers, you will still need to enter additional metadata like your email address when you sign up if your OpenID provider does not provide it to us, and the email address will need to be validated unless we feel we can trust a particular OpenID provider (for example, validation of a yahoo.com email address provided by the yahoo.com OpenID provider would probably serve little purpose except confirming that Launchpad emails are getting past spam filters).

From the POV of integrating existing communities, OpenID is a big win, and a desired feature. We have blog and wiki components running separate pieces of software, but all capable of supporting OpenID. Using an external code and project management tool like Launchpad would be a massive advantage, but for requiring users to register with ‘yet another service’. OpenID alleviates that problem (and with major ISPs like Yahoo and AOL now acting as providers, there's no shortage of OpenIDs in circulation).

Ultimately, none of Launchpad, Github of Google Code support OpenID right now. But some indication of which one might add it first could sway a decision. Just sayin’ ;-)

Keep up the good work!

A response to Martin Pool's quote, because I want to make sure that this is clear: (Well, for as far as I understand OpenID that is...)
"As further information: I've been told one blocker to doing this is that Launchpad really wants to have an email address for the user, and openid does not(?) directly provide one."

OpenID is designed mainly for using a single *identity* for login purposes. The login is handled by the OpenID server and the server then confirms to (in this case) launchpad that the user has granted launchpad (the consumer) access.

OpenID is not meant to be a complete database of user information. If the Launchpad service wants additional information, it is free to just ask the user for this information. The only difference is that the OpenID identity is the "unique identifier" for the user instead of a site-specific username.

I would be perfectly okay with having to provide an email address for communication purposes after I have logged in for the first time with my OpenID account.

A side note:
OpenID has a mechanism that supports storing multiple 'personalities' in the OpenID account (on the server). A user of OpenID can specify which personality can be sent to the server upon successful login. And if the personality is populated with an email address, then Launchpad should be able to receive this information.
And if I remember correctly, Launchpad could just check this information during the first login and request the user to send a more detailed personality if so required. (Or ofcourse just ask for the additional information.)

Danny,

Your understanding is consistent with my own. To solve this well,
Launchpad would need to be able to accept an email address if one is
provided (and then presumably confirm it), and alternatively ask users
for one when they first authenticate using OpenID.

--
Martin <http://launchpad.net/~mbp/>

I have another interesting point to make on this bug/feature request:

Allowing Launchpad to be an OpenID consumer would also enable extra authentication methods for users of Launchpad. It is important for Launchpad to ask a user for an email, this is of course inherent in Launchpad's purpose. However, allowing the ability to login via relaying the authentication to an external site will enable users to authenticate with very secure methods (read: NOT *just* a password!).

For an example of what I'm talking about, consider one time password devices such as the Yubikey (http://yubico.com), RSA tokens, SMS text messages with secret "out of band" communication to the user, etc... This is the future and purpose of OpenID in my opinion. To authenticate users in a very secure fashion, and enable them to use this same authentication method on many sites. For Lauchpad, this would allow developers to have a really secure way to distribute and manage projects. I agree that just having an OpenID at another site should not give users an automatic account here, Lauchpad should be allowed to ask for whatever information from the user that is needed to provide them with its services (email, GPG/SSH public keys, etc...).

I've been told verbally there are some technical limitations in the openid spec (to do with getting a verified email address?) that might mean this is hard to implement. Because this is a pretty commonly requested bug it might be worth describing that here.

Another thread about this:

https://lists.ubuntu.com/archives/bazaar/2009q1/054508.html

This is now on our list for 3.0

Let me add another reason why this is important. There are large communities out there (expecially in the higher-educaiton and research space) that build federations using SAML 2.0. Although the trust and privacy expectations of SAML 2.0 and OpenID 2.0 are quite different it is relatively easy for those communities to provide SAML->OpenID provider gateways. It may well be that launchpad will become more attractive to those communities opensource efforts if the login/user provisioning process is taken out of the picture.

Let me also take the oportunity to plug http://rnd.feide.no/simplesamlphp as a candidate for your RP implementation. By using simpleSamlphp you'd get most current id technology: SAML, OpenID, InfoCard plus some lesser known ones. Its all php, opensource and dead easy to use.

This is slightly tangential to this bug but I'd like to have LP work with Yubikeys (Yubikey is mentioned above). This doesn't require LP to be a consumer but simply to store the Yubikey field and perhaps also incorporate the decryption routines already written (FOSS - http://code.google.com/p/yubico-openid-server/) by Yubico. http://yubico.com/developers/openid/

According to the blog post, this is in the works:

  http://blog.launchpad.net/cool-new-stuff/openid-from-your-launchpad-profile

Please take a minute to tell us which external authentication methods/services you want to use to log in to the identity service - create a bug for each one and tag it with openidrp and it will appear in our list. We've made a start based on existing comments. If you find someone has already created a bug for your choice, add yourself to the 'Also affects me' list.

https://bugs.launchpad.net/canonical-identity-provider/+bugs?field.tag=openidrp

Thanks

Please note: This isn't a request to bombard us with lists of all the openid providers you want to be able to log in with - this bug #210943 is for tracking the status of the identity service accepting logins from external openid providers.

someone pointed me to http://demand.openid.net/site/launchpad.net

https://dev.launchpad.net/LEP/OpenIdRoadmap describes needed steps for Launchpad to support this. We need to coordinate with ISD on how this might relate to CIP plans. (Note that the roadmap is not scheduled work.)

Stuart Metcalfe said that there had been some possibilities that CIP would be the way that this would be implemented, but that's no longer on the table. This is back to being a Launchpad bug, and https://dev.launchpad.net/LEP/OpenIdRoadmap is the description for our current thinking of how it would go forward.

I highly doubt that Launchpad is going to stop providing open IDs, so we may as well remove that part of the title.

On 8 September 2010 12:32, Josh Brown <email address hidden> wrote:
> I highly doubt that Launchpad is going to stop providing open IDs, so we
> may as well remove that part of the title.

It didn't mean "stop being a provider" it meant "as well as"; the
comments above were confused about the difference.

--
Martin

Is it so difficult to add OpenID consumer functionality? Our project is currently on SourceForge. They do offer OpenID consumer functionality. Unfortunately we have outgrown their bug tracker. We'd like to move to Launchpad, a fantastic bugtracker, but.. our contributors log in to SourceForge using all sorts of OpenID providers. The lack of OpenID consumer functionality on Launchpad is an unnecessary roadblock.

Why does the Launchpad blog [0] mention in 2008 that "we’re making Launchpad into an OpenID consumer next year" and then this bug report gets tossed around and its importance set to low?

[0] http://blog.launchpad.net/cool-new-stuff/openid-from-your-launchpad-profile#comment-20070

I'll second this. I've just had to create an account. It would have been a lot simpler if I could have used my google open auth account. Having more than 1 openID to my name seems a little contrary to the whole point of openID.

I just had the following reply today:

  http://ubuntulogy.org/interface/fonts/3077#comment-4468

  No, I won’t do that. I was trying to use Ubuntu several times and I was always founding some bugs. I was trying to send the feedback about the bugs using launchpad – but u can’t just report the bug. First, u should register, and u can’t log in using OAuth or OpenId accounts.

  I thought that this indicates that they don’t need feedback very much.

Not having OpenID and requiring yet-another-account is a more blocker towards getting feedback (one more step, one more barrier). I'll ask a fairly I hope, simple, question:

  1. Is full OpenID support blocked by politics? Or,
  2. Is full OpenID support blocked by technology/time?

I'm asking, because if it is (1) blocked on politics, then energy can be put towards that first; thus allowing the latter to happen.

At this point there is little point in running after openid since openid connect (aka 3.0) is just around the corner and will be supported by major content providers and vendors. Why is this hard?

Leif: I don't think the user minds the version number, just whether they need to create and remember yet-another-account-*and*-password.

@sladen http://openidconnect.com/about/ and
http://openidconnect.com/faq/ - its quite different.

Doing openid today would still serve our browser using clients a lot, I think.

I think they (the users) do care since there are practically speaking no (or very very few) openid producers left that have any user base to speak of. Most "social" identity providers are using something that looks like, or builds on, oauth today (eg fb and twitter). This is what openid connect will look like: a refactoring of openid (with quite a bit of semantic import from saml) on top of oauth. So don't spend another 2 years looking at openid because the industry has moved on and by the time you guys are finished there will really be no openid producers left.

@sladen as far as I know this is only blocked by time, and if someone offers an adequate patch to do it, it would be accepted. ("Patch" here may include considering and planning for deployment issues.)

@Leif I'm happy to hear the protocol is evolving. I think there's not much point choosing exactly which ones to support until someone's about to start work on it.

Have a look at pySAML2 hosted here. It contains all you need in order to support SAML2, openid, oauth, twitter, fb etc including various protocol translators. Roland is probably going to implement openid connect in that framework too sometime. There are several deployment models. I suggest you talk to the primary author (Roland Hedberg), I'm sure he'd be happy to give you some pointers.

Another situation today on #ubuntu-ensemble where Launchpad being an OpenID consumer would avoid the situation:

  <sladen> etneg: Launchpad doesn't seem to think there's anyone with that email address (I've tried subscribing it)
  <etneg> i dont have an account on launchpad, i just subscribed to the ensemble list, that was it and now to the bugs list so i can post it there
  <sladen> etneg: ahhh, no Launchpad account, that'll be why I can't subscribe you to the bug report :)
  <etneg> i'll need a launchpad account to post to the bugs report?

The OpenID principle is that the user has a single server and a single password.
If each site restricts OpenID to its own server, that's not OpenID.

OpenID is not incompatible with additional subscription data for the most implicated users.
The goal is to login everywhere with the same ID without having to use 200 passwords.

It would be nice for Launchpad, and also the wikies, to promote OpenID.

Sign in to Launchpad.

This is the Launchpad login service utilizing OpenID technology. This site allows you to use your Launchpad account to log into OpenID-enabled sites around the Internet.

That Launchpad Login banner really seems to confuse client (consumer) and server.
(Isn't exploring the Web with Microsoft Internet Explorer enough? ;-) )

login.launchpad.net is an OpenID provider that can be used to log into any open OpenID consumer. launchpad.net itself is an OpenID consumer that presently only accepts the login.launchpad.net provider.

An OpenID "consumer" that only accepts itself as a provider is NOT an OpenID consumer in any useful sense. The absolute best description of such a scenario is that it was done as part of a transition process to using OpenID and the transition isn't complete. I came to launchpad to report a bug in a product, not to trust that you'll take good care of the password that you demand I provide.

This bug has been reported over four years ago now. I think that restricting logins to just one provider (login.launchpad.net) basically just kills the idea of OpenID. OpenID was ment to reduce the amount of logins needed to a low as possible. Launchpad is doing a very good job on making that "low" one higher than it would be if Launchpad would allow third-party (or even second-party) OpenID providers. Now, seriously Launchpad developers, are you going to do something about this soon, someday or never?