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 <[email protected]> wrote:
On Thu, Jun 10, 2010 at 8:27 AM, Dirk Balfanz <[email protected]>
wrote:
On Wed, Jun 9, 2010 at 4:05 PM, John Panzer <[email protected]>
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
[email protected] / abstractioneer.org / @jpanzer
On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura <[email protected]>
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 <[email protected]
> 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://twitter.com/_nat_en
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
