Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
Justin Richer <jricher@mit.edu> Wed, 25 February 2015 16:25 UTC
Return-Path: <jricher@mit.edu>
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 7CD2F1A90FC for <oauth@ietfa.amsl.com>; Wed, 25 Feb 2015 08:25:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.611
X-Spam-Level:
X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CjdnGWg75HO4 for <oauth@ietfa.amsl.com>; Wed, 25 Feb 2015 08:25:20 -0800 (PST)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A461A8828 for <oauth@ietf.org>; Wed, 25 Feb 2015 08:23:50 -0800 (PST)
X-AuditID: 1209190e-f79bb6d0000030e8-a6-54edf71445a7
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 76.C2.12520.517FDE45; Wed, 25 Feb 2015 11:23:49 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t1PGNmov026651; Wed, 25 Feb 2015 11:23:48 -0500
Received: from [192.168.0.109] (c-66-30-197-6.hsd1.ma.comcast.net [66.30.197.6]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1PGNkWf008384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Feb 2015 11:23:47 -0500
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <CB4A9839-31F2-4B15-8E76-BC3623C8B734@ve7jtb.com>
Date: Wed, 25 Feb 2015 11:23:45 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <FCA7BAEC-1D49-4A5E-BC0E-B290B569D1D8@mit.edu>
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> <CB4A9839-31F2-4B15-8E76-BC3623C8B734@ve7jtb.com>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixCmqrSv6/W2IweceToulO++xWjTszLc4 +fYVm8Xqu3/ZHFg8ds66y+6xeNN+No8lS34yedy+vZElgCWKyyYlNSezLLVI3y6BK+Pigi/M BQ0GFW+fv2NvYNym1sXIySEhYCJxr289G4QtJnHhHojNxSEksJhJYv2LTawQzkZGiYNnH7JA OGeZJLb3/WcEaWEW0JPYcf0XK4jNK2AgMffUFyYQW1jAXOL/gztgNpuAqsT0NS1gNqeAncSE w/PB6lmA4q3nTzOBDGUWmMco8fTvJXaIodoSyxa+ZoYYaiUxf3cX1BmrWCTO/tsJdqyIgIrE vn2PgK7gADpcXqJnU/oERsFZSG6aheSmWUjGLmBkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRr rJebWaKXmlK6iREc6pJ8Oxi/HlQ6xCjAwajEw3tA5k2IEGtiWXFl7iFGSQ4mJVHepPdvQ4T4 kvJTKjMSizPii0pzUosPMUpwMCuJ8La9AsrxpiRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1O TS1ILYLJynBwKEnwCnwDahQsSk1PrUjLzClBSDNxcIIM5wEafuMryPDigsTc4sx0iPwpRl2O LQf2z2QSYsnLz0uVEue9CVIkAFKUUZoHNweWol4xigO9JcyrBLKOB5je4Ca9AlrCBLRkz+NX IEtKEhFSUg2MHEXHw3skn72X90ueFtca2Jt79aH6RFZR5p/PnF7tPt86g1/ud1TprDJZk6ba 67L6zvtyfi+pWDalIyWhPbpswiUx61t71D8GzeTeIMc23z9l+18Fr53rTx+d7mJ7+Tzn3z85 Iu+eC75c+DDGs/HdV4e0gnoZjkkp72MX1O/rqPpdq2LEtjBYiaU4I9FQi7moOBEAv6PT0iwD AAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/98pWcmquTfS1mTVBTy3RmP1gGMw>
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 16:25:22 -0000
John’s assessment is correct and this is what we’ve tried to capture in the privacy considerations section of the latest draft: In general, the metadata for a client, such as the client name and software identifier, are common across all instances of a piece of client software and therefore pose no privacy issues for end-users. Client identifiers, on the other hand, are often unique to a specific instance of a client. For clients such as web sites that are used by many users, there may not be significant privacy concerns regarding the client identifier, but for clients such as native applications that are installed on a single end-user's device, the client identifier could be uniquely tracked during OAuth 2.0 transactions and its use tied to that single end-user. However, as the client software still needs to be authorized by a resource owner through an OAuth 2.0 authorization grant, this type of tracking can occur whether or not the client identifier is unique by correlating the authenticated resource owner with the requesting client identifier. Note that clients are forbidden by this specification from creating their own client identifier. If the client were able to do so, an individual client instance could be tracked across multiple colluding authorization servers, leading to privacy and security issues. Additionally, client identifiers are generally issued uniquely per registration request, even for the same instance of software. In this way, an application could marginally improve privacy by registering multiple times and appearing to be completely separate applications. However, this technique does incur significant usability cost in the form of requiring multiple authorizations per resource owner and is therefore unlikely to be used in practice. Hopefully this is more clear now. Thanks for the feedback and close review, — Justin > On Feb 24, 2015, at 8:55 PM, John Bradley <ve7jtb@ve7jtb.com> wrote: > > 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 >
- [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Justin Richer
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Phil Hunt
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Mike Jones
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Justin Richer
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Phil Hunt
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg John Bradley
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Justin Richer
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Hannes Tschofenig
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Hannes Tschofenig
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Sam Hartman
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Mike Jones
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Bill Burke
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Mike Jones
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg John Bradley
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg John Bradley
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Justin Richer
- Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg Kathleen Moriarty