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

John Bradley <> Wed, 18 February 2015 15:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 578211A893E for <>; Wed, 18 Feb 2015 07:08:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h5KgtGZheiQM for <>; Wed, 18 Feb 2015 07:08:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07E831A923D for <>; Wed, 18 Feb 2015 07:08:15 -0800 (PST)
Received: by pdjz10 with SMTP id z10so1748767pdj.0 for <>; Wed, 18 Feb 2015 07:08:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1g9ba2c3VEyzPtkc+bHty54xHwn8YKh4NDbNGymt6Ms=; b=JAwMCMLFvSn/F+DBOR3Sjkzo+d0+6dQBESGYF0FuigaCWcm188QOqoaMfXY3qQCJwN FyhNgXtRClzPz2VyJJBSckWggAR0DgBm0Kvs7/8+EWOADDPyF4Qeto9J3jzHB4GWkkCG 70nVKc7dKg44rtWHQLMiIBr53u8EN1tcXzPHylH94PGLvusZKt9+NP0QQfGkFE/m219m HgYV4aRKURHJWtaQhI9MovXEerlR3siE0dYOHaQTrJ+tOIBGjrktXttAEW1JAAEuVe2E CKE+aR7KBTyAs666zkZPboSXYUnOichdM83G8P0M1DeDZrL1EY99fEt+czjtNAL4rovB U7Hw==
X-Gm-Message-State: ALoCoQmunOTNq3Ure9vlLF6C1PIOR2iF+V8MFv47qg+n1JY5/4xsWWOVRLDwwDO1kiO3LP6Yw2B0
X-Received: by with SMTP id p2mr59987645pdr.0.1424272094675; Wed, 18 Feb 2015 07:08:14 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id gi6sm20826744pbd.93.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Feb 2015 07:08:13 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_12E6CA57-8905-4D03-A769-924BF9CE8B6E"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley <>
In-Reply-To: <>
Date: Wed, 18 Feb 2015 07:07:57 -0800
Message-Id: <>
References: <> <> <> <> <>
To: Kathleen Moriarty <>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Feb 2015 15:08:19 -0000

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

John B.