Jim, Thanks for the broad summary, I fully agree with you. There should be some mechanism for mobile devices with less resources for OAuth.
Regarding the source parameter of the Application, it is very important with regards of e-marketing of the application itself. Greetings! On Sep 5, 2:08 am, "Jim Renkel" <james.ren...@gmail.com> wrote: > OAuth is great, in certain circumstances. In others, it's not so great. > > Circumstances for which it is great include: > - consumer web sites; and > - consumer client applications that have access to a reasonable > browser on > the client device > in both cases with the qualification that the authorization pages of the > service provider are in a language (e.g., English, Japanese, etc.) that > is the same as that used by the consumer. > > In these circumstances, OAuth as defined by the specifications and > implemented by twitter works very well. > > Circumstances for which it is not so great include: > - consumer client applications that do not have access to a reasonable > browser on the client device; and > - consumer client applications and web sites that are in languages for > which service authorization pages in those languages are not > available. > > In these circumstances, OAuth as defined by the specifications and > implemented by twitter does not work so well. > > Currently, in circumstances where OAuth does not work very well, twitter > client applications and web-sites can resort to Basic Authentication. > > The drawbacks to this are obvious: > - the user must give their twitter password to the client; > - at some point twitter will no longer support Basic Authentication; > and > - the source of tweets created by these clients is "API" rather than > the > client's name. > > Pooh pooh the last drawback if you will, but to some it is important. > > Now, the fact of the matter is that some users are perfectly comfortable > in giving their twitter passwords to client applications and web-sites, > even where those clients support OAuth. > > I don't think these users should be penalized and forced to use OAuth > if'n and when'n twitter drops support for Basic Authentication. > > And if'n and when'n twitter drops support for Basic Authentication, > client applications and web-sites that now only support Basic > Authentication will be forced to support OAuth. Myself, I don't think > that's an unreasonable requirement, but others may differ. > > And I don't think these creators should have to forgo having their > client's name as the source of tweets their clients create, now or ever, > just because their users chose to trust them to use Basic > Authentication. > > So I propose the following enhancement to twitter's OAuth > implementation: > > Allow a userID and password to be included as optional parameters of an > oauth/access_token request. If supplied and authentic, they would cause > a valid access token to be returned without the user having visited the > authorize URL and approved the access. > > Alternately, the userID and password could be optional on an > oauth/request_token request, in which case, if supplied and authentic, > the request would return a valid access token, rather than a request > token, again without the user having visited the authorize URL and > approved the access. The advantage to this alternative is it reduces by > one the number of API calls needed. > > I believe either of these alternatives is a viable solution for the > circumstances where the existing OAuth implementation does not work so > great. > > Comments expected and welcome. > > Jim Renkel > > -----Original Message----- > From: twitter-development-talk@googlegroups.com > > [mailto:twitter-development-t...@googlegroups.com] On Behalf Of > twittme_mobi > Sent: Friday, September 04, 2009 08:39 > To: Twitter Development Talk > Subject: [twitter-dev] Re: Mobile oAuth > > I am also interested in mobile oath solution. > twitter guys should think of something before deprecating basic auth > > On Aug 20, 8:01 am, Cameron Kaiser <spec...@floodgap.com> wrote: > > > I have a mobile based twitter client in the field and have > implemented > > > oAuth for this client. Some of the devices are either very low > memory > > > or have primitive browsers that dont support the rendering of the > > > 'allow' / 'deny' access page (http://twitter.com/oauth/authorize). I > > > have tried the obvioushttp://m.twitter.com/oauth/authorizebutthis > > > seems to serve the same standard webage. > > > > So Im looking for nat previous info or plans of a lightweight > > > implementation of oAuth access page for twitter. > > > I'm also particularly interested in such a page, especially one a text > > browser could access such as Lynx or w3m. > > > -- > > ------------------------------------ > personal:http://www.cameronkaiser.com/-- > > Cameron Kaiser * Floodgap Systems *www.floodgap.com* > ckai...@floodgap.com > > -- Adore, v.: To venerate expectantly. -- Ambrose Bierce > ----------------------
