Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 24 February 2015 23:53 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 DA86F1A036A for <oauth@ietfa.amsl.com>; 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 <oauth@ietfa.amsl.com>; 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 <oauth@ietf.org>; Tue, 24 Feb 2015 15:53:56 -0800 (PST)
Received: by labgd6 with SMTP id gd6so344297lab.8 for <oauth@ietf.org>; 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: <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>
Date: Tue, 24 Feb 2015 18:53:55 -0500
Message-ID: <CAHbuEH6UmVZruCf114UFcJVPHEXPawR47=GfhJESi6hURb-o8Q@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=089e0158ab60476389050fde3bc4
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/OEne768VwHq2u1rlyoOqqnKrUZU>
Cc: "oauth@ietf.org" <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 <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:54:00 -0000

Hi Mike,

On Tue, Feb 24, 2015 at 6:47 PM, Mike Jones <Michael.Jones@microsoft.com>
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.
>

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 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’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>> wrote:
> >>
> >>
> >>
> >> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <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>> 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>
> >> https://www.ietf.org/mailman/listinfo/oauth
>
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>



-- 

Best regards,
Kathleen