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

From: "Manger, James H" <[email-masked]>
Date: Mon, 7 Jun 2010 23:51:54 +1000

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

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 8 Jun 2010 11:53:34 +0900

I fully agree on it.

Instead of doing as a flow, defining request_url as one of the core variable
would be better.
The question then is, whether this community accepts the idea.

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

---

From: John Panzer <[email-masked]>
Date: Wed, 9 Jun 2010 16:05:10 -0700

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
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura <[email-masked]> wrote:

> I fully agree on it.
>
> Instead of doing as a flow, defining request_url as one of the core
> variable would be better.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 9 Jun 2010 16:27:07 -0700

> FWIW, I really like that notion.  It's also very easy to describe and

+1

How does the Client decide to use this new level of indirection? When the
User Agent looks like it wouldn't like long URLs?

Dirk.

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 10 Jun 2010 15:50:52 +0900

That's right. It would help various extensions as well.

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 10 Jun 2010 16:27:57 +0900

> User Agent looks like it wouldn't like long URLs?

There are a few cases that I am aware of:

1) When the User Agent looks like  it would not like long URLs.

It is entirely possible that some extension makes a long URL.
For example, the client might want to send a public key with
the request.

2) When the server wants the request non-repudiation

The server might want the request to be non-repudiable.
It is possible to sign the request dynamically, but a simpler way of doing
it is to
make a signed request file (perhaps in Magic Signature format) and put it on
the client. It can just be done by a client utility or something, so that
the private key does not even have to reside on the server nor the client
needs to program anything.

3) When the server wants the requests to be cacheable

As I have proposed, if the request_url comes with sha256 hash of the file,
the server knows if the file has changed without fetching it, so it does not
have to re-fetch a same file, which is a win as well.

4) When the client wants to simplify the implementation without compromising
the security

If the request parameters go through the Browser, it may be tampered at the
browser even if TLS was used. This implies we need to have signature on the
request as well. However, if https request_url was used, it is not going to
be tampered, thus we now do not have to sign the request. This simplifies
the implementation.

>
> Dirk.
>
>
>>  --
>> John Panzer / Google
>> [email-masked] / abstractioneer.org <http://www.abstractioneer.org/>/ @jpanzer
>>
>>
>>

---

From: Nat <[email-masked]>
Date: Fri, 11 Jun 2010 10:26:03 +0900

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 <[email-masked]> 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 does the Client decide to use this new level of indirection?  
> When the User Agent looks like it wouldn't like long URLs?
>
> It is possible to sign the request dynamically, but a simpler way of  
> doing it is to
> make a signed request file (perhaps in Magic Signature format) and  
> put it on the client. It can just be done by a client utility or  
> something, so that the private key does not even have to reside on  
> the server nor the client needs to program anything.
>
> the server knows if the file has changed without fetching it, so it  
> does not have to re-fetch a same file, which is a win as well.
>
> 4) When the client wants to simplify the implementation without  
> compromising the security
>
> If the request parameters go through the Browser, it may be tampered  
> at the browser even if TLS was used. This implies we need to have  
> signature on the request as well. However, if https request_url was  
> used, it is not going to be tampered, thus we now do not have to  
> sign the request. This simplifies the implementation.
>
>
>
> Dirk.
>
> --
> John Panzer / Google
> [email-masked] / abstractioneer.org / @jpanzer
>
>
>
> On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H <[email-masked] 
> > wrote:
> Nat,
>
> Yes. That feels like the simplest mental model for this  
> functionality, and the simplest way to specify it.
>
> --
> James Manger
>
>
>
> -- 
> Nat Sakimura (=nat)

---

From: Luke Shepard <[email-masked]>
Date: Thu, 10 Jun 2010 20:06:06 -0700

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:

=nat @ Tokyo via iPhone

On 2010/06/10, at 16:27, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Jun 10, 2010 at 8:27 AM, Dirk Balfanz <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jun 9, 2010 at 4:05 PM, John Panzer <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> 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 does the Client decide to use this new level of indirection? When the User Agent looks like it wouldn't like long URLs?

The server might want the request to be non-repudiable.
It is possible to sign the request dynamically, but a simpler way of doing it is to
make a signed request file (perhaps in Magic Signature format) and put it on the client. It can just be done by a client utility or something, so that the private key does not even have to reside on the server nor the client needs to program anything.

As I have proposed, if the request_url comes with sha256 hash of the file,
the server knows if the file has changed without fetching it, so it does not have to re-fetch a same file, which is a win as well.

4) When the client wants to simplify the implementation without compromising the security

If the request parameters go through the Browser, it may be tampered at the browser even if TLS was used. This implies we need to have signature on the request as well. However, if https request_url was used, it is not going to be tampered, thus we now do not have to sign the request. This simplifies the implementation.

Dirk.

--
John Panzer / Google
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]> / <http://www.abstractioneer.org/> abstractioneer.org<http://abstractioneer.org/> / @jpanzer

On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
I fully agree on it.

Instead of doing as a flow, defining request_url as one of the core variable would be better.
The question then is, whether this community accepts the idea.

On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
Nat,

--
James Manger

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

_______________________________________________
OAuth mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 11 Jun 2010 14:57:22 -0700

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" <[email-masked]> wrote:

I fully agree on it.

On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H <[email-masked]> wrote:
Nat,

--
James Manger

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 17 Jun 2010 15:28:01 +0900

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 Artifact Binding, which is based on OAuth2.0).

=nat

On Sat, Jun 12, 2010 at 6:57 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> 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
>
>