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