Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10

Justin Richer <jricher@mitre.org> Mon, 20 May 2013 15:45 UTC

Return-Path: <jricher@mitre.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1171521F92F4 for <oauth@ietfa.amsl.com>; Mon, 20 May 2013 08:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.232
X-Spam-Level:
X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q70bHNdlHASr for <oauth@ietfa.amsl.com>; Mon, 20 May 2013 08:45:51 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8D24421F92E3 for <oauth@ietf.org>; Mon, 20 May 2013 08:45:51 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D813C1F06D8; Mon, 20 May 2013 11:45:50 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AEE0E1F0664; Mon, 20 May 2013 11:45:50 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 20 May 2013 11:45:50 -0400
Message-ID: <519A4512.9080905@mitre.org>
Date: Mon, 20 May 2013 11:45:22 -0400
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Phil Hunt <phil.hunt@oracle.com>
References: <C0CE9538-4B72-4882-9462-B08A2D386720@oracle.com> <51965446.2070404@mitre.org> <84E4E4E6-EA02-4141-BA6D-77A0B3F76E7A@oracle.com> <3701BFCE-3D0F-45A3-955E-7486904B98B3@ve7jtb.com> <99D23FB9-19C3-40DF-9989-30F6686091DA@oracle.com>
In-Reply-To: <99D23FB9-19C3-40DF-9989-30F6686091DA@oracle.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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, 20 May 2013 15:45:58 -0000

On 05/17/2013 07:29 PM, Phil Hunt wrote:
> He's saying every client gets a registration token and a client token.
>
What's a "client token", exactly? There are three potential places for 
OAuth tokens in and around dynamic registration, and none of them are 
called "client token".

1) The registration access token, which binds a "client" (or "instance 
of a client", if you will) to a set of registration information at a 
specific authorization server. The client uses this to call its Client 
Information Endpoint to do updates, refreshes, and potentially delete 
itself. This token is *only* good at this Client Information Endpoint, 
and nowhere else. This token is specific to the registration it represents.

2) The (optional) initial token used to authenticate to the Client 
Registration Endpoint. This is *not* the registration access token, and 
it is *not* used to access the Client Information Endpoint. How the 
client or developer get this token is out of scope. How the registration 
server validates this token is out of scope. The structure and contents 
of this token are out of scope.

3) The access/refresh tokens that a registered client eventually gets 
from the Token Endpoint and uses with protected resources. These tokens 
aren't used at the Client Registration Endpoint or at the Client 
Information Endpoint.

There are also a couple of related concepts that aren't tokens at all:

4) The client_id, which is issued to a "client" (or "client instance") 
by the authorization server. This must be unique at the auth server for 
each client instance. The client uses this client_id at the 
Authorization Endpoint and the Token Endpoint in normal OAuth flows.

5) The client_secret, which is issued to a "client" (or "client 
instance") by the auth server, for confidential clients (ie: clients 
that can protect their client_secret). This is used by the client to 
authenticate to the Token Endpoint and nowhere else.


Which of these do you mean by a "client token"?

  -- Justin