Not trying to play down your use case but I think this would be limited to 
Shindig (and OpenSocial implementations).

So your idea is for the client to always try 1.0a first, and if the server 
returns an error or does not acknowledge the callback parameter, to fallback to 
1.0?

EHL

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Brian Eaton
> Sent: Wednesday, May 06, 2009 8:50 AM
> To: [email protected]
> Subject: [oauth] Re: OAuth Core 1.0 Rev A, Draft 2
> 
> 
> On Tue, May 5, 2009 at 10:43 PM, Eran Hammer-Lahav
> <[email protected]> wrote:
> > This seems to suggest the client needs a way to detect which version
> the server
> > is using. How about check the documentation? We don't have discovery
> yet which
> > is going to solve the flow versioning problem. I am not sure what use
> case you
> > are trying to solve.
> 
> Use case is consumers and service providers trying to transition to
> OAuth 1.0a in parallel without creating down time or needing to "all
> hold hands and jump together".  Reading documentation is not an option
> for that.  "Discovery" in the sense of downloading a bunch of
> information about a service provider is massive overkill.  We just
> need a way to detect that both consumer and SP support callback
> tokens.
> 
> My specific concern is around the OAuth consumer implementation in
> Shindig.  It hides details of the OAuth protocol from clients, which
> people have appreciated.  (Supporting problem reporting and session
> extension have been completely transparent to application code, for
> example.)  I'd like to continue to do that with the transition from
> OAuth 1.0 to 1.0a.
> 
> However, existing clients have hardcoded callback URLs on their
> approval URLs.  If the consumer code can detect that the service
> provider supports OAuth 1.0a, it can automatically correct that
> problem by stripping the callback URL off the approval URL.  If the
> consumer code can't detect service provider version, then we're going
> to end up in situations where different callback URLs are sent on both
> the request token step and the approval step.
> 
> It won't surprise me in the least if that breaks service providers.
> It looks exactly like an attack.
> 
> 

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to