I sent this reply to Brian's original email earlier, but forgot to click
reply-all.
I disagree with hardcoding the approval URL into the device. To enable short
URLs, there's nothing in the spec preventing the Auth Server from returning a
different approval URL for each client id. E.g.,http://w
+1 to accepting only HTTP POST and preventing cross-site posting.
On Apr 2, 2010, at 10:20 AM, Marius Scurtescu wrote:
> On Fri, Apr 2, 2010 at 8:53 AM, Brian Eaton wrote:
>> On Thu, Apr 1, 2010 at 9:18 PM, Allen Tom wrote:
>>> The Auth server should also check for the presence of an HTTP Refer
Even if the auth server is using redirects for user simplicity, it can still
comply with the referer-checking requirement by having the simple URL
(http://google.samsung.com) pass its referer as a GET param to the actual
complex URL (https://www.google.com/accounts/OAuthAuthorize?client_id=12389
-OPTION or JavaScript, a page cannot
be prevented from being displayed in an iframe.
On Apr 1, 2010, at 9:20 PM, Eran Hammer-Lahav wrote:
> Can you write this as an actual proposal for the text?
>
> EHL
>
>
> On 4/1/10 8:25 PM, "Brent Goldman" wrote:
>
>&g
Auth server must not enable “auto approval” for the device flow.
Meaning that the user must click through the approval screen, even if the user
had previously authorized the same client_id previously
Allen
On 4/1/10 9:06 PM, "Brent Goldman"
> wrote:
Isn't there a similar
ode into the
device.
-- Forwarded message --
From: Eric Sachs mailto:esa...@google.com>>
Date: Wed, Mar 17, 2010 at 5:45 PM
Subject: Re: [OAUTH-WG] Device Profile
To: Brent Goldman mailto:br...@facebook.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)"
+1 on both
Regarding clickjacking: If we don't want the flows to be inlined in an iframe,
specifying that the clients must show the server in a popup doesn't protect
against malicious clients that choose to show it in an iframe anyway. So I
think it also make sense to add to the core spec that
I am also supportive of this approach.
On Mar 24, 2010, at 7:13 PM, David Recordon wrote:
> I'm certainly supportive of this approach; Eran has shown that he's a
> good editor. :)
>
> On Wed, Mar 24, 2010 at 10:11 AM, Blaine Cook wrote:
>>
>>
>> Hi all,
>>
>> Hannes and I have discussed the
erent enough, but I think the use cases
> overlap.. The only difference really is that in your flow, the user code
> travels from the AS to the client to the user and back to the AS; whereas in
> the flow I've described, it flows from the AS to the user to the client back
SMS? Also, the Device Profile was created as the reverse of OAuth, so
the reverse of the Device Profile is just a variation on regular OAuth! Maybe
this could be developed into yet another profile.
-Brent
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@i
(http://daveman692.livejournal.com/349384.html).
-Brent
# This is an initial draft for discussion and is designed to act like devices
which integrate with Netflix and iTunes. It was written initially by Brent
Goldman (br...@facebook.com).
The Device Profile is suitable when the client is a d
On Feb 18, 2010, at 9:14 AM, Eran Hammer-Lahav wrote:
> A few questions we should answer before moving forward. Considering *your*
> use cases and reasons for being here:
>
> 1. Why are you here? What are you trying to solve that is not already
> addressed by existing specifications (OAuth 1.0
12 matches
Mail list logo
