Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 18 February 2015 17:58 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124BE1A7003 for <oauth@ietfa.amsl.com>; Wed, 18 Feb 2015 09:58:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.31
X-Spam-Level:
X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEtpTsgJwFbU for <oauth@ietfa.amsl.com>; Wed, 18 Feb 2015 09:58:05 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BF41A8749 for <oauth@ietf.org>; Wed, 18 Feb 2015 09:58:05 -0800 (PST)
Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lpfas-1Xsdp831i2-00fRnm; Wed, 18 Feb 2015 18:58:00 +0100
Message-ID: <54E4D2A5.5030705@gmx.net>
Date: Wed, 18 Feb 2015 18:57:57 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Justin Richer <jricher@mit.edu>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
References: <CAHbuEH587HcqaqTMrmLPXQimRAaS2j1Uv+BC-0UHeyBwC8+3Uw@mail.gmail.com> <54DC2CB1.8090400@mit.edu> <D3644538-EF35-476B-8158-270C8FC21647@oracle.com> <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com> <CAHbuEH5NUcQ5Q30yj80OSBe4epaarpkFroyM_Yfp5-thkMJBgA@mail.gmail.com> <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com> <CAHbuEH4Pa6N5YMP=5f0W24nPsQ8aGPqL8sHOaspE5A1K8Gui4Q@mail.gmail.com> <DC682515-BCFD-42B8-9765-BD8EF32DDBD2@mit.edu>
In-Reply-To: <DC682515-BCFD-42B8-9765-BD8EF32DDBD2@mit.edu>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gKxvB3lvqsQ9K9vVg40xU8OmVNEawNeKb"
X-Provags-ID: V03:K0:Tcd6z0RU15ENzvsVkjD5v0EkKdkMXaA9zY3ky1UVWzHIJXUOVPX +DeHQfUYjVl05qDJJo1tQEG8Grequ73YRG1QqeJdHC1q2jpouhIHwKfvo3Yhdfnmrvk4DtR +0urXbxHD/+tS5BTOEUXNE/sp8pF1Iv2baxrX4ibliizyambrvy9yO1ROE6sXY8qxlqqnre D128uf1esmL3N5U/tkw6w==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/dzRquU1Q2o7Wz59ZFgkVd-4MV4M>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 18 Feb 2015 17:58:08 -0000

Hi Justin, Hi John,

I believe that provisioning a client with a unique id (which is what a
client id/client secret is) allows some form of linkability. While it
may be possible to associate the client to a specific user I could very
well imagine that the correlation between activities from a user and
those from the client (particularly when the client is running on the
user's device) is quite possible.

Ciao
Hannes

On 02/18/2015 06:37 PM, Justin Richer wrote:
> I’ll incorporate this feedback into another draft, to be posted by the
> end of the week. Thanks everyone!
> 
>  — Justin
> 
>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>> <kathleen.moriarty.ietf@gmail.com
>> <mailto:kathleen.moriarty.ietf@gmail.com>> wrote:
>>
>>
>>
>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <ve7jtb@ve7jtb.com
>> <mailto:ve7jtb@ve7jtb.com>> wrote:
>>
>>     snip
>>>     On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>>>     <kathleen.moriarty.ietf@gmail.com
>>>     <mailto:kathleen.moriarty.ietf@gmail.com>> wrote:
>>>
>>>         > The client_id *could* be short lived, but they usually aren't. I don't see any particular logging or tracking concerns using a dynamic OAuth client above using any other piece of software, ever. As such, I don't think it requires special calling out here.
>>>
>>>
>>>     Help me understand why there should not be text that shows this
>>>     is not an issue or please propose some text.  This is bound to
>>>     come up in IESG reviews if not addressed up front. 
>>>
>>>
>>
>>     The client_id is used to communicate to the Authorization server
>>     to get a code or refresh token.  Those tokens uniquely identify
>>     the user from a privacy perspective. 
>>     It is the access tokens that are sent to the RS and those can and
>>     should be rotated, but the client)id is not sent to the RS in
>>     OAuth as part of the spec. 
>>
>>     If you did rotate the client_id then the AS would track it across
>>     rotations, so it wouldn’t really achieve anything.
>>
>>     One thing we don’t do is allow the client to specify the
>>     client_id, that could allow correlation of the client across
>>     multiple AS and that might be a privacy issue, but we don’t allow it.
>>
>>
>> Thanks, John.  It may be helpful to add in this explanation unless
>> there is some reason not to? 
>>
>>
>>     John B.
>>
>>
>>
>>
>> -- 
>>
>> Best regards,
>> Kathleen
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>