[OAUTH-WG] A couple of questions re dynamic client registration

Todd W Lainhart <lainhart@us.ibm.com> Fri, 25 October 2013 20:48 UTC

Return-Path: <lainhart@us.ibm.com>
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 BE7C111E81DC for <oauth@ietfa.amsl.com>; Fri, 25 Oct 2013 13:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 D3NvZqzx8Gq0 for <oauth@ietfa.amsl.com>; Fri, 25 Oct 2013 13:48:13 -0700 (PDT)
Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id 20DD411E8152 for <oauth@ietf.org>; Fri, 25 Oct 2013 13:47:58 -0700 (PDT)
Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <oauth@ietf.org> from <lainhart@us.ibm.com>; Fri, 25 Oct 2013 14:47:57 -0600
Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 25 Oct 2013 14:47:56 -0600
Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 8692F38C8042 for <oauth@ietf.org>; Fri, 25 Oct 2013 16:47:54 -0400 (EDT)
Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by b01cxnp23032.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r9PKltW765863856 for <oauth@ietf.org>; Fri, 25 Oct 2013 20:47:55 GMT
Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r9PKlt1E027109 for <oauth@ietf.org>; Fri, 25 Oct 2013 16:47:55 -0400
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r9PKltAO027106 for <oauth@ietf.org>; Fri, 25 Oct 2013 16:47:55 -0400
To: IETF oauth WG <oauth@ietf.org>
MIME-Version: 1.0
X-KeepSent: 6CCBF50C:668DDA9B-85257C0F:0070D399; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3FP4 SHF39 May 13, 2013
Message-ID: <OF6CCBF50C.668DDA9B-ON85257C0F.0070D399-85257C0F.007240F4@us.ibm.com>
From: Todd W Lainhart <lainhart@us.ibm.com>
Date: Fri, 25 Oct 2013 16:47:53 -0400
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 10/25/2013 16:47:55, Serialize complete at 10/25/2013 16:47:55
Content-Type: multipart/alternative; boundary="=_alternative 007240F285257C0F_="
X-TM-AS-MML: No
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13102520-9332-0000-0000-000001EDAD8E
Subject: [OAUTH-WG] A couple of questions re dynamic client registration
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: Fri, 25 Oct 2013 20:48:24 -0000

I'm working off this document for our client registration: 
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-14 

Section 4 - Client Configuration Endpoint says this:

The client MUST use its registration access token in
   all calls to this endpoint as an OAuth 2.0 Bearer Token [RFC6750].

I'm trying to understand if I should provide a separate administrative 
endpoint for client configurations (i.e. accessible via an entity with 
admin credentials/privileges).  I think this language is telling me "yes". 
 What are the client options for read/update/delete should this access 
token be lost?  I read "none".

Section 4.1 - Section 4.1 says this:

The authorization server MUST provide the client with the fully
   qualified URL in the "registration_client_uri" element of the Client
   Information Response (Section 5.1).

I'm curious as to why this isn't returned in the Location header?






Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.com