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 700AF1A0070 for ; Tue, 24 Feb 2015 15:07:48 -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 1lMk7aBgw-f3 for ; Tue, 24 Feb 2015 15:07:46 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 30F6C1A9069 for ; Tue, 24 Feb 2015 15:07:46 -0800 (PST) Received: by lbiz11 with SMTP id z11so190858lbi.5 for ; Tue, 24 Feb 2015 15:07:44 -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=d/HRCRdAd5ErcHaa7C/SnAFTSH2mrinBsp5WPbz00jE=; b=ZbcDE+VPUz5y8FnGyHMEvUqyICdKmN9mO5D2DEvOdKe5OuthzPVfqE2M1/OkrZSuDC IUdIc8ySspbqw7fd4Jn0MqztH8ilgyskqP4nhOGCQ+vBjzUbiicZJuRdK8BF3YjaI2V5 gPtXLV19HiXZsZq39zhOEC/YiKUbdqZIRCg+jJhwTHxUxXobePYLrMI79HdY7Qpw5zu9 m7mnp6PXGgcx4X6aYtaZjqkxy3OZpXWMsM0r6nz/EfBtoapS6FfiBezJ2Ewvl9Ay+d6Y DZefTxqCNKD/Pck/BaQCgLzFm+gsLz559WMh0VUGc9CsMvaQCivCG0ENkCOanD4R1nYs UvRA== MIME-Version: 1.0 X-Received: by 10.112.97.106 with SMTP id dz10mr311903lbb.4.1424819264531; Tue, 24 Feb 2015 15:07:44 -0800 (PST) Received: by 10.112.167.101 with HTTP; Tue, 24 Feb 2015 15:07:44 -0800 (PST) In-Reply-To: <54E4D2A5.5030705@gmx.net> References: <54DC2CB1.8090400@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com> <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com> <54E4D2A5.5030705@gmx.net> Date: Tue, 24 Feb 2015 18:07:44 -0500 Message-ID: From: Kathleen Moriarty To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11345b1221b1b4050fdd96d6 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: Tue, 24 Feb 2015 23:07:48 -0000 --001a11345b1221b1b4050fdd96d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Thanks for updating the draft. I just want to confirm that Hannes is okay with the updated definitions and updates the shepherd report to reflect that. This is getting held up a bit while we sort through copyright of text from UMA and OpenID. The text from UMA went into an IETF draft, so that should be the reference as it clears up any possible issues as they provided that text in an IETF draft. The chairs will be helping to sort out the requirements with OpenID, per our discussions the IETF trustees. I'm not sure how long this will take, but wanted to provide a status so no one thought this had been dropped. Thanks. On Wed, 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=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 > >> >> > 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 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=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 > > > > --=20 Best regards, Kathleen --001a11345b1221b1b4050fdd96d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Thanks for updating the draft.= =C2=A0 I just want to confirm that Hannes is okay with the updated definiti= ons and updates the shepherd report to reflect that.

This is getting held up a bit while we sort through copyright of text fr= om UMA and OpenID.=C2=A0 The text from UMA went into an IETF draft, so that= should be the reference as it clears up any possible issues as they provid= ed that text in an IETF draft. =C2=A0

The chairs w= ill be helping to sort out the requirements with OpenID, per our discussion= s the IETF trustees.=C2=A0 I'm not sure how long this will take, but wa= nted to provide a status so no one thought this had been dropped.

Thanks.

On Wed, 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=E2=80=99ll incorporate this feedback into an= other draft, to be posted by the
> end of the week. Thanks everyone!
>
>=C2=A0 =E2=80=94 Justin
>
>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>> <kathleen.m= oriarty.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:
>>
>>=C2=A0 =C2=A0 =C2=A0snip
>>>=C2=A0 =C2=A0 =C2=A0On Feb 18, 2015, at 6:46 AM, Kathleen Moria= rty
>>>=C2=A0 =C2=A0 =C2=A0<kathleen.moriarty.ietf@gmail.com
>>>=C2=A0 =C2=A0 =C2=A0<mailto:kathleen.moriarty.ietf@gmail.c= om>> wrote:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> The client_id *could* be= short lived, but they usually aren't. I don't see any particular l= ogging or tracking concerns using a dynamic OAuth client above using any ot= her piece of software, ever. As such, I don't think it requires special= calling out here.
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0Help me understand why there should not be = text that shows this
>>>=C2=A0 =C2=A0 =C2=A0is not an issue or please propose some text= .=C2=A0 This is bound to
>>>=C2=A0 =C2=A0 =C2=A0come up in IESG reviews if not addressed up= front.
>>>
>>>
>>
>>=C2=A0 =C2=A0 =C2=A0The client_id is used to communicate to the Aut= horization server
>>=C2=A0 =C2=A0 =C2=A0to get a code or refresh token.=C2=A0 Those tok= ens uniquely identify
>>=C2=A0 =C2=A0 =C2=A0the user from a privacy perspective.
>>=C2=A0 =C2=A0 =C2=A0It is the access tokens that are sent to the RS= and those can and
>>=C2=A0 =C2=A0 =C2=A0should be rotated, but the client)id is not sen= t to the RS in
>>=C2=A0 =C2=A0 =C2=A0OAuth as part of the spec.
>>
>>=C2=A0 =C2=A0 =C2=A0If you did rotate the client_id then the AS wou= ld track it across
>>=C2=A0 =C2=A0 =C2=A0rotations, so it wouldn=E2=80=99t really achiev= e anything.
>>
>>=C2=A0 =C2=A0 =C2=A0One thing we don=E2=80=99t do is allow the clie= nt to specify the
>>=C2=A0 =C2=A0 =C2=A0client_id, that could allow correlation of the = client across
>>=C2=A0 =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 explanation u= nless
>> there is some reason not to?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0John B.
>>
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <ma= ilto: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
--001a11345b1221b1b4050fdd96d6--