That is the main reason I am pushing forward, but there are other reasons as well.
For example, if the device is sitting on a slow network, it would be much faster and thus user friendly if we move bulk of the payload server to server. Another example of the merit is that when something like user identifiers are to be sent to the end_user_endpoint, then it would be much better to do it server to server than through the browser, which is a default man-in-the-middle. Implementation is going to be simpler as well. Since the request travels server to server over SSL, it does not have to be signed to avoid tampering. When these parameters are sent over browser redirect, they can be tampered. To avoid the tampering, you need to sign the request, which is a big headache. =nat On Thu, May 27, 2010 at 1:23 PM, David Recordon <[email protected]> wrote: > Isn't the capability that distinguishes this flow the fact that URLs can not > be more than ~500 bytes? > > On Wed, May 26, 2010 at 10:13 PM, Manger, James H > <[email protected]> wrote: >> >> David, >> >> > This feels exactly like the sort of thing that should be a new flow. >> >> Why is the size of the parameters related to the fundamental capabilities >> that distinguish flows (can/can't launch browser; can/can't receive >> redirects; can/can't keep client secret; is/isn't registered; with/without a >> user)? >> >> Its not that some devices have URI limits and other don't. Its just that >> the size of the limits varies, which make the issue more pressing for >> selected mobile phones first. Perhaps there is no chance the ~2KB URI limit >> in IE will ever be exceeded -- but things like PAPE in OpenID strained >> similar assumptions there. >> >> I guess I am just uncomfortable with the repetition between the flows. >> >> -- >> 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
