On Mon, May 4, 2009 at 9:40 AM, Eran Hammer-Lahav <[email protected]> wrote: > 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
I think there should be a 6th charter item: allow consumers to support both the broken and the fixed protocols. As it happens most of the solutions being discussed do allow that, so that won't cause new problems. I just want to make sure that we keep consumers in mind as we work on this. > - 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. This will require additional documentation updates at every service provider and more fiddling for consumers. I know that it seems like a simple solution, but appearances are deceiving. Requiring new URLs will be fairly painful and will slow deployment. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
