Re: [OAUTH-WG] Device Profile

"Shafi, Saleem" <mshafi@paypal.com> Tue, 16 March 2010 19:19 UTC

DomainKey-Signature: s=ppcorp; d=paypal.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=S7OxptAwVVLIcE2dpHcz7C+v6CW3TYnAMnso2rbed69l+vlJSUTZeZF7 J/ic6eHc9bLM3R9aEAp1rSA7ga0iqrsIDtW0dJMCqnDMgyKWuZmBd+/FM ZWubc3qaFwwsVkT;
From: "Shafi, Saleem" <mshafi@paypal.com>
To: Brent Goldman <brent@facebook.com>, "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Date: Tue, 16 Mar 2010 12:19:48 -0700
Thread-Topic: Device Profile
Thread-Index: AcrBBY9CyqPQQpiETL2yGqJ87nEJnwEN0g6Q
Message-ID: <854035E628BF9B4C9688EB1400DAAC72BD3CA160@RHV-MEXMS-002.corp.ebay.com>
References: <4603A1CF-ED1B-4CE3-8EEE-53599B2E177A@facebook.com>
In-Reply-To: <4603A1CF-ED1B-4CE3-8EEE-53599B2E177A@facebook.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Device Profile
Precedence: list

Hello..
 
Is there any interest in being able to respond with multiple oauth_verification_url values?  I can forsee the possibility of the Authorization Server being able to support browser-based user verification (http/https) or text messages (assuming we could authenticate the user on sending the SMS)..  Letting the authorization server return multiple URLs could give the client/user more options..
 
Also, would there be room in this profile for a scenario where the user verification code isn't returned to the client, but rather sent to the user directly?  If the initial request that the client makes includes some identifier for the user and the authorization server has contact information for that user, could the AS inform the user (via email, sms, IVR, etc) of a one-time user code that they would enter into the device*?  It's sort of the reverse model, but it should still establish a connection between the device, AS and user..  This profile might make sense where the device has very simple data entry options and the user might not be near a browser-capable device..
 
Saleem.

*Eve points out that this is somewhat simliar to the verification_code addition in the Oauth 1.0a spec to protect against session-fixation attacks (http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/), especially the way it's communicated in WRAP's Rich App profile when the app in question can't be contacted by the AS with a URL..


-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brent Goldman
Sent: Thursday, March 11, 2010 4:28 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Device Profile

Over the past couple days, Luke Shepard, David Recordon, and I have been brainstorming an OAuth profile for standardizing the flow that devices such as game consoles and entertainment centers use to hook up with services such as Netflix and iTunes. The basic flow is that a device can gain authorization by directing the user to visit a URL on their computer and to enter a verification code copied from the device's screen.

A draft spec is attached to this email. Any thoughts or feedback?

Note: this is one of the many profiles going into the OAuth 2.0 draft that David is writing (http://daveman692.livejournal.com/349384.html).

-Brent

[OAUTH-WG] Device Profile Brent Goldman
Re: [OAUTH-WG] Device Profile Shafi, Saleem
Re: [OAUTH-WG] Device Profile Brent Goldman
Re: [OAUTH-WG] Device Profile Shafi, Saleem
Re: [OAUTH-WG] Device Profile Brent Goldman
Re: [OAUTH-WG] Device Profile Eric Sachs
[OAUTH-WG] Device Profile Aiden Bell
Re: [OAUTH-WG] Device Profile Marius Scurtescu