Re: [OAUTH-WG] device profile comments

Brent Goldman <brent@facebook.com> Sat, 24 April 2010 02:19 UTC

Return-Path: <brent@facebook.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89F613A67CF for <oauth@core3.amsl.com>; Fri, 23 Apr 2010 19:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.264
X-Spam-Level:
X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv5WrEc9qFPH for <oauth@core3.amsl.com>; Fri, 23 Apr 2010 19:18:57 -0700 (PDT)
Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 7EC9D3A67F6 for <oauth@ietf.org>; Fri, 23 Apr 2010 19:18:44 -0700 (PDT)
Received: from mail.thefacebook.com ([192.168.18.212]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o3O2HjL0031548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 Apr 2010 19:17:45 -0700
Received: from sc-hub02.TheFacebook.com (192.168.18.105) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.689.0; Fri, 23 Apr 2010 19:18:20 -0700
Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Fri, 23 Apr 2010 19:18:20 -0700
From: Brent Goldman <brent@facebook.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Fri, 23 Apr 2010 19:17:17 -0700
Thread-Topic: [OAUTH-WG] device profile comments
Thread-Index: AcrjVGh1Gn9QqhhcRP+nHJBo4hcqow==
Message-ID: <464689C5-571B-43F6-9B3B-4C8DA525D9D3@facebook.com>
References: <i2odaf5b9571004221649h733f675bva2f9f4438ef43921@mail.gmail.com> <4BD1AE7F.3000001@lodderstedt.net>
In-Reply-To: <4BD1AE7F.3000001@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_464689C5571B43F69B3B4C8DA525D9D3facebookcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-23_10:2010-02-06, 2010-04-23, 2010-04-23 signatures=0
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] device profile comments
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Apr 2010 02:19:05 -0000

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://www.facebook.com/roku to link a Roku device to your Facebook account.

I also don't think we need a callback URL specified by the device so that instructional text can be displayed after the user authorized. The approval URL will just tell the user to go back to the device once they're done. If an Auth Server wants to support more detailed instructions, the client can register a callback URL or approval text in advance, at the same time they're registering their short URL.

-Brent

On Apr 23, 2010, at 7:28 AM, Torsten Lodderstedt wrote:


- Authorization server doesn’t return approval URL - device hard-codes
this instead.
   I expect that this will point to a manufacturer specific page, and
that the manufacturer specific page will automatically redirect to a
page on the authorization server.


Why not returning client-id-specific approval-URLs from the
authorization server? This would allow to change them dynamically w/o
changing the device's firmware/configuration.
And even if the authorization server returns an URL, the device
firmeware can always use hard-coded URLs.

What do you think?

regards,
Torsten.
- Approval URL MUST have client_id, and MAY have callback.
   I expect that the client_id will be used to brand the approval
page, and that the callback will point to a manufacturer specific
completion page.

Plus a few comments on error codes:

“End User Authorization Pending or Expired” - authorization server
probably isn’t going to be able to tell whether a code has expired, or
was never issued.  Probably just return “unknown_code”.

The “slow_down” error probably merits an “interval”.  Maybe always
return “interval” with authorization_pending, and eliminate the
slow_down error code entirely?

Cheers,
Brian

[1] http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps
[2] http://sites.google.com/site/oauthgoog/UXFedLogin/nobrowser
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth