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

From: Nat Sakimura <[email-masked]>
Date: Fri, 4 Jun 2010 12:12:34 +0900

James,

On Mon, May 31, 2010 at 10:17 AM, Manger, James H <
[email-masked]> 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:

Request parameters SHOULD be provided through request 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 (this "flow").
>

It is a MUST. Without it, you just cannot obtain other required parameters.

>
> Would be good to say "A request_url param MUST NOT be provided in a request
> file". Probably good to add "A request file MUST be rejected if it includes
> a request_url param".
>

request_url param MAY be provided in a request file. It is just its
identifier. It probably is best to be there.

>
> > I am still not sure if "type" MUST be provided in the URL.
> > Conceptually, it need not be there. It depends on how implementors feel.
>
> > Any other parameters MAY be provided in the URL to override what is in
> the request_file,
>
> I agree.
>
> > but the URL total length MUST NOT exceed 512 bytes.
>
> That is reasonable.
>
> --
> James Manger
>

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 4 Jun 2010 17:21:10 +1000

Nat,

>>"All" doesn't make much sense if params can still appear in the URI, and override the file.

> Request parameters SHOULD be provided through request file. 

If it is perfectly legitimate to include some params in the user-url, and those override the same params in the file, then there is no point requiring the overridden params to be present in the file with a MUST or even a SHOULD. What about saying:
"A shorter user-uri is more likely to avoid mobile browser URI length limits, and to reduce bandwidth and latency for mobile traffic. Consequently, as many parameters as practical should be provided through the request file, instead of directly in the user-uri."

>> This isn't really a "MUST", its just indicates if you are using this feature (this "flow").

> It is a MUST. Without it, you just cannot obtain other required parameters. 

Without it you are using "normal" OAuth2 (all the params in the user-uri), which is fine and shouldn't violate a MUST.
If this mechanism is defined in a separate spec then I guess it could be a MUST for that spec. Even in that case, though, servers that support request_url shouldn't reject interactions with all the params directly in the user-uri.

>> Would be good to say "A request_url param MUST NOT be provided in a request file". Probably good to add "A request file MUST be rejected if it includes a request_url param".

> request_url param MAY be provided in a request file. It is just its identifier. It probably is best to be there. 

It sounds like you are assuming the request_url in the file is the same as the request_url in user-uri that led to the file. The server treats request_url in user-uri as a trigger to include more params, but the server treats request_url in the file as merely a name for the file (which it ignores because there is nothing for the server to do with such a name).

This is inconsistent.

request_url should be an include mechanism, regardless of where it appears. If we only want to support an include mechanism in user-uri, and not supported nested includes, then we should explicitly say request_url MUST NOT appear in a file.

--
James Manger

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 7 Jun 2010 21:55:16 +0900

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 actually quite useful.

If the idea gets support in the community I am all for it.

=nat

On Fri, Jun 4, 2010 at 4:21 PM, Manger, James H <
[email-masked]> wrote:

> If it is perfectly legitimate to include some params in the user-url, and
> those override the same params in the file, then there is no point requiring
> the overridden params to be present in the file with a MUST or even a
> SHOULD. What about saying:
> "A shorter user-uri is more likely to avoid mobile browser URI length
> limits, and to reduce bandwidth and latency for mobile traffic.
> Consequently, as many parameters as practical should be provided through the
> request file, instead of directly in the user-uri."
>
>
>
> Without it you are using "normal" OAuth2 (all the params in the user-uri),
> which is fine and shouldn't violate a MUST.
> If this mechanism is defined in a separate spec then I guess it could be a
> MUST for that spec. Even in that case, though, servers that support
> request_url shouldn't reject interactions with all the params directly in
> the user-uri.
>
>
>
> >> Would be good to say "A request_url param MUST NOT be provided in a
> request file". Probably good to add "A request file MUST be rejected if it
> includes a request_url param".
>
> It sounds like you are assuming the request_url in the file is the same as
> the request_url in user-uri that led to the file. The server treats
> request_url in user-uri as a trigger to include more params, but the server
> treats request_url in the file as merely a name for the file (which it
> ignores because there is nothing for the server to do with such a name).
>
> This is inconsistent.
>
> request_url should be an include mechanism, regardless of where it appears.
> If we only want to support an include mechanism in user-uri, and not
> supported nested includes, then we should explicitly say request_url MUST
> NOT appear in a file.
>
> --
> James Manger
>