IETF Logo Mail Archive

Re: [OAUTH-WG] device profile comments

Brian Eaton <beaton@google.com> Mon, 10 May 2010 23:26 UTC

Return-Path: <beaton@google.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 EEE483A69E1 for <oauth@core3.amsl.com>; Mon, 10 May 2010 16:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.6
X-Spam-Level:
X-Spam-Status: No, score=-101.6 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
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 eC00uvNCiE+9 for <oauth@core3.amsl.com>; Mon, 10 May 2010 16:26:47 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 5E6AD3A6B86 for <oauth@ietf.org>; Mon, 10 May 2010 16:24:43 -0700 (PDT)
Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o4ANOVK7014118 for <oauth@ietf.org>; Mon, 10 May 2010 16:24:31 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273533871; bh=v3MMbdR+7gwtz9axWfgEm74Vk+w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=iwNSDhz6ily/3H92sO5/xR4gwPaCgUuv12SJjzaS4KjjmyNXX7peLwecR9OTc4IfO 51STVjBymOQGN17ARG39w==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=LtW21ZOzojgU/8KI55+BOQnh+nnxXq6AS/NyfPwqZOi102qXuvmYlgjL5uAoveJ7G XQmtaHcZZ2v5Bh2Oe6yYw==
Received: from pxi1 (pxi1.prod.google.com [10.243.27.1]) by hpaq14.eem.corp.google.com with ESMTP id o4ANO2VK031821 for <oauth@ietf.org>; Mon, 10 May 2010 16:24:30 -0700
Received: by pxi1 with SMTP id 1so1891284pxi.22 for <oauth@ietf.org>; Mon, 10 May 2010 16:24:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.143.27.18 with SMTP id e18mr3260900wfj.41.1273533869422; Mon, 10 May 2010 16:24:29 -0700 (PDT)
Received: by 10.143.136.7 with HTTP; Mon, 10 May 2010 16:24:29 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <i2odaf5b9571004221649h733f675bva2f9f4438ef43921@mail.gmail.com> <y2kfd6741651004221758y7d207961we2a6d1e65e6dd279@mail.gmail.com> <o2qdaf5b9571004262327u90caa8b6vbfa976ec44c86d91@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Mon, 10 May 2010 16:24:29 -0700
Message-ID: <AANLkTilz19cI0FCy8nChbsD9DOUQLeUNJVI2dg4p49ao@mail.gmail.com>
From: Brian Eaton <beaton@google.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
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: Mon, 10 May 2010 23:26:48 -0000

On Sun, May 9, 2010 at 10:12 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>> "The client is incapable of receiving incoming requests from the authorization
>> server (incapable of acting as an HTTP server).  ADD:
>> The device manufacturer is assumed to have registered with the
>> authorization server.  The authorization server and device manufacturer
>> agree on a client id used to identify the manufacturer's devices."
>
> I don't see the point. The fact that there is a client_id parameter makes this clear enough. This is true for all flows.

It's definitely not true for all flows.  Neither the web app profile,
nor the javascript profile, nor the installed application profile
requires preregistration in order to work.  The appropriate user
experience happens via the callback URL.

The device profile is different because you really cannot achieve a
suitable user experience without preregistration.

v2.23.0 | Report a Bug | By Email