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 DA86F1A036A for ; Tue, 24 Feb 2015 15:53:59 -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 i5fraRj2-WvC for ; Tue, 24 Feb 2015 15:53:57 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (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 DDD821A0058 for ; Tue, 24 Feb 2015 15:53:56 -0800 (PST) Received: by labgd6 with SMTP id gd6so344297lab.8 for ; Tue, 24 Feb 2015 15:53:55 -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=2bPfxkBJbk9Yc4d1pk3izLQOSV5/BLp57rDNLBdmh3Y=; b=c51LpN9bj/XTUaL55xoDiKQ5klNVpZlSqd0r9WHoAxqHDrxyofW/F5bGMGnShXPp3x YeKRyvVX1CKhx/5bFY6C1GHsdakdu0CValXUXkRW5kQpQWaotzorfIbl1+k/1KcE1+Gx Wyync71kH0YlNOepNhBxvVq4Ax7+GwkV4BE9sTvl884tyy0YWsNUDLLK4XYcJNPtQ0VT CrczpqEu212B0CASOOqe6olRuZuB3qqtPPrmuuMZr7RqJ0upoCZnto8FocTcTbu7eCym J7A3i/ATg4ZM6gKBGOhiBuXJOYsBfwarlTEAE9b+CbxmNtdVFiLqcZ/JPENyFEgV5vzQ errQ== MIME-Version: 1.0 X-Received: by 10.152.8.229 with SMTP id u5mr429518laa.4.1424822035242; Tue, 24 Feb 2015 15:53:55 -0800 (PST) Received: by 10.112.167.101 with HTTP; Tue, 24 Feb 2015 15:53:55 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com> References: <54DC2CB1.8090400@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A222C933@TK5EX14MBXC290.redmond.corp.microsoft.com> <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.com> <54E4D2A5.5030705@gmx.net> <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com> Date: Tue, 24 Feb 2015 18:53:55 -0500 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: multipart/alternative; boundary=089e0158ab60476389050fde3bc4 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:54:00 -0000 --089e0158ab60476389050fde3bc4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mike, On Tue, Feb 24, 2015 at 6:47 PM, Mike Jones wrote: > Thanks, Kathleen. This had been discussed on the OAuth list before, but > just in case you or the IETF legal counsel weren=E2=80=99t aware of it = =E2=80=93 the reason > that it=E2=80=99s OK to produce derivative works from OpenID specs, as > draft-ietf-oauth-dyn-reg did, is that it=E2=80=99s explicitly allowed by = the OpenID > Foundation. See this text at > http://openid.net/specs/openid-connect-registration-1_0.html#Notices =E2= =80=93 > the spec from which text was copied: > > > > The OpenID Foundation (OIDF) grants to any Contributor, developer, > implementer, or other interested party a non-exclusive, royalty free, > worldwide copyright license to reproduce, prepare derivative works from, > distribute, perform and display, this Implementers Draft or Final > Specification solely for the purposes of (i) developing specifications, a= nd > (ii) implementing Implementers Drafts and Final Specifications based on > such documents, provided that attribution be made to the OIDF as the sour= ce > of the material, but that such attribution does not indicate an endorseme= nt > by the OIDF. > > > > You could pass that on to the appropriate IETF legal counsel if they=E2= =80=99re > not already aware of it. > Thank you. This was in Hannes message that I sent to the trust to review already. I'll chat with the chairs when they resurface from day jobs/travel and we will figure this out. Thanks, Kathleen > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Kathleen > Moriarty > *Sent:* Tuesday, February 24, 2015 3:08 PM > *To:* Hannes Tschofenig > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg > > > > Hello, > > > > Thanks for updating the draft. I just want to confirm that Hannes is oka= y > 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 fro= m > UMA and OpenID. The text from UMA went into an IETF draft, so that shoul= d > be the reference as it clears up any possible issues as they provided tha= t > 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 > > > > > > > > -- > > > > Best regards, > > Kathleen > --=20 Best regards, Kathleen --089e0158ab60476389050fde3bc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mike,

On Tue, Feb 24, 2015 at 6:47 PM, Mike Jones <<= a href=3D"mailto:Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jon= es@microsoft.com> wrote:

Thanks, Kathleen.=C2=A0 T= his had been discussed on the OAuth list before, but just in case you or th= e IETF legal counsel weren=E2=80=99t aware of it =E2=80=93 the reason that = it=E2=80=99s OK to produce derivative works from OpenID specs, as draft-ietf-oauth-dyn-= reg did, is that it=E2=80=99s explicitly allowed by the OpenID Foundation.= =C2=A0 See this text at http://openid.net/specs/openid-connect-registration= -1_0.html#Notices =E2=80=93 the spec from which text was copied:=

=C2=A0

The OpenID Foundation (OIDF) grants to any Contributor, devel= oper, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative= works from, distribute, perform and display, this Implementers Draft or Fi= nal Specification solely for the purposes of (i) developing specifications,= and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that att= ribution be made to the OIDF as the source of the material, but that such a= ttribution does not indicate an endorsement by the OIDF.

=C2=A0

You could pass that on to= the appropriate IETF legal counsel if they=E2=80=99re not already aware of= it.


Thank you.=C2= =A0 This was in Hannes message that I sent to the trust to review already.= =C2=A0 I'll chat with the chairs when they resurface from day jobs/trav= el and we will figure this out.

Thanks,
= Kathleen

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of Kathleen Moriarty
Sent: Tuesday, February 24, 2015 3:08 PM
To: Hannes Tschofenig
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

=C2=A0

Hello,

=C2=A0

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

=C2=A0

This is getting held up a bit while we sort through = copyright of text from 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 i= ssues as they provided that text in an IETF draft. =C2=A0

=C2=A0

The chairs will be helping to sort out the requireme= nts with OpenID, per our discussions the IETF trustees.=C2=A0 I'm not s= ure how long this will take, but wanted to provide a status so no one thoug= ht this had been dropped.

=C2=A0

Thanks.

=C2=A0

On Wed, Feb 18, 2015 at 12:57 PM, Hannes Tschofenig = <hannes.t= schofenig@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 poste= d 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.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:
>>
>>=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.com&= gt;> 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= <mailto:OAuth@i= etf.org>
>> https://www.ietf.org/mailman/listinfo/oauth

>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>



=C2=A0

--

=C2=A0

Best regards,

Kathleen




--

Best regards,
Kath= leen
--089e0158ab60476389050fde3bc4--