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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 18 February 2015 15:30 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 1A5DF1ABB19 for <oauth@ietfa.amsl.com>; Wed, 18 Feb 2015 07:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 UC-zJQxEhS6t for <oauth@ietfa.amsl.com>; Wed, 18 Feb 2015 07:30:23 -0800 (PST)
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (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 6D5AD1ABC74 for <oauth@ietf.org>; Wed, 18 Feb 2015 07:30:22 -0800 (PST)
Received: by labms9 with SMTP id ms9so1810331lab.10 for <oauth@ietf.org>; Wed, 18 Feb 2015 07:30:21 -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=QL+qm7ndW1G5MYqVh6BLQubf4EnM2f2o0Yp0x1cuTVw=; b=wkrGukqxjbXwHH/h6ZazAyMrUYDTLDbSB/gSs/JMIjfMTTyV44r+XXY1/3GRRa6/ed DPQWWjOE3Zk6bgm+7SJO2pGmH9KoOUtB9V4d5Dz/hn1j14zk2avxXHtcgJxB5aOIDJAS sddni3u69gFGgWLQMCjdjHAjElQJMLJTxlNAyNa57DNTGGeNF6L6O8QYaNiytQLT74Is t3Po7BlcNZ1BIeMA0b7zD/Rt1Gkv9nQYSgVmNt3WQ49c2wtMMtcM4x9LB54Mm5EBgiCJ iMEnOm9NGPwd41trpfzxvZpgNy34YMzAx/313Y/nTiBMpU9xH24OPUd8xd2oVed8Zbgx OcJg==
MIME-Version: 1.0
X-Received: by 10.152.8.229 with SMTP id u5mr4828158laa.4.1424273421017; Wed, 18 Feb 2015 07:30:21 -0800 (PST)
Received: by 10.112.167.101 with HTTP; Wed, 18 Feb 2015 07:30:20 -0800 (PST)
In-Reply-To: <1766F429-C82D-471D-BCE9-F8E5F234CE3C@ve7jtb.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>
Date: Wed, 18 Feb 2015 10:30:20 -0500
Message-ID: <CAHbuEH4Pa6N5YMP=5f0W24nPsQ8aGPqL8sHOaspE5A1K8Gui4Q@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=089e0158ab6052a9ad050f5e7f2e
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/g50XWlG5sDOLG6jtbP_zcl6yGNQ>
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, 18 Feb 2015 15:30:26 -0000

On Wed, Feb 18, 2015 at 10:07 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> snip
>
> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty <
> 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