I like this idea. Hadn't thought about the security benefits, thanks for enumerating Nat.
On Jun 10, 2010, at 6:26 PM, Nat wrote: One more good thing: 5) We can move almost all the params into JSON. =nat @ Tokyo via iPhone On 2010/06/10, at 16:27, Nat Sakimura <sakim...@gmail.com<mailto:sakim...@gmail.com>> wrote: On Thu, Jun 10, 2010 at 8:27 AM, Dirk Balfanz <<mailto:balf...@google.com>balf...@google.com<mailto:balf...@google.com>> wrote: On Wed, Jun 9, 2010 at 4:05 PM, John Panzer <<mailto:jpan...@google.com>jpan...@google.com<mailto:jpan...@google.com>> wrote: So the thinking is that this is just a generic "include" or "one level of indirection" feature that is orthogonal to other flows? FWIW, I really like that notion. It's also very easy to describe and understand conceptually. +1 How does the Client decide to use this new level of indirection? When the User Agent looks like it wouldn't like long URLs? There are a few cases that I am aware of: 1) When the User Agent looks like it would not like long URLs. It is entirely possible that some extension makes a long URL. For example, the client might want to send a public key with the request. 2) When the server wants the request non-repudiation The server might want the request to be non-repudiable. It is possible to sign the request dynamically, but a simpler way of doing it is to make a signed request file (perhaps in Magic Signature format) and put it on the client. It can just be done by a client utility or something, so that the private key does not even have to reside on the server nor the client needs to program anything. 3) When the server wants the requests to be cacheable As I have proposed, if the request_url comes with sha256 hash of the file, the server knows if the file has changed without fetching it, so it does not have to re-fetch a same file, which is a win as well. 4) When the client wants to simplify the implementation without compromising the security If the request parameters go through the Browser, it may be tampered at the browser even if TLS was used. This implies we need to have signature on the request as well. However, if https request_url was used, it is not going to be tampered, thus we now do not have to sign the request. This simplifies the implementation. Dirk. -- John Panzer / Google <mailto:jpan...@google.com>jpan...@google.com<mailto:jpan...@google.com> / <http://www.abstractioneer.org/> abstractioneer.org<http://abstractioneer.org/> / @jpanzer On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura <<mailto:sakim...@gmail.com>sakim...@gmail.com<mailto:sakim...@gmail.com>> wrote: I fully agree on it. Instead of doing as a flow, defining request_url as one of the core variable would be better. The question then is, whether this community accepts the idea. On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H <<mailto:james.h.man...@team.telstra.com>james.h.man...@team.telstra.com<mailto:james.h.man...@team.telstra.com>> wrote: Nat, > On the other hand, you are starting to think of it as a generic "include" > mechanism, are you? Yes. That feels like the simplest mental model for this functionality, and the simplest way to specify it. -- James Manger -- Nat Sakimura (=nat) <http://www.sakimura.org/en/>http://www.sakimura.org/en/ <http://twitter.com/_nat_en>http://twitter.com/_nat_en _______________________________________________ OAuth mailing list <mailto:OAuth@ietf.org>OAuth@ietf.org<mailto:OAuth@ietf.org> <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list <mailto:OAuth@ietf.org>OAuth@ietf.org<mailto:OAuth@ietf.org> <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=nat) <http://www.sakimura.org/en/>http://www.sakimura.org/en/ <http://twitter.com/_nat_en>http://twitter.com/_nat_en <ATT00001..txt>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
