I think we are stuck in this debate over the wire version because we do not have a well defined scope for this effort. While this has been obvious to me, it might not be obvious to others.
The charter for this work is: 1. Fully address the security hole identified in the OAuth Core 1.0 specification 2. Provide a solution in the form of a new specification in a short period of time (2-4 weeks) 3. Narrowly address the security hole without attempting to improve or change anything else 4. Allow servers to support the broken and fixed protocols 5. Provide a solution that requires the least amount of changes to existing deployed code --- We have identified two possible solutions: - Add a verification code and sign the callback parameter (signed callbacks) - Simplify the authorization flow by combining the first two steps (signed authorization request) We have reached wide consensus that the best approach is the first, signed callbacks. --- Our charter includes a requirement for servers to be able to support both revisions which means they need a way to tell which flow they client is using. We have three options for identifying the flow used: - oauth_callback always required in the Request Token step to allow servers to know which flow the client is using. To support manual verification code entry or no verification code at all, we will use magic values (like 'oob' and 'none'). - Servers use a different set of authorization endpoint (just the 3 OAuth endpoints, not any other API), or use a flag during the client registration (indicating which version they use) to know which flow is being used. - The oauth_version parameter value is changed to indicate which version is being used. The first two options *clearly* match charter requirement #5 better than the third option. The first two options affect only the *3* OAuth endpoints, while the third affects *all* OAuth-protected endpoints. We still need to pick one from the first two options. --- Those advocating other solutions or the need to address the meaning of the wire version, etc. will have plenty of opportunity to do so shortly in the IETF. EHL --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
