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.
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? 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 > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
