Re: [OAUTH-WG] Device Profile

"Shafi, Saleem" <mshafi@paypal.com> Wed, 17 March 2010 20:44 UTC

Return-Path: <mshafi@paypal.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 9A4FA28C0CE for <oauth@core3.amsl.com>; Wed, 17 Mar 2010 13:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.034
X-Spam-Level:
X-Spam-Status: No, score=-9.034 tagged_above=-999 required=5 tests=[AWL=-4.865, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, SARE_FORGED_PAYPAL_C=1.3]
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 l-80Gspumf8k for <oauth@core3.amsl.com>; Wed, 17 Mar 2010 13:44:42 -0700 (PDT)
Received: from rhv-mipot-002.corp.ebay.com (rhv-mipot-002.corp.ebay.com [216.33.244.7]) by core3.amsl.com (Postfix) with ESMTP id 82CBF3A682A for <oauth@ietf.org>; Wed, 17 Mar 2010 13:44:42 -0700 (PDT)
DomainKey-Signature: s=ppcorp; d=paypal.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: 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=ExuJgVZ/oRdh72TqAWiEjUZP++fO0cldi5oAx7yiVQK+d0EX33uncFdT AZRxgpNh7w46epgJJvJv9KYbbtupE5s++BSqbEMQ7MZeczMoVygDxesAm 1Pq6sLVfwTk03Oe;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=mshafi@paypal.com; q=dns/txt; s=ppcorp; t=1268858693; x=1300394693; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Shafi,=20Saleem"=20<mshafi@paypal.com>|Subject: =20RE:=20Device=20Profile|Date:=20Wed,=2017=20Mar=202010 =2013:44:48=20-0700|Message-ID:=20<854035E628BF9B4C9688EB 1400DAAC72BD4459FB@RHV-MEXMS-002.corp.ebay.com>|To:=20Bre nt=20Goldman=20<brent@facebook.com>|CC:=20"OAuth=20WG=20( oauth@ietf.org)"=20<oauth@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<CF0416FE-E9BB-46F0-86C7-8644C5447ECF@fac ebook.com>|References:=20<4603A1CF-ED1B-4CE3-8EEE-53599B2 E177A@facebook.com>=0D=0A=20<854035E628BF9B4C9688EB1400DA AC72BD3CA160@RHV-MEXMS-002.corp.ebay.com>=0D=0A=20<CF0416 FE-E9BB-46F0-86C7-8644C5447ECF@facebook.com>; bh=Ondk2ONFJjkZ3dxCbsi3aZ10kbhKRvymTt9xFYbBWuM=; b=akaR946EW32yRZuOFB2CFy9CweGXISw0kKVfwyW4/XUhyWwqX+14yKvt lSoNP1jSLZDXSjdgK1r7Eev1bLaiTTZpX0r6N4t1oN79I21MX/dt0awBb DSi7SaB7xO6SO2d;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.51,261,1267430400"; d="scan'208";a="9355477"
Received: from rhv-vtenf-001.corp.ebay.com (HELO RHV-MEXHT-001.corp.ebay.com) ([10.112.113.52]) by rhv-mipot-002.corp.ebay.com with ESMTP; 17 Mar 2010 13:44:53 -0700
Received: from RHV-MEXMS-002.corp.ebay.com ([10.245.17.115]) by RHV-MEXHT-001.corp.ebay.com ([10.245.24.100]) with mapi; Wed, 17 Mar 2010 13:44:49 -0700
From: "Shafi, Saleem" <mshafi@paypal.com>
To: Brent Goldman <brent@facebook.com>
Date: Wed, 17 Mar 2010 13:44:48 -0700
Thread-Topic: Device Profile
Thread-Index: AcrFxwx3ytiWABZYRgS38vqutY2V+QASgVGw
Message-ID: <854035E628BF9B4C9688EB1400DAAC72BD4459FB@RHV-MEXMS-002.corp.ebay.com>
References: <4603A1CF-ED1B-4CE3-8EEE-53599B2E177A@facebook.com> <854035E628BF9B4C9688EB1400DAAC72BD3CA160@RHV-MEXMS-002.corp.ebay.com> <CF0416FE-E9BB-46F0-86C7-8644C5447ECF@facebook.com>
In-Reply-To: <CF0416FE-E9BB-46F0-86C7-8644C5447ECF@facebook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: d/B9yjkbpclEaVs3QUWYdA==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Device Profile
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: Wed, 17 Mar 2010 20:44:43 -0000

> Authenticating the user via text message is an awesome idea, but we can't really communicate that to the device as another
> oauth_verification_url. This is probably worthy of another profile. Using SMS to auth could also be useful at an untrusted
> computer at an internet cafe -- maybe you don't want to authenticate yourself with the AS via password in case a keylogger
> is installed. 

I'm not sure I understand why we couldn't use the oauth_verification_url for this..  Following RFC 5724 (http://tools.ietf.org/html/rfc5724), couldn't we have something like this:

    HTTP/1.1 200 OK
    Content-Type: application/x-www-form-urlencoded

    oauth_device_code=74tq5miHKB&oauth_user_code=94248&oauth_verification_url=http%3A%2F%2Fwww%2Eexample%2Ecom%2Fdevice&oauth_verification_url=sms%3A%2B180080080000

Then the client could display the option to the user to either visit http://www.example.com/device or send an SMS to 1-800-800-8000

> I'm not sure I like the reverse of this scenario. What stops other people from entering my identifier into their device,
> thus causing the AS to ping me via email or 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.

You're right, spam could be a problem, but it would be a user annoyance issue that could be mitigated by the Authorization Server much like any other spam filter might..  E.g., users could opt-out/opt-in to the entire process, or allow only certain devices/clients to communicate with them, etc..  In any case, I don't think it would pose a security risk since I simply wouldn't enter the code I received into the device if I wasn't the one that initiated it and am probably not physically at the device anyway..

Perhaps it doesn't make sense to lump this in with the device profile you've defined since the process is different 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 to the AS..  Which direction the code travels depends on what kind of input options are available and the relationship between the AS and user..


Saleem.


-----Original Message-----
From: Brent Goldman [mailto:brent@facebook.com] 
Sent: Wednesday, March 17, 2010 6:43 AM
To: Shafi, Saleem
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: Device Profile

On Mar 16, 2010, at 12:19 PM, Shafi, Saleem wrote:

> 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..

Authenticating the user via text message is an awesome idea, but we can't really communicate that to the device as another oauth_verification_url. This is probably worthy of another profile. Using SMS to auth could also be useful at an untrusted computer at an internet cafe -- maybe you don't want to authenticate yourself with the AS via password in case a keylogger is installed.

> 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..

I'm not sure I like the reverse of this scenario. What stops other people from entering my identifier into their device, thus causing the AS to ping me via email or 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-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
> 
>