[OAUTH-WG] Dynamic Client Registration Management

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 12 January 2015 15:10 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 B17D01AC3AD for <oauth@ietfa.amsl.com>; Mon, 12 Jan 2015 07:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 fbvrz_UBlR7Q for <oauth@ietfa.amsl.com>; Mon, 12 Jan 2015 07:10:17 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C043D1AC39D for <oauth@ietf.org>; Mon, 12 Jan 2015 07:10:16 -0800 (PST)
Received: from [172.16.254.109] ([80.92.123.55]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MaE4a-1YUQPO1oEa-00JqzT for <oauth@ietf.org>; Mon, 12 Jan 2015 16:10:14 +0100
Message-ID: <54B3E3D5.9040502@gmx.net>
Date: Mon, 12 Jan 2015 16:10:13 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "oauth@ietf.org" <oauth@ietf.org>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="mTUaaJnoF9U347rSorCDrju2nIA1kwEbA"
X-Provags-ID: V03:K0:SvCYmVoBHMt9tA8JE9klj7dz6ULfBeySo0fmkt2QToYoIZG6J21 djLrbbs7aLbP2MbjztA4ST/9mG3PRfBOqEIHpOxok8eEUloNXw2+MHB2/X9uCMzrrv2rQHO Br9tPiyGh5ytaGLLZj+o5rMCMb7atkskWq7jUQJDIKRjCYLnoo8hy1yNjZx1/AF+Xe5dZan KDm8g9cMm1tj/6rxk3XXw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/N64XPe92jtDAbeRb5WSA-dc4iDE>
Subject: [OAUTH-WG] Dynamic Client Registration Management
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: Mon, 12 Jan 2015 15:10:25 -0000

Hi Justin, Hi all,

I re-read the latest version of the dynamic client registration
management document and I still have a few issues with the document.

Let me start with the document structure.

When you look at the ToC you will notice that there is something wrong.

   2.  Client Configuration Endpoint . . . . . . . . . . . . . . . .   5
     2.1.  Client Read Request . . . . . . . . . . . . . . . . . . .   6
     2.2.  Client Update Request . . . . . . . . . . . . . . . . . .   6
     2.3.  Client Delete Request . . . . . . . . . . . . . . . . . .   9
   3.  Responses . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.1.  Client Information Response . . . . . . . . . . . . . . .  10
	
Figure 1 describes a number of request and responses, namely
* Client Registration Request and Client Information Response
* Read or Update Request and Client Information Response
* Delete Request and Delete Confirmation

Section 3 only covers the "Client Information Response".

It would of course been cleaner to have a response that matches the
request. This avoids confusion. But that's where we are right now.

Currently, most of the response message content is actually described in
Section 2 rather than in Section 3.

You may want to think about re-structure the text in the following way.
This would also cause you to re-think a lot of the data duplication issue.

For example, an update request requires the client to re-submit all data
and then, in the response, the authorization server has to submit a lot
of the data back to the client again (even if it does not change it).
That does not sound right to me.


   2.  Client Configuration Endpoint
     2.1. Client Registration Request and Client Information Response
     2.2. Client Read Request and Client Information Response
     2.3. Client Update Request and Client Information Response
     2.4. Client Delete Request and Delete Confirmation
	 	

Appendix B.  Registration Tokens and Client Credentials

   Throughout the course of the dynamic registration protocol, there are
   three different classes of credentials in play, each with different
   properties and targets.

   o  The initial access token is optionally used by the client or
      developer at the registration endpoint.

s/client or developer/client

	  This is an OAuth 2.0
      token that is used to authorize the initial client registration
      request.  The content, structure, generation, and validation of
      this token are out of scope for this specification.  The
      authorization server can use this token to verify that the
      presenter is allowed to dynamically register new clients.  This
      token may be shared among multiple instances of a client to allow
      them to each register separately, thereby letting the
      authorization server use this token to tie multiple instances of
      registered clients (each with their own distinct client
      identifier) back to the party to whom the initial access token was
      issued, usually an application developer.  This token should be
      used only at the client registration endpoint.

[hannes] Is this correct? "should only be used at the client
registration endpoint"
It would be better to say that this must only be used at the client
registration endpoint since that was the purpose for creating it.

   o  The registration access token is used by the client or developer
      at the client configuration endpoint and represents the holder's
      authorization to manage the registration of a client.

s/client or developer/client

	  This is an
      OAuth 2.0 bearer token that is issued from the client registration
      endpoint in response to a client registration request and is
      returned in a client information response.  The registration
      access token is uniquely bound to the client identifier and is
      required to be presented with all calls to the client
      configuration endpoint.  The registration access token should be
      protected and should not be shared between instances of a client
      (otherwise, one instance could change or delete registration
      values for all instances of the client).

[hannes] The registration access token must be confidentiality protected
in transit and also protected against unauthorized access when stored
locally on the client.

In what cases do you envision the registration access token to be shared
among client instances?

	  The registration access
      token can be rotated through the use of the client update method
      on the client configuration endpoint.  The registration access
      token should be used only at the client configuration endpoint.

[hannes] Why 'should' and not 'must'? Again, we create this registration
access token specifically for the use with the client configuration
endpoint.	
	
   o  The client credentials (such as "client_secret") are optional
      depending on the type of client and are used to retrieve OAuth
      tokens.

[Hannes] Proposed text: "The use of client credentials (such as
"client_secret") is optional
      and depends on the type of client."

	  Client credentials are most often bound to particular
      instances of a client and should not be shared between instances.
      Note that since not all types of clients have client credentials,
      they cannot be used to manage client registrations at the client
      configuration endpoint.  The client credentials can be rotated
      through the use of the client update method on the client
      configuration endpoint.  The client credentials cannot be used for
      authentication at the client registration endpoint or at the
      client configuration endpoint.

[hannes] Why do you mean that they cannot be used for authentication?
What happens if a client uses a client credential in the interaction
with these endpoints?

B.1.  Credential Rotation

   The authorization server MAY rotate the client's registration access
   token and/or client credentials (such as a "client_secret")
   throughout the lifetime of the client in order to minimize the risk
   of leakage of these credentials.

[Hannes] Proposed text: "The authorization server may be configured to
issue new registration access
   tokens and/or client credentials (such as a "client_secret") to the
client
   throughout the lifetime of the client instance to limit the lifetime
of the credentials.
   This may help to minimize impact of exposed credentials."

[Hannes] Note also that the registration access token is a mandatory
field in the client information response and so it appears that this
rotation in some sense happens with every request/response unless the
authorization server returns the same info all the time (which would be
very wasteful).

   The client can discover that these
   values have changed by reading the client information response
   returned from either a read or update request to the client
   configuration endpoint.

[Hannes] Proposed Text: "The authorization server conveys new new
registration access
   tokens and/or client credentials to the client in the client
information response of
   either a read or update request to the client configuration endpoint."

   The client's current registration access
   token and client credentials (if applicable) MUST be included in this
   response.

[Hannes] Shouldn't that read "The client's current registration access
   token and client credentials (if applicable) MUST be included in the
request."

   The registration access token SHOULD be rotated only in response to
   an update request to the client configuration endpoint, at which
   point the new registration access token is returned to the client and
   the old registration access token SHOULD be discarded by both
   parties.

[Hannes] We talked about the second SHOULD statement here on the mailing
list before. I thought I convinced you to either turn it into a MUST or
to tell the reader when to discard and it when it should not be discarded.

If you additionally take the text in Section 2.2 into account the entire
story is inconsistent. Here is the text:

" If the
   authorization server includes a new client secret and/or registration
   access token in its response, the client MUST immediately discard its
   previous client secret and/or registration access token.  The value
   of the "client_id" MUST NOT change from the initial registration
   response.
"


Also the first SHOULD statement raises the question why it is there. Of
course, it makes no sense to rotate the credential with a delete
request. Is this what you are trying to say? I don't see why the
registration access token cannot be rotated in response to a read request.

   If the registration access token were to expire or be
   rotated outside of such requests, the client or developer might be
   locked out of managing the client's configuration.

   Methods by which the client can request credential rotation are
   outside the scope of this document.

[Hannes] Proposed text: "Note that the authorization server decides
about frequency of credential rotation and not the client."

Ciao
Hannes