Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
Bill Burke <bburke@redhat.com> Tue, 24 February 2015 23:59 UTC
Return-Path: <bburke@redhat.com>
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 BB1071A036A for <oauth@ietfa.amsl.com>; Tue, 24 Feb 2015 15:59:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.312
X-Spam-Level:
X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 hVpIiRvLaFQb for <oauth@ietfa.amsl.com>; Tue, 24 Feb 2015 15:59:05 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1A21A0058 for <oauth@ietf.org>; Tue, 24 Feb 2015 15:59:05 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1ONx4BG006737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <oauth@ietf.org>; Tue, 24 Feb 2015 18:59:04 -0500
Received: from [10.10.51.118] (vpn-51-118.rdu2.redhat.com [10.10.51.118]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1ONx3Fc028086 for <oauth@ietf.org>; Tue, 24 Feb 2015 18:59:04 -0500
Message-ID: <54ED1047.2010408@redhat.com>
Date: Tue, 24 Feb 2015 18:59:03 -0500
From: Bill Burke <bburke@redhat.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: oauth@ietf.org
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> <CAHbuEH79CvMDtzmi7C3K+K=zAKD+pQ_k_qb8_ySYAZJucuO18w@mail.gmail.com> <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/lXTSevAjG2XdqVzMkAMyGnZwL-Q>
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: Tue, 24 Feb 2015 23:59:07 -0000
Is there plans to derive from any other parts of openid connect and bring them into IETF/OAuth? Thanks. On 2/24/2015 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’t aware of it – the > reason that it’s OK to produce derivative works from OpenID specs, as > draft-ietf-oauth-dyn-reg did, is that it’s explicitly allowed by the > OpenID Foundation. See this text at > http://openid.net/specs/openid-connect-registration-1_0.html#Notices – > 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, > and (ii) implementing Implementers Drafts and Final Specifications based > on such documents, provided that attribution be made to the OIDF as the > source of the material, but that such attribution does not indicate an > endorsement by the OIDF. > > You could pass that on to the appropriate IETF legal counsel if they’re > not already aware of it. > > -- 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 > 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 <mailto: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> > >> <mailto: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> > >> <mailto: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> > >>> <mailto: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> <mailto:OAuth@ietf.org > <mailto:OAuth@ietf.org>> > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > Best regards, > > Kathleen > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
- [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