On Fri, May 28, 2010 at 2:10 AM, Marius Scurtescu <[email protected]> wrote: > Thanks for the clarification Nat. > > Just curios, can't the phone client actually POST to the authz server? > That would take care of the URL length limitation.
POST means an extra click, which is a UI disaster. Also, more data over the air means slower response. > > In your diagram, the verification code is passed from UA to Web Client > and then the Web Client is exchanging it for the access and refresh > tokens. These tokens are never passed back to the UA, is that > intended? Also, why can't the UA do the exchange directly? It is following the Web Server flow. Apart from getting the request parameter through the request_url fetch is almost exactly as in the Web Server flow. You could conceive similar things to UA-flow, I suppose. > > Marius > > > > On Wed, May 26, 2010 at 6:11 PM, Nat Sakimura <[email protected]> wrote: >> Yes. It is mainly for something called "feature phones" that has over >> 90% share in Japan. >> >> If it is the core OAuth only, it is not much of the problem. >> However, when we start adding something like Identity Layer on top of it, >> it starts to get problematic. >> >> The web client usually lives on external web server. >> >> Here are some answers to the question I got to the blog page from >> Luke, so that we can share them here as well. >> >> Q. Why "immediate" in the request? >> >> Initially, I was thinking like you did. Then, I got feedback from the >> community that if "immediate" was denied at the Authz Server, the RP >> may want to redo it with "immediate"=false, thus overriding what was >> written in the request file instead of making two versions of the >> request file. It is an override mechanism. >> >> Q. Why not "type" in the request? >> >> I could certainly include it in the request. Only the reason I did not >> was that it was already written in the request file, and it is not >> going to change like "immediate". The concern about having "type" in >> the request instead of request file is that it is easy to tamper. >> Since "type" is also used as some kind of security measure, it might >> be better to protect it if it is easy to do, and that was another >> reason for putting type in the request file and not request. >> >> Q. Name "rurl" confusing >> >> Originally, "rurl" was called "rpfurl" for Request Parameter File URL. >> Then, Breno told me that it is "mouthful" and since then it was >> wanting a better name. "rurl" was my attempt to make it not mouthful. >> Certainly, I can make it "request_url". >> >> >> On Thu, May 27, 2010 at 2:54 AM, Marius Scurtescu <[email protected]> >> wrote: >>> Hi Nat, >>> >>> The main use case for this flow would be for mobile apps that cannot >>> handle long URLs, is that correct? If so, I assume that the only >>> problematic long URL is the initial request sent through the >>> user-agent to the authorization server, right? >>> >>> Does the Web Client run on the phone as well, or on some external web >>> server? >>> >>> Marius >>> >>> >>> >>> On Wed, May 26, 2010 at 6:57 AM, Nat Sakimura <[email protected]> wrote: >>>> Back in February, I have suggested mobile web app flow to the oauth_wrap >>>> group. >>>> Now that it is wrapped into OAuth 2.0, here is my another try, this >>>> time for OAuth 2.0 draft. >>>> >>>> "OAuth 2.0 Mobile WebApp Flow" >>>> http://www.sakimura.org/en/modules/wordpress/oauth-20-mobile-webapp-flow/ >>>> >>>> I really wish that this could be included in OAuth 2.0 as it will help >>>> build identity layers on OAuth 2.0 that works for mobile web browsers etc. >>>> >>>> -- >>>> 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 >>>> >>> >> >> >> >> -- >> Nat Sakimura (=nat) >> http://www.sakimura.org/en/ >> http://twitter.com/_nat_en >> > -- 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
