Re: [oauth] "Fixing OAuth" blog post

I think we're seeing this sort of push back in the context of Twitter
API community for several reasons.

1.  The developers which have been successful are naturally
comfortable, and change is painful.
2.  The security concerns around rogue access to your Twitter account
are *comparatively* minor.
3.  There isn't much in the way of a meaningful gradient of access for
Twitter, though even allowing a differentiation of read/write access
is going to be a huge win for the community (if not particularly
exciting to developers of Twitter clients, like atebit)

Additionally its natural for API consumers to tend to think in terms
of convenience, with possible concessions to the issue of rogue
operators, where the real challenges for an API provider are control,
predictability, and bumbling/misguided operators.

I think the disaster of the delegated auth as a viable user experience
as rather spectacularly failed to prove itself in the field.  Which is
not to say the experience can't and shouldn't be improved as the
nature of our devices shift, and it was with an eye to flexibility and
allowing that kind of improvement to emerge that we struggled to keep
the core spec simple.

-kellan

On Thu, Feb 19, 2009 at 4:59 PM, Lisa Dusseault
<lisa.dusseault@gmail.com> wrote:
>
> From http://blog.atebits.com/2009/02/fixing-oauth/
>
>  ... a few years from now when OAuth is finally integrated sensibly, I think
> it actually will be quite nice.  "Integrated sensibly" is key. Today is an
> opportunity to get it right.
> [...]
>
> I think the ultimate goal is to have a single, global, native-looking,
> "blessed" authentication gateway on every device. This gateway could be
> expressed on different devices in different ways. On the iPhone for example,
> it could be represented as a special OS-provided window (running in a
> protected process) that slid up over an app, allowing the user to enter a
> password (or authenticate via something else like OpenID). The sheet would
> then slide back down revealing the app after authentication was complete.
> The requesting app would never need to quit. There would be no need for any
> web pages, and the authentication experience would be completely
> standardized across every app on that device that used OAuth.
>
> _______________________________________________
> oauth mailing list
> oauth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>