Re: [OAUTH-WG] OAuth 1 Bridge Flow

2010-05-04 Thread Allen Tom
Although we have not formally announced any plans to support OAuth2 yet, I would expect that Yahoo would be able to simultaneously support both Oauth 1.0a and OAuth2 without requiring clients to upgrade their existing Oauth 1.0a credentials for OAuth2. Note: Yahoo currently requires the Session Ex

Re: [OAUTH-WG] Refresh tokens security enhancement

2010-05-04 Thread Marius Scurtescu
On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt wrote: > Am 03.05.2010 18:55, schrieb Allen Tom: >> Invalidating the Refresh Token (and presumably also invalidating any >> outstanding Access Tokens) would make sense as an option for applications >> that require a high level of security. Howev

Re: [OAUTH-WG] OAuth 1 Bridge Flow

2010-05-04 Thread Justin Richer
Interesting work. So as each app upgrades its support from OAuth1 to OAuth2, it exchanges its old tokens for new ones once for each user, right? Then the app in question is effectively going to have to speak both flavors of OAuth to do this one-time upgrade. I always assumed that apps would just ha

[OAUTH-WG] explicit request for refresh token

2010-05-04 Thread Marius Scurtescu
Currently all flows return an optional refresh token and I think it was mentioned that the Autonomous Client flows should never return a refresh token. While a refresh token will probably be used in most cases by the other flows, in some cases the refresh token will be just ignored by the client.

Re: [OAUTH-WG] Refresh tokens security enhancement

2010-05-04 Thread Torsten Lodderstedt
Hi Allen, Am 03.05.2010 18:55, schrieb Allen Tom: Hi Torsten, Thanks for posting this idea - I think that issuing a new Refresh Token (and invalidating the old one) on every refresh request would help detect token theft. HOWEVER - in practice, this mechanism could make implementations very tri

Re: [OAUTH-WG] OAuth 1 Bridge Flow

2010-05-04 Thread Marius Scurtescu
On Tue, May 4, 2010 at 11:03 AM, Luke Shepard wrote: > That's a good idea. > > FWIW we created a custom endpoint for this purpose - allows you to exchange > Facebook sessions for OAuth 2.0 tokens. Documented here: > http://developers.facebook.com/docs/guides/upgrade Thanks for the pointer. Are

Re: [OAUTH-WG] OAuth 1 Bridge Flow

2010-05-04 Thread Marius Scurtescu
On Tue, May 4, 2010 at 10:48 AM, Eran Hammer-Lahav wrote: > Why a short lived 2.0 token? Why not provide an endpoint to exchange a 1.0 > token with a 2.0 token with a refresh token? Yes, we thought about this use case but wasn't sure about the right implementation. If an OAuth 2.0 refresh token

Re: [OAUTH-WG] OAuth 1 Bridge Flow

2010-05-04 Thread Luke Shepard
That's a good idea. FWIW we created a custom endpoint for this purpose - allows you to exchange Facebook sessions for OAuth 2.0 tokens. Documented here: http://developers.facebook.com/docs/guides/upgrade On May 4, 2010, at 10:48 AM, Eran Hammer-Lahav wrote: > Why a short lived 2.0 token? Why n

Re: [OAUTH-WG] OAuth 1 Bridge Flow

2010-05-04 Thread Eran Hammer-Lahav
Why a short lived 2.0 token? Why not provide an endpoint to exchange a 1.0 token with a 2.0 token with a refresh token? EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Tuesday, May 04, 2010 10:27 AM > To: OAu

Re: [OAUTH-WG] Scope - Coming to a Consensus

2010-05-04 Thread Mark Mcgloin
+1 to option 3 I think the suggestion below from Torsten makes great sense, especially in relation to standardized apis such as mail Mark On 01 May 2010, at 13:36 PM, Eve Maier wrote: > Am 01.05.2010 03:07, schrieb Marius Scurtescu: >> On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt >