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 4171E1A1A72 for ; Mon, 2 Mar 2015 08:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] 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 fuy9JdRPaHZ4 for ; Mon, 2 Mar 2015 08:03:36 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (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 05FFD1A1ABB for ; Mon, 2 Mar 2015 08:03:36 -0800 (PST) Received: by labgd6 with SMTP id gd6so31322815lab.7 for ; Mon, 02 Mar 2015 08:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C1dHF4CqBrp48EkGjiDpTEm8W/a0CP9SDYGvgIqieyI=; b=M+L1XBYosfCYBR7gWpIqiGjXWp7ISFJGXS+rjxAlGISFJxnkx/J8/aLtX9T4wvE+v0 zyemkdbGwj8bnQiclE1OWxypFrj6l30rb/dt4wmZ66qwOaGZmZzqHkdfEbwct2QlMCo9 A4t95CfnIWj4ecaAteaKeVNscnWNKzVYpufF0HyjxJVgNWVFSjasH56UChzTQLUeDBrK CxiKswZM4xdfpw8iegFRtA2mNRDN6Acpxo/oUpWALNHFXJLQcOS9zu4hq3X+r314WzIH 4CEgk7ftmAXMoKenGYAMLGlm9oaeNOJvuxajvYiq90K/YxSCoS1CRL/S+LpsIh7AzeZd ZKPw== MIME-Version: 1.0 X-Received: by 10.112.130.39 with SMTP id ob7mr15543200lbb.32.1425312214482; Mon, 02 Mar 2015 08:03:34 -0800 (PST) Received: by 10.112.167.101 with HTTP; Mon, 2 Mar 2015 08:03:34 -0800 (PST) In-Reply-To: References: <54DC2CB1.8090400@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com> <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com> <54E4D2A5.5030705@gmx.net> Date: Mon, 2 Mar 2015 11:03:34 -0500 Message-ID: From: Kathleen Moriarty To: Justin Richer Content-Type: multipart/alternative; boundary=047d7b3433da3d05310510505c19 Archived-At: Cc: "" 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: Mon, 02 Mar 2015 16:03:39 -0000 --047d7b3433da3d05310510505c19 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you, I just reviewed the diff and the changes to the draft look good. Best regards, Kathleen On Wed, Feb 25, 2015 at 11:23 AM, Justin Richer wrote: > John=E2=80=99s assessment is correct and this is what we=E2=80=99ve 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, > =E2=80=94 Justin > > > On Feb 24, 2015, at 8:55 PM, John Bradley 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 t= o > 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 ver= y > >> 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=E2=80=99ll incorporate this feedback into another draft, to be post= ed by the > >>> end of the week. Thanks everyone! > >>> > >>> =E2=80=94 Justin > >>> > >>>> 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 dynamic OAu= th > 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=E2=80=99t really achieve anything. > >>>> > >>>> One thing we don=E2=80=99t 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=E2=80=99= 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 > >>>> 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 > > > > --=20 Best regards, Kathleen --047d7b3433da3d05310510505c19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you, I just reviewed the diff and the changes to the= draft look good.

Best regards,
Kathleen
=

On Wed, Feb= 25, 2015 at 11:23 AM, Justin Richer <jricher@mit.edu> wrote:<= br>
John=E2=80=99s assessment is correct and = this is what we=E2=80=99ve tried to capture in the privacy considerations s= ection of the latest draft:

=C2=A0 =C2=A0In general, the metadata for a client, such as the client name= and
=C2=A0 =C2=A0software identifier, are common across all instances of a piec= e of
=C2=A0 =C2=A0client software and therefore pose no privacy issues for end-u= sers.
=C2=A0 =C2=A0Client identifiers, on the other hand, are often unique to a s= pecific
=C2=A0 =C2=A0instance of a client.=C2=A0 For clients such as web sites that= are used by
=C2=A0 =C2=A0many users, there may not be significant privacy concerns rega= rding
=C2=A0 =C2=A0the client identifier, but for clients such as native applicat= ions
=C2=A0 =C2=A0that are installed on a single end-user's device, the clie= nt
=C2=A0 =C2=A0identifier could be uniquely tracked during OAuth 2.0 transact= ions
=C2=A0 =C2=A0and its use tied to that single end-user.=C2=A0 However, as th= e client
=C2=A0 =C2=A0software still needs to be authorized by a resource owner thro= ugh an
=C2=A0 =C2=A0OAuth 2.0 authorization grant, this type of tracking can occur=
=C2=A0 =C2=A0whether or not the client identifier is unique by correlating = the
=C2=A0 =C2=A0authenticated resource owner with the requesting client identi= fier.

=C2=A0 =C2=A0Note that clients are forbidden by this specification from cre= ating
=C2=A0 =C2=A0their own client identifier.=C2=A0 If the client were able to = do so, an
=C2=A0 =C2=A0individual client instance could be tracked across multiple co= lluding
=C2=A0 =C2=A0authorization servers, leading to privacy and security issues.=
=C2=A0 =C2=A0Additionally, client identifiers are generally issued uniquely= per
=C2=A0 =C2=A0registration request, even for the same instance of software.= =C2=A0 In
=C2=A0 =C2=A0this way, an application could marginally improve privacy by =C2=A0 =C2=A0registering multiple times and appearing to be completely sepa= rate
=C2=A0 =C2=A0applications.=C2=A0 However, this technique does incur signifi= cant
=C2=A0 =C2=A0usability cost in the form of requiring multiple authorization= s per
=C2=A0 =C2=A0resource owner and is therefore unlikely to be used in practic= e.


Hopefully this is more clear now.

Thanks for the feedback and close review,
=C2=A0=E2=80=94 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 resou= rce 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.=C2=A0 The client_id and s= ecret prevent that from being used in a different client if the bearer toke= n leaks.
>
> Remember the client_id is going to be different at different AS as eac= h will have a separate registration.
> If the client_id was fixed across multiple AS then it would be a corre= lation 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 wh= at 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 a= nd
>> 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=E2=80=99ll incorporate this feedback into another draft, to = be posted by the
>>> end of the week. Thanks everyone!
>>>
>>> =E2=80=94 Justin
>>>
>>>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>>>> <ka= thleen.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@ve7= jtb.com>> wrote:
>>>>
>>>>=C2=A0 =C2=A0snip
>>>>>=C2=A0 =C2=A0On Feb 18, 2015, at 6:46 AM, Kathleen Mori= arty
>>>>>=C2=A0 =C2=A0<kathleen.moriarty.ietf@gmail.com
>>>>>=C2=A0 =C2=A0<mailto:kathleen.moriarty.ietf@gmail.com>> wrote: >>>>>
>>>>>> The client_id *could* be short lived, but they usu= ally aren't. I don't see any particular logging or tracking concern= s using a dynamic OAuth client above using any other piece of software, eve= r. As such, I don't think it requires special calling out here.
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0Help me understand why there should not be= text that shows this
>>>>>=C2=A0 =C2=A0is not an issue or please propose some tex= t.=C2=A0 This is bound to
>>>>>=C2=A0 =C2=A0come up in IESG reviews if not addressed u= p front.
>>>>>
>>>>>
>>>>
>>>>=C2=A0 =C2=A0The client_id is used to communicate to the Au= thorization server
>>>>=C2=A0 =C2=A0to get a code or refresh token.=C2=A0 Those to= kens uniquely identify
>>>>=C2=A0 =C2=A0the user from a privacy perspective.
>>>>=C2=A0 =C2=A0It is the access tokens that are sent to the R= S and those can and
>>>>=C2=A0 =C2=A0should be rotated, but the client)id is not se= nt to the RS in
>>>>=C2=A0 =C2=A0OAuth as part of the spec.
>>>>
>>>>=C2=A0 =C2=A0If you did rotate the client_id then the AS wo= uld track it across
>>>>=C2=A0 =C2=A0rotations, so it wouldn=E2=80=99t really achie= ve anything.
>>>>
>>>>=C2=A0 =C2=A0One thing we don=E2=80=99t do is allow the cli= ent to specify the
>>>>=C2=A0 =C2=A0client_id, that could allow correlation of the= client across
>>>>=C2=A0 =C2=A0multiple AS and that might be a privacy issue,= but we don=E2=80=99t allow it.
>>>>
>>>>
>>>> Thanks, John.=C2=A0 It may be helpful to add in this expla= nation unless
>>>> there is some reason not to?
>>>>
>>>>
>>>>=C2=A0 =C2=A0John B.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Best regards,
>>>> Kathleen
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org <m= ailto: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
>




--
=

Best regards,
Kathleen
--047d7b3433da3d05310510505c19--