IETF Logo Mail Archive

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

"Richer, Justin P." <jricher@mitre.org> Sat, 26 October 2013 16:20 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 28BCD11E81AD for <oauth@ietfa.amsl.com>; Sat, 26 Oct 2013 09:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.406
X-Spam-Level:
X-Spam-Status: No, score=-6.406 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 js+equIp770K for <oauth@ietfa.amsl.com>; Sat, 26 Oct 2013 09:20:36 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 72F4F11E81B0 for <oauth@ietf.org>; Sat, 26 Oct 2013 09:20:34 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DFF351F08C6; Sat, 26 Oct 2013 12:20:33 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D192C1F0557; Sat, 26 Oct 2013 12:20:33 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0158.001; Sat, 26 Oct 2013 12:20:33 -0400
From: "Richer, Justin P." <jricher@mitre.org>
To: Todd W Lainhart <lainhart@us.ibm.com>
Thread-Topic: [OAUTH-WG] A couple of questions re dynamic client registration
Thread-Index: AQHO0cOQAlOD5rtMX0qvoMmAzT0qjpoHbhwA
Date: Sat, 26 Oct 2013 16:20:32 +0000
Message-ID: <1F06FCA3-A492-46BA-9D3E-81B2BA526C98@mitre.org>
References: <OF6CCBF50C.668DDA9B-ON85257C0F.0070D399-85257C0F.007240F4@us.ibm.com>
In-Reply-To: <OF6CCBF50C.668DDA9B-ON85257C0F.0070D399-85257C0F.007240F4@us.ibm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.3.191]
Content-Type: multipart/alternative; boundary="_000_1F06FCA3A49246BA9D3E81B2BA526C98mitreorg_"
MIME-Version: 1.0
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [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: Sat, 26 Oct 2013 16:20:41 -0000

On Oct 25, 2013, at 1:47 PM, Todd W Lainhart <lainhart@us.ibm.com<mailto:lainhart@us.ibm.com>>
 wrote:

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<http://tools.ietf.org/html/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".

I would suggest it, or provide alternative mechanisms to access the endpoint. Our own implementation (MITREid) does the former. In our case, we also wanted a mechanism whereby our admins can edit the client id and client secret directly as needed, as well as support manual registration, neither of which are supported by the dynamic registration protocol (and that's on purpose).


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<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-14#section-5.1>).

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


Simply because we wanted it to be self-contained in the returned JSON object. We could, I suppose, also return it in the location header, which would follow REST principles a little better.

 -- Justin





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<mailto:lainhart@us.ibm.com>

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email