Comment 26 for bug 532055

Revision history for this message
Martin Pool (mbp) wrote : Re: [Bug 532055] Re: Provide a user-friendly way of authorizing desktop, GUI launchpadlib applications

On 30 March 2010 22:58, Leonard Richardson
<email address hidden> wrote:
>> That seems like a fairly extreme implementation of openid
>> compared to other web services; most will still let you use a
>> username:password if you want.
>
> The Launchpad Login service will still let you use a username:password,
> but it really has nothing to do with Launchpad--we don't administer it
> or have access to its data. Any more than, once you can log into
> Launchpad using your MySpace OpenID, we'll have access to your MySpace
> password.

Yes, obviously we don't want people proxying random passwords through Launchpad.

The case I'm describing is that other apps implement a hybrid of

A- one site-specific username paired with
B- zero or more openid urls from any provider, in which case you must
authenticate directly against that provider, plus
C- optionally a site-specific password - this may be backed by an
site-specific openid server but this is an implementation detail

The advantage of supporting C is that there are some cases such as
handhelds or text-mode servers where creating and then using a
site-specific password is in fact the best tradeoff for some users.
istm that is quite useful for Launchpad api clients compared to
manually generating and copying around tokens. identi.ca is a good
example of this approach, see https://identi.ca/main/login.

Perhaps this is just a transitional phase and eventually option C will
go out of fashion. And if this is already architecturally impossible
I don't think it's important to reinstate it.

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