I am really not sure what point you are trying to make. Last I checked, you made the point that you need a new wire version because you are not going to support *any* oauth_callback parameter and wanted to make sure your clients do not need to use a parameter (empty or otherwise) that you are simply going to ignore to indicate they are using the fixed flow. Your entire argument for changing the wire version was that you are not going to support the one artifact servers can use to detect which flow is being used.
As a solution, I offered that you simply create a new set of OAuth authorization endpoints for the fixed flow and tell all your clients to transition to that set which will require the use of the verification code. I do not recall what was the temporary fix you opted to use for your current clients. Can you share with the group how you plan to transition your service to the new flow? How are you going to handle existing clients? This is important because I strongly believe the proposal we have on the table fully addresses all your needs. If it doesn't, we need to know why. And my point about braking shit that isn't broken was not about big companies. That was just a good example of complex deployment that will break for no reason. The benefit of my proposal is to you, to large providers, and to small provides, because that you don't need to touch any other endpoint you have, only the 3 OAuth ones. The rest will all continue to work AS-IS. It also means none of your *API developers* will need to make any changes, other they to how they obtain authorization. So your comment about large corporations and their fancy resources is actually irrelevant because my proposal is serving the interest of the really little guys - the API developers - equally well. They don't have to go and change the entire way they use OAuth-protected APIs, just how they get Access Tokens. I think that's a big deal. EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of David Parry > Sent: Friday, May 01, 2009 7:44 PM > To: OAuth > Subject: [oauth] Re: Version Preference > > > Large corporations like Google and Yahoo have more resources at their > disposal, so it's all relative. > > On May 2, 12:08 pm, Eran Hammer-Lahav <[email protected]> wrote: > > No. I'm trying not to break areas of the spec that are unaffected by > the security hole, provide tools to close the hole, and do it in a way > that allows providers who choose to, to offer a migration path to their > developers that is not just shutting down their existing old-flow OAuth > endpoints. > > > > When you consider the fact that the authorization flow is merely 3 > endpoints out of potentially tens or hundreds of API endpoints, the > deployment impact on the server is much greater on the API side than on > the OAuth authorization side. This might not be an issue to small > providers where the entire API is managed by a single server/codebase, > but for large provider such as Yahoo! and Google with a huge > distributed deployment, this is a real impact. Add to that OpenSocial > which uses 2-legged, the size of secure and unbroken deployment that a > new wire version will break for no gain at all is significant. > > > > EHL > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On > Behalf > > > Of David Parry > > > Sent: Friday, May 01, 2009 6:51 PM > > > To: OAuth > > > Subject: [oauth] Re: Version Preference > > > > > You're trying to maximize interoperability between the new and > flawed > > > spec. > > > > > ie. > > > > > SP 1.0 <-> Consumer 1.0a > > > > > SP 1.0a <-> Consumer 1.0 > > > > > On May 2, 11:22 am, Eran Hammer-Lahav <[email protected]> wrote: > > > > I have no idea what point you are trying to make. Specifications > are > > > about interoperability (what else would it be about?). > > > > > > EHL > > > > > > > -----Original Message----- > > > > > From: [email protected] [mailto:[email protected]] On > > > Behalf > > > > > Of David Parry > > > > > Sent: Friday, May 01, 2009 5:57 PM > > > > > To: OAuth > > > > > Subject: [oauth] Re: Version Preference > > > > > > > Let's play devils advocate for a minute, considering the > current > > > > > exploit was in plain view for over a year before it was found. > > > > > > > Are you willing to bet OAuth's reputation (in sake of > > > > > interoperability) that no flaws exist in this "trapdoor" switch > ? > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
