> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Manger, James H > Sent: Wednesday, May 06, 2009 12:23 AM
> Scalability of consumers should have been part of the protocol design, > even if only implicitly, because scalability is a general concern. > Tokens and callbacks are the vehicles that OAuth offers to encode > state. Other options might be helpful in some situations, but OAuth > Core should not add a new dependence on them unless absolutely > necessary. Should have been but it wasn't. You are elevating a side-effect into a protocol design. > Isn't the existence of explicit concerns that will be overridden by > callback-with-request-token a good reason to try a different approach, > such as callback-with-access-token? No. The existence of running code would. > The consumer recreating their own callback URI will be vastly vastly > simpler. I find this a very unconvincing reason. How much OAuth support have you done and how many frustrated client developers did you help? This is a real problem. And the more a client needs to scale, the more complex its deployment will be. Multiple hosts, ports, etc. will be part of what it will have to deal with. They still need to fetch all the parameters, sort them, make sure they are encoded correctly (note, there are many ways to encode URIs and there is no way of knowing how the server chose to do so), find the right host and port (there could be many), etc. While I share your definition of 'simpler', it is not grounded in reality. This is unfortunate but feedback from developers still shows most people already find OAuth really really hard. > The callback-with-request-token and callback-with-access-token > proposals are quite close as far as fixing the security hole is > concerned. Both use an unguessable verifier from the authorization > step. Both prevent an attacker from modifying the callback: one by not > sending it to the attacker; the other by checking it isn't changed. > That is a difference; it requires careful thought; it is not a great > departure. The approach you take in securing the callback is very new. Signing the callback parameter is not (it is for OAuth but not other protocol in the space). Can you point to other protocols that use this approach? > I share your concern about time for a security review. However, that > concern applies to all the proposals. The current proposal has been reviewed for almost 3 weeks. We are basically done, tweaking the language and waiting for people to start implement to get more feedback. There are other solutions that we did not consider because they are too big to get done within the timeframe we defined for a new final spec (3-5 weeks). I'm not asking you to give up on this, just to move this discussion to where it belongs - in the IETF work. For me to consider your proposal now, you need to show me how it will impact client developers *today*. I will need to hear from them to buy into the statelessness requirements. 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 -~----------~----~----~----~------~----~------~--~---
