> 1. The ability to encode the request token and secret into the callback > for client statelessness was not part of the protocol design. It is a nice > side-effect at best.
There have been lots and lots of discussions about scalability and stateless operation in OAuth. It has mostly been about enabling the SP to be stateless, but that reflects that it is mostly SPs writing the spec. Even today Dirk Balfanz has been suggesting re-wording of the current fix proposal so ensure stateless operation is explicitly supported. 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. > In fact, the callback used to be in the request token step, but moved to > the authorization step only because some were concerned about forcing the > server to maintain extra state. 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? > 2. The new requirement to reconstruct the callback URI is going to be as > complicated for people as constructing the signature base string... The proposal requires 1 party (the consumer) to construct its own URI (callback) twice. This is very different from getting two separate parties (consumer & service provider) to construct the same signature base string using a complicated formula from a spec involving a variety of fields from various places. The consumer recreating their own callback URI will be vastly vastly simpler. I find this a very unconvincing reason. > 3. From a security review perspective, this is an even greater departure > from well known protocols in the space. While I have no attacks in mind, I > would not be comfortable promoting this solution in the same timeframe for > the current proposal. It is pretty hard to judge how great a departure a protocol is. It does not seem like a great departure to me. It certainly seems like less of a departure from OAuth 1.0 than callback-with-request-token. 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. I share your concern about time for a security review. However, that concern applies to all the proposals. James Manger [email protected] Identity and security team — Chief Technology Office — Telstra --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
