Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

I have just submit an I-D. http://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ It has extra things like Signing and Encrypting of the Request payload for some use-case stated in the introduction, but the core is the "request_url". (The draft actually is largely copy and paste of OpenID Ar

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

I'd still like to see this proposed as a new I-D. It can be very short. I will have the extensibility guidelines in the next draft or two, but you can start by just declaring a new parameter for the relevant endpoints. EHL On 6/7/10 7:53 PM, "Nat Sakimura" wrote: I fully agree on it. Instea

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

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 mailto:sakim...@gmail.com>> wro

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

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 wrote: On Thu, Jun 10, 2010 at 8:27 AM, Dirk Balfanz wrote: On Wed, Jun 9, 2010 at 4:05 PM, John Panzer wrote: So the thinking is that this is just a

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

On Thu, Jun 10, 2010 at 8:27 AM, Dirk Balfanz wrote: > > > On Wed, Jun 9, 2010 at 4:05 PM, John Panzer 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 als

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

That's right. It would help various extensions as well. On Thu, Jun 10, 2010 at 8:05 AM, John Panzer 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 e

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

On Wed, Jun 9, 2010 at 4:05 PM, John Panzer 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

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

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. -- John Panzer / Google jpan...@google.com / abstractioneer.org

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

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 ___ OAuth mailing list O

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

Ah, I am starting to getting your point. I was assuming that the text was just dealing with this particular flow, possibly a separate standalone document as David R. suggested. On the other hand, you are starting to think of it as a generic "include" mechanism, are you? I agree that would be actu

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

Nat, >>> All the request parameters MUST be provided through request file. >>"All" doesn't make much sense if params can still appear in the URI, and >>override the file. > What about this:  > > Request parameters SHOULD be provided through request file.  If it is perfectly legitimate to includ

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

James, On Mon, May 31, 2010 at 10:17 AM, Manger, James H < james.h.man...@team.telstra.com> wrote: > Nat, > > > All the request parameters MUST be provided through request file. > > "All" doesn't make much sense if params can still appear in the URI, and > override the file. > What about this:

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

Nat, > All the request parameters MUST be provided through request file. "All" doesn't make much sense if params can still appear in the URI, and override the file. > The "request_url" MUST be provided in the URL. This isn't really a "MUST", its just indicates if you are using this feature (t

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

meter. > > Allowing any parameters to be provided indirectly sounds more sensible. > > -- > James Manger > > > ---------- > From: Nat Sakimura [mailto:sakim...@gmail.com] > Sent: Thursday, 27 May 2010 9:07 PM > To: David Recordon > Cc: Manger, James H; oau

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

sday, 27 May 2010 9:07 PM To: David Recordon Cc: Manger, James H; oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow ... Client Requests Authorization type REQUIRED. The parameter value MUST be set to web_server request_url REQUIRED. Request fi

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

On 2010/05/28, at 3:12, Marius Scurtescu wrote: On Thu, May 27, 2010 at 11:06 AM, Nat Sakimura wrote: On Fri, May 28, 2010 at 2:10 AM, Marius Scurtescu > wrote: Thanks for the clarification Nat. Just curios, can't the phone client actually POST to the authz server? That would take care

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

On Thu, May 27, 2010 at 11:06 AM, Nat Sakimura wrote: > On Fri, May 28, 2010 at 2:10 AM, Marius Scurtescu > 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 mean

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

On Fri, May 28, 2010 at 2:10 AM, Marius Scurtescu 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

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

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 to

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

t;> headers. The SHALL be an HTTP or HTTPS URI, and SHOULD be the >> latter. >> >> >> [Probably need a way for a service to indicate whether or not it supports >> . Perhaps a "features=inc_uri,other" parameter in the HTTP >> WWW-Authenticate header.] &g

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

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

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

er-uri >> >> parameters in XXX format. Any parameter appearing directly in the >> user-uri >> >> SHALL override the same parameter obtained from . The >> >> >> response SHOULD be cacheable by including appropriate HTTP >> cache-control >> >> headers. Th

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

uri > >> SHALL override the same parameter obtained from . The > >> response SHOULD be cacheable by including appropriate HTTP cache-control > >> headers. The SHALL be an HTTP or HTTPS URI, and SHOULD be the > >> latter. > >> > >> > >> [P

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

The SHALL be an HTTP or HTTPS URI, and SHOULD be the >> latter. >> >> >> [Probably need a way for a service to indicate whether or not it supports >> . Perhaps a "features=inc_uri,other" parameter in the HTTP >> WWW-Authenticate header.] >> >> -- >> Ja

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

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 < james.h.man...@team.telstra.com> wrote: > David, > > > This feels exactly like the sort of thing that should be a new flow. > > Why is the siz

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

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

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

gt; -Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Nat Sakimura > Sent: Wednesday, 26 May 2010 11:58 PM > To: oauth > Subject: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow > > Back in February, I have suggested mobile web app flow t

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

not it supports . Perhaps a "features=inc_uri,other" parameter in the HTTP WWW-Authenticate header.] -- James Manger -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura Sent: Wednesday, 26 May 2010 11:58 PM To: oauth Subject: [O

Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

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, o

[OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

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