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

John Bradley <ve7jtb@ve7jtb.com> Wed, 25 February 2015 01:55 UTC

Return-Path: <ve7jtb@ve7jtb.com>
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 0433C1A8871 for <oauth@ietfa.amsl.com>; Tue, 24 Feb 2015 17:55:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 IkJSKDx49Tek for <oauth@ietfa.amsl.com>; Tue, 24 Feb 2015 17:55:08 -0800 (PST)
Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B301A884E for <oauth@ietf.org>; Tue, 24 Feb 2015 17:55:08 -0800 (PST)
Received: by qcwb13 with SMTP id b13so729452qcw.7 for <oauth@ietf.org>; Tue, 24 Feb 2015 17:55:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Wo/6JADk6fq2fLQ7VHpSqDI5nL7qTKhmpYSx8geDufc=; b=K4rxjo3FgUD/rkg8jTyCs5VsGhvQnpDzDeGA/TQd/FDcrDpW6+PBryY3Md0BW8cFHU 6V7x6+IKwsbDEA5hXz06oWxJ23vQzuq8Jv6LXAjIgEIOVkmhdixu1kdBp/anRulUMgPe MNlcp5yOuh3WX4yJ9I9T8xNATcdjnL2THn5GRgeL6bXRymuiW5ATCdApq8jTyDRu8Z+r zIGYzOgm/Hsn8WGOo4EE0us2hKoHscT/lD2XKUro0S4vqGUtlvOAn3vCWdTruQnnjyh4 1Er9lt8Hx9p37n3PGjC2x1i4JFtaBIkDHJfHqqo70PYTOyqgsWRVoTeg+lTlJ/YeSk64 f2aw==
X-Gm-Message-State: ALoCoQkL/LStZEv/sWIp0CcwCr8x0xUj8xIOqRv5hPv1tuyD+GpP0VWCK7zn1WfLlSz5P+A8NEfp
X-Received: by 10.140.152.72 with SMTP id 69mr1828369qhy.53.1424829307821; Tue, 24 Feb 2015 17:55:07 -0800 (PST)
Received: from [192.168.4.129] (ip-64-134-240-44.public.wayport.net. [64.134.240.44]) by mx.google.com with ESMTPSA id y8sm30671785qal.14.2015.02.24.17.55.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 17:55:07 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_D14F7387-7690-4074-A211-59E51993B3DB"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <54E4D2A5.5030705@gmx.net>
Date: Tue, 24 Feb 2015 20:55:04 -0500
Message-Id: <CB4A9839-31F2-4B15-8E76-BC3623C8B734@ve7jtb.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> <54E4D2A5.5030705@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/QQzJeCQ0_a9v3KbS5iyMdDtiqiM>
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, 25 Feb 2015 01:55:11 -0000

Yes but it is authenticating the client to the AS as part of the resource owners consent.   

Ther eis a one to one mapping of resource owner to client in that case. 

The client ID is no more identifying than the refresh token that maps to the RO by design.

Yes the grant identifies the RO in some way.  The client_id and secret prevent that from being used in a different client if the bearer token leaks.

Remember the client_id is going to be different at different AS as each will have a separate registration.
If the client_id was fixed across multiple AS then it would be a correlation issue, but that is not the case.

Perhaps I am not understanding the concern?

John B.

> On Feb 18, 2015, at 12:57 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
> 
> 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
>> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth