Subject: [OAUTH-WG] Limiting signed requests to use the Authorization request header

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 30 Mar 2010 21:20:40 -0700

Since we have consensus that using signed requests is a more advance use
case and will be used by more experienced developer, I would like to suggest
we limit sending signed request parameters to the Authorization header (no
URI query parameters or form-encoded body).

This will not change the ability to send the oauth_token parameter in the
query or body when using bearer tokens (as well as in the header). It will
only apply to sending signed requests.

The makes client request parameter much simpler as the only parameter
"invading" the URI or body space of the request is oauth_token. Anything
else is limited to the header.

Thoughts? If you are not a fan, please reply with a use case.

EHL

---

From: Brian Eaton <[email-masked]>
Date: Tue, 30 Mar 2010 21:25:56 -0700

> else is limited to the header.

Why would oauth_token ever hit the URI or body in a signed request?

> Thoughts? If you are not a fan, please reply with a use case.

I am a fan.  +1.

---

From: David Recordon <[email-masked]>
Date: Tue, 30 Mar 2010 21:34:37 -0700

Sounds reasonable. If you're computing signatures then you certainly
can set an authorization header.

On Tue, Mar 30, 2010 at 9:25 PM, Brian Eaton <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 30 Mar 2010 21:42:35 -0700

> Why would oauth_token ever hit the URI or body in a signed request?

It wouldn't. I meant in the entire spec (i.e. Bearer tokens).

EHL

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 30 Mar 2010 22:06:57 -0700

+1

-----Original Message-----
From: Eran Hammer-Lahav <[email-masked]>
To: OAuth WG <[email-masked]>
Subject: [OAUTH-WG] Limiting signed requests to use the Authorization
request header
Date: Tue, 30 Mar 2010 21:20:40 -0700

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 31 Mar 2010 07:13:10 +0200

+1

generally, why do we need other ways than headers for sending the 
authorization data? HTTP basic/digest authentication only use headers

> From: Eran Hammer-Lahav<[email-masked]>
> To: OAuth WG<[email-masked]>

---

From: "Moore, Jonathan" <[email-masked]>
Date: Wed, 31 Mar 2010 07:25:13 -0400

What about a use case where the signature will be generated by one component but the request will be redeemed by another?

For example, suppose there is a cross-domain JSONP call that requires authorization; in this case, I might have my client side code hit *my* origin server, obtain a signed URL, and then redeem it by hitting the JSONP resource. This has scaling advantages over having my origin proxy an OAuth request, and doesn't require me to have keys located on the client; I can keep them safely in my data centers.

In this case, sending a "ready to redeem" signed request using the query parameter mechanism simplifies the client-side code. Furthermore, in this use case (cross-domain script inclusion), the client doesn't have the means to set the Authorization header (it can only include a <script> element with a URL).

A similar use case would be if you wanted to provide signed redirects (similarly useful for cross-domain functionality); browsers aren't going to modify the redirect URL they get back, or add an Authorization header to it.

Jon
........
Jon Moore
Comcast Interactive Media

-----Original Message-----
From: [email-masked] on behalf of Eran Hammer-Lahav
Sent: Wed 3/31/2010 12:20 AM
To: OAuth WG
Subject: [OAUTH-WG] Limiting signed requests to use the Authorizationrequest header

EHL