Return-Path: 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 20C0B1A87A6 for ; Wed, 18 Feb 2015 09:58:07 -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 dil_BTkUm68U for ; 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 25BCA1A7003 for ; Wed, 18 Feb 2015 09:58:05 -0800 (PST) Received: from [192.168.131.129] ([80.92.119.127]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M7Y9j-1XbFZ002v1-00xO1A; Wed, 18 Feb 2015 18:58:01 +0100 Message-ID: <54E4D2A5.7090501@gmx.net> Date: Wed, 18 Feb 2015 18:57:57 +0100 From: Hannes Tschofenig 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 , Kathleen Moriarty References: <54DC2CB1.8090400@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com> <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8ej04jDCNh1cu1GDdkwc7OcbiKoSCHWGN" X-Provags-ID: V03:K0:IlF566tb5le4pvwWQZpvNZwkucdMXtVJ163QWpCkYv+hEyNHgtY EPET6NBe+C2fppKJAhLXTYaY4S6i5REszS2d+Cy3xCDEekOCS5ANTmkhSOUaw3lAcjUMPjx mpu5xUgbjfb3zCSdn/HFASdB2roDo9pLA61SBn3tbGifutj7cCCD3AVa8kSGbIgrtel57F9 qVMERB4YuaZeLfSNrymWQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 17:58:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8ej04jDCNh1cu1GDdkwc7OcbiKoSCHWGN Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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=92ll incorporate this feedback into another draft, to be posted by th= e > end of the week. Thanks everyone! >=20 > =97 Justin >=20 >> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty >> > > wrote: >> >> >> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley > > wrote: >> >> snip >>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty >>> >> > 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 dynam= ic 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.=20 >>> >>> >> >> 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.=20 >> 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.=20 >> >> If you did rotate the client_id then the AS would track it across >> rotations, so it wouldn=92t really achieve anything. >> >> One thing we don=92t 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=92t allo= w it. >> >> >> Thanks, John. It may be helpful to add in this explanation unless >> there is some reason not to?=20 >> >> >> John B. >> >> >> >> >> --=20 >> >> Best regards, >> Kathleen >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --8ej04jDCNh1cu1GDdkwc7OcbiKoSCHWGN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU5NKlAAoJEGhJURNOOiAtwTsH/1YDT74iYqN5eAqFvtNqyLJ5 4DBpvBABJN+m4j/BLaOP3G7cw16R0/TE3Ncw3qmgyA7IM5D/+b/57C2PtQGRRfBJ kCYS+3XFkkgD1qXKfSK5JN+ZFxIm/0g2FHZTh5d8QuJKNKHDcLrxJUh2/VLHYijK sqSC4NXjiexQKcPBtPnOW6Fgiajs+fpbmoEYP/INF9lOaHJIdVP56OPbwDvfEDuE r6OHzrOspdIh/Ynq7RGJpu3R8ejpmlaPz8Jgxsq7Rl5GYX5tXoMQLaFGSR1ExtRh WUwh9SZiI4jbxoAKdnIZ2N12C5WNOcUvOsPO1KQ8S+Z1/tsLRFTfHM5ZUJh6lR4= =ZlUc -----END PGP SIGNATURE----- --8ej04jDCNh1cu1GDdkwc7OcbiKoSCHWGN--