One way around the issue of incrementing oauth_version is for the SP to see it as a "minimum required version for this endpoint" rather than enforcing one version requirement across all endpoints. By allowing for different minimum required versions for each endpoints, we can maintain backward compatibility while still being able to increment the oauth_version. The SP can decide which oauth version to support for each endpoint. For the session fixation fix SPs can continue allowing 1.0 versions on resource requests since we are not chaging this part of the spec. Two legged consumers would not be broken and the SP can tell which flow is being used when it might not be obvious.
I was going suggest this in a seperate thread, but since this idea is blocked on this issue, I thought it would be relevent to suggest here. On Tue, May 5, 2009 at 9:29 PM, Breno de Medeiros <[email protected]> wrote: > Good point. This alternate solution is less backward compatible. > > On May 5, 2009 7:15 PM, "Josh Roesslein" <[email protected]> wrote: > > One issue that arises is now the SP has no way to tell if we are using 1.0 > old flow or the new flow.The SP will not know which one is being used until > the consumer asks for the access token. So how will we know if the callback > should use the old flow's format or the new flow w/ verifier? > > We would either have to increment the wire version OR the SP would have to > use different end points for the two flows. > > example: http://www.test.com/oauth/1.0a OR 1.0/request > > On Tue, May 5, 2009 at 9:06 PM, Manger, James H < > [email protected]> wrote: > > [I sa... > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
