Re: [OAUTH-WG] Clarification of "client application consisting of multiple components"

nov matake <nov@matake.jp> Sun, 11 March 2012 17:43 UTC

Return-Path: <nov@matake.jp>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD5921F85C2 for <oauth@ietfa.amsl.com>; Sun, 11 Mar 2012 10:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.668
X-Spam-Level:
X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8amBWym9tIa for <oauth@ietfa.amsl.com>; Sun, 11 Mar 2012 10:43:35 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 986DC21F85C0 for <oauth@ietf.org>; Sun, 11 Mar 2012 10:43:32 -0700 (PDT)
Received: by dakl33 with SMTP id l33so4345511dak.31 for <oauth@ietf.org>; Sun, 11 Mar 2012 10:43:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=LsGEIN9zjvJ//86rSW+lcltsCytqgZJ6v4fyY7+si/4=; b=QuV39ObMt1iOePAngn5O6M6pqDjRJGZBy/6jOliPBnCzKA33ayFq4BtlQjqu87W8xD N4RCtOyZSagXvoqw13DyKZsN32pN82lE3ik1LUkojtY1NY6hi9sedclNxx9oGzegqJ3g R6ScYUNxu65aZQU/OZ/GAk9FWRdrkbS6iIPylMvOIkPTPC5l0AhmI7DNWiZl2x012ORv tOfDt5o+Se2wsTSwLUKcVcNNu64XTLokn0ekxMiNBOUYlJ+7jOfsrnAR2qnckUR1Lzw2 QuKGyXXa++6yC0cDKTz0vzrpmPiVhMU+Kuc8daOYUgVqyqyKoapBOBevR3zA9s0AsgXe Vzzg==
Received: by 10.68.235.34 with SMTP id uj2mr15314566pbc.74.1331487812178; Sun, 11 Mar 2012 10:43:32 -0700 (PDT)
Received: from [192.168.1.106] (q032020.dynamic.ppp.asahi-net.or.jp. [203.181.32.20]) by mx.google.com with ESMTPS id z10sm8535801pbq.55.2012.03.11.10.43.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 10:43:31 -0700 (PDT)
References: <62D85564-7961-4AB6-B1FA-B2DD75A4C74B@matake.jp> <90C41DD21FB7C64BB94121FBBC2E723453AFF08605@P3PW5EX1MB01.EX1.SECURESERVER.NET> <C129DBDE-09EE-42F9-8530-5D777A3457DE@matake.jp> <90C41DD21FB7C64BB94121FBBC2E723453AFF08609@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFF08609@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <038CA61F-9DB3-45BC-8DEF-85738F50EA97@matake.jp>
X-Mailer: iPhone Mail (9B176)
From: nov matake <nov@matake.jp>
Date: Mon, 12 Mar 2012 02:43:26 +0900
To: Eran Hammer <eran@hueniverse.com>
X-Gm-Message-State: ALoCoQk4LTjNXQBAQVUhzZGVb76yWqDO39cKK/24FJmTntdXXpyp7l2oYfHrofVYexInHwez5YVz
Cc: nov matake <nov@matake.jp>, "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Clarification of "client application consisting of multiple components"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 11 Mar 2012 17:43:35 -0000

I understood.
Thanks.

--
nov

On Mar 12, 2012, at 2:30 AM, Eran Hammer <eran@hueniverse.com> wrote:

> That use case was removed from the specification. Either way, it is up to the authorization server to decide which registration options to offer the client if they make such a grant type available in the future, and how it will apply the security policies. IOW, those proposing such an extension in the future will have to figure out how this should be handled.
> 
> EH
> 
>> -----Original Message-----
>> From: nov matake [mailto:nov@matake.jp]
>> Sent: Sunday, March 11, 2012 10:21 AM
>> To: Eran Hammer
>> Cc: nov matake; oauth@ietf.org WG
>> Subject: Re: [OAUTH-WG] Clarification of "client application consisting of
>> multiple components"
>> 
>> So what is the usecase of response_type=token%20code ?
>> I thought, in that usecase, token was for the client's client-side component,
>> code was for the client's server-side component, and both of them have the
>> same client_id.
>> 
>> --
>> nov
>> 
>> On Mar 12, 2012, at 12:57 AM, Eran Hammer <eran@hueniverse.com> wrote:
>> 
>>> If you have two components each with different security profile, you must
>> assign each a different client_id. Otherwise, there is no way to enforce the
>> rest of the spec's security requirements.
>>> 
>>> EH
>>> 
>>>> -----Original Message-----
>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>> Behalf Of nov matake
>>>> Sent: Sunday, March 11, 2012 8:25 AM
>>>> To: oauth@ietf.org WG
>>>> Subject: [OAUTH-WG] Clarification of "client application consisting
>>>> of multiple components"
>>>> 
>>>> Hi,
>>>> 
>>>> I just found this sentence in the latest draft.
>>>> 
>>>> Does it mean "an application consisting of server-side and
>>>> client-side component (eg. foursquare iPhone app) MUST have separate
>>>> client_id for each component" ?
>>>> Or can I image something like Facebook is doing right now? (register
>>>> each component for a single client_id separately)
>>>> 
>>>> ==
>>>> A client application consisting of multiple components, each with its
>>>> own client type (e.g. a distributed client with both a confidential
>>>> server-based component and a public browser-based component), MUST
>>>> register each component separately as a different client to ensure
>>>> proper handling by the authorization server.  The authorization
>>>> server MAY provider tools to manage such complex clients through a
>> single administration interface.
>>>> ==
>>>> 
>>>> --
>>>> nov <nov@matake.jp>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth