pre-authorized" GET
requests, whether they use OAuth or not. I may reach out to the HTTP WG about
that.
Jon
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Monday, April 12, 2010 2:03 AM
To: Moore, Jonathan
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Limiting
Hi Jon,
Purely from a process perspective, the same goes with convincing that this
use case is core to the protocol. There is already a list of things the core
spec does not support (language preference, re-delegation, body signatures,
asymmetric secrets, discovery, UI features) which people want
Actually, in this case, I'm imagining a base page that is heavily
cached (and non-personalized), perhaps delivered by CDN, non-SSL. The
rendered page then wants to make an authorized cross-domain call to
the Service Provider, personalized to the currently logged-in user.
I don't think one-t
I don't know if we are really done. Does the current draft already
consider one-time tokens? How does a client acquire one-time tokens?
Moreover, I would prefer the signature solution because of the increase
in load caused by the acquisition of multiple one-time tokens.
Apart from that, anoth
Ok, thanks - I was missing the possibility that bearer tokens could be
single use. I agree this covers my use case adequately, so I am now
definitely +1 for simplifying the spec in this way.
Thanks for bearing (pun intended) with me.
Jon
Jon Moore
On Apr 10, 2010, at 3:30 AM, "To
From my point of view, your use case can be implemented in two ways
1) tokenized & signed URLs provided by your origin server
2) URLs with one-time usage bearer tokens as parameter acquired by your
origin server
I see the following pros/cons:
Load: (2) requires the origin server to acquire on
Its a more complicated spec in both detail and how signatures are created.
The fact that the URI or body includes both resource parameters and
token/signature parameters makes it necessary to parse and sort the parameters,
deal with encoding, etc. If we limit signed request to the header, then a
However, this doesn't address my earlier use case of a signed, cross-
domain JSONP call, especially if it's sitting on a non-HTTPS page; I
need to make a non-HTTP XHR request to obtain a (signed or tokenized)
URL to include in my
In practice this is the same as logging in which I expect to require SSL
anyway. Signed or not, attackers should not be able to login to your email
account simply by using a MITM attack when you click on your IM client. So SSL
is required already.
EHL
On 4/9/10 7:30 AM, "George Fletcher" wro
4/8/10 11:31 AM, Eran Hammer-Lahav wrote:
Re: [OAUTH-WG] Limiting signed requests to use the
Authorization request header Can you share an example of a
native application launching an external browser with a
protect resource?
Native application = AIM
Yes, this is possible, though to be secure it should really happen over
SSL which is less of a requirement for a signed request.
I guess the main question is whether we really need to remove the
signature related parameters from URL and only allow them in the
Authorization header. For signed r
As far as I understand, this use case could also be implemented using
bearer tokens. Am I wrong?
I assume the benefit of using signed GET requests is a better protection
against abuse of the token if the URL is spread via log files or
Referer-Headers. But this measure obliges the receiver to i
On Thu, Apr 8, 2010 at 7:08 AM, George Fletcher wrote:
> I realize that these sorts of use cases are trivial if establishment of the
> SSO session switches from a signed mechanism to the OAuth WRAP bearer token
> model. The one nice feature of the signed URL is that it is one time use
> where the
t;>
>> Allen
>>
>>
>> On 4/8/10 11:30 AM, "George Fletcher" wrote:
>>
>> On 4/8/10 11:31 AM, Eran Hammer-Lahav wrote:
>>
>> Re: [OAUTH-WG] Limiting signed requests to use the
>> Authorization request header Can y
On 4/8/10 11:31 AM, Eran Hammer-Lahav wrote:
Re: [OAUTH-WG] Limiting signed requests to use the
Authorization request header Can you share an example of a
native application launching an external browser with a
protect resource?
Native application = AIM
;>
>>> Not odd at all a lot of the Eclipse applications can work this way
>>>
>>>
>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
>>> Eran Hammer-Lahav
>>> Sent: Thursday, April 08, 2010 7:41 AM
>
e Fletcher; OAuth WG
*Cc:* Jonathan Moore
*Subject:* Re: [OAUTH-WG] Limiting signed requests to use the
Authorization request header
Why is the native application launching a browser with a protected
resource request? That seems odd.
Note that we currently have no plans
Fletcher; OAuth WG
Cc: Jonathan Moore
Subject: Re: [OAUTH-WG] Limiting signed requests to use the Authorization
request header
Why is the native application launching a browser with a protected resource
request? That seems odd.
Note that we currently have no plans of supporting signatures in any
, 2010 7:41 AM
To: George Fletcher; OAuth WG
Cc: Jonathan Moore
Subject: Re: [OAUTH-WG] Limiting signed requests to use the Authorization
request header
Why is the native application launching a browser with a protected resource
request? That seems odd.
Note that we currently have no pl
Why is the native application launching a browser with a protected resource
request? That seems odd.
Note that we currently have no plans of supporting signatures in any of the
flows. We are discussing signatures only for using tokens with secrets when
accessing protected resources.
EHL
On 4
Another use case is where a rich client wants to bootstrap a web session
with the same identity (rich client to web SSO). Assuming that the web
session will be established via OAuth with signatures, there is no way
to fire up the browser with a "signed URL" if the OAuth parameters and
signature
+1
generally, why do we need other ways than headers for sending the
authorization data? HTTP basic/digest authentication only use headers
+1
-Original Message-
From: Eran Hammer-Lahav
To: OAuth WG
Subject: [OAUTH-WG] Limiting signed requests to use the Authorization
request header
D
+1
-Original Message-
From: Eran Hammer-Lahav
To: OAuth WG
Subject: [OAUTH-WG] Limiting signed requests to use the Authorization
request header
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 ex
On 3/30/10 9:25 PM, "Brian Eaton" wrote:
> On Tue, Mar 30, 2010 at 9:20 PM, Eran Hammer-Lahav
> wrote:
>> 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.
>
> Wh
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 wrote:
> On Tue, Mar 30, 2010 at 9:20 PM, Eran Hammer-Lahav
> wrote:
>> The makes client request parameter much simpler as the only parameter
>> "i
On Tue, Mar 30, 2010 at 9:20 PM, Eran Hammer-Lahav wrote:
> 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.
Why would oauth_token ever hit the URI or body in a signed
26 matches
Mail list logo
