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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 25 February 2015 01:02 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 0CBB51A1A36 for <oauth@ietfa.amsl.com>; Tue, 24 Feb 2015 17:02:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 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, MIME_QP_LONG_LINE=0.001, 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 GUg5gGP8vdna for <oauth@ietfa.amsl.com>; Tue, 24 Feb 2015 17:02:07 -0800 (PST)
Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (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 4732F1A1A0B for <oauth@ietf.org>; Tue, 24 Feb 2015 17:02:07 -0800 (PST)
Received: by mail-qa0-f47.google.com with SMTP id v10so522873qac.6 for <oauth@ietf.org>; Tue, 24 Feb 2015 17:02:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5rwPwPQdhuDHpbHRyEB0Z5/TqsbrBhSCNUf0eootb+Q=; b=VkxLpGHpg0OgP6bbeqHNWySnrDH1C5q9VjWkX+qJdaFixo1ssudKt29NSTMcnyRV0s IknlIe0Z7AsaRaMG4l+1kPVD9YplybqAHhvmgWQqUDw0EcudW0dlYte0NaSW4w6fH0yY FQ2pNhmqJMLuqurnZiYy3vpBGaCTgecvTAv4mla2guFjdHBTxUYKoB52sm/vfXV4WVI3 +3QlCN1ZzOjfculaWKVK8HU/4Sy7DjOQ9ZbRZgIUKmfG9/dHX57qLG0HD50h8UNouVEv XOR2A8aEpN+dREALnFevnxVbzYT6q4N0JqWAVQVfzwvlz2w3c8Ef9gLTLj9qRGDCDhke RfLA==
X-Received: by 10.140.233.148 with SMTP id e142mr1530377qhc.15.1424826126486; Tue, 24 Feb 2015 17:02:06 -0800 (PST)
Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id 8sm426634qgk.33.2015.02.24.17.02.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Feb 2015 17:02:05 -0800 (PST)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Google-Original-From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-2D5E1D14-044E-4180-9C88-839B97A7E821"
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (11D257)
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2264EC6@TK5EX14MBXC290.redmond.corp.microsoft.com>
Date: Tue, 24 Feb 2015 20:02:01 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <3AAFF7CB-1C84-4BD5-B8BF-9162660BD57D@gmail.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>
To: Mike Jones <Michael.Jones@microsoft.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/ZSwAvcFjGVKiMGtTxulp9DBgxN8>
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: Wed, 25 Feb 2015 01:02:10 -0000

I was able to get a response, I'm guessing the question got too buried in the thread over the past few days.

Essentially, it is the contributors responsibility to ensure it's ok to include text.  If this was Mike or someone else that believe it is fine, then we can proceed.

Hannes may need to update the shepherd report and I'll read through the updated version tomorrow.  I'll try to get a review out if the accompanying management draft tomorrow too.

Thanks,
Kathleen 

Sent from my iPhone

> On 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.
>  
>                                                                 -- 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