> From: [email protected] [mailto:[email protected]] On Behalf > Of Brian Eaton > Sent: Tuesday, May 05, 2009 4:20 PM
> Section 6.2: > > Consumers that need to maintain compatibility with both 1.0 and 1.0a > service providers are going to send oauth_callback on this step. We > should be explicit about how to handle backwards compatibility here or > we are going to end up with incompatible implementations. > Specifically: > - if the consumer sent the oauth_callback on the RT step, the > oauth_callback on the authorization URL should be ignored. > - if the consumer did not send the oauth_callback on the RT step, > the oauth_callback may be accepted if the SP wants to be compatible > with OAuth 1.0 > > Alternatively, we should give consumers a way to detect SP version, by > having the SP return oauth_callback_accepted=1 in the request token > response. I think this might be a better answer. I am not sure what the issue here is. I understand the need for servers to detect what version a client is using because they might want to support old flow clients for some time on the same endpoints. I think servers can figure out how to implement this without any help from the spec which is why I don't think we need a transition section or what's new. 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. > 6.2.3 > > "non-guessable" should be "unguessable" Is it a word? > Appendix A.2: this does not demonstrate how to avoid an XSRF attack on > the callback URL. Maybe add "&xsrf=<some-gibberish>" here? It shouldn't. XSRF should be addressed in a security consideration section (which will be added in the next draft), not in the protocol example. EHL --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
