[OSM-dev] The future of Potlatch

[Frederik Ramm]

Hi,

> Well I assume the client app would make a request to /api/0.5/user/token
> or something with noraml username+password HTTP authentication and get a
> token back that it could then use from then on.
> 
> Though of course if the client app is doing it then it could just use
> the HTTP auth with username+password anyway.

Yes, that's the problem. What we want is really something where the
user's password is never given to anyone but the trusted site.

I haven't looked at OAuth but I don't need to; these things are
basically all the same. The simple methods do everything in a two-step
process (redirect there, redirect back, involving signed tokens), the
more complex methods require the client to talk to the API first,
basically initiating a transaction ("I'm about to send someone to
you") and retrieving a transaction id, then they do the two-step
redirect with only the transaction id as payload, then they request
the transaction result from the API ("the user I just sent to you, who
was that an can I have a trusted token").

Whenever you talk about these things, OpenID comes up but as crschmidt
has pointed out, OpenID is something different. 

I don't care whether we use OAuth or a homebrew thing, it's a few
lines of code only either way and we don't intend to do banking
transactions. From pure "number of lines of code" impression, OAuth
seems to do more than we need but hey... as long as that wouldn't
force those who cannot use ready-made OAuth modules to implement all
sorts of unneeded stuff just to be compliant, I couldn't care less.

Bye
Frederik

--
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"