Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

Phil Hunt <phil.hunt@oracle.com> Thu, 30 May 2013 15:52 UTC

Return-Path: <phil.hunt@oracle.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 6595621F939E for <oauth@ietfa.amsl.com>; Thu, 30 May 2013 08:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.518
X-Spam-Level:
X-Spam-Status: No, score=-4.518 tagged_above=-999 required=5 tests=[AWL=-1.615, BAYES_00=-2.599, MANGLED_CREDIT=2.3, MIME_QP_LONG_LINE=1.396, 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 Z+a+VLS1rzgT for <oauth@ietfa.amsl.com>; Thu, 30 May 2013 08:52:51 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9B99D21F93E6 for <oauth@ietf.org>; Thu, 30 May 2013 08:52:47 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4UFqhw4029155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 May 2013 15:52:44 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UFqiHa029147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 15:52:44 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4UFqhdA001072; Thu, 30 May 2013 15:52:43 GMT
Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 May 2013 08:52:43 -0700
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <5071FA1C-F6F7-43AD-9EDC-13B0D480F97A@mitre.org> <51A3AE0B.1020802@lodderstedt.net> <51A4BF27.50800@mitre.org> <51A72B3E.9050300@lodderstedt.net> <51A76052.6040004@mitre.org> <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <0354062A-DEB8-4272-861B-43DC48887F54@ve7jtb.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E872A80-1B5B-468D-910C-1D6E9DFEFF78@oracle.com>
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt <phil.hunt@oracle.com>
Date: Thu, 30 May 2013 08:52:28 -0700
To: John Bradley <ve7jtb@ve7jtb.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
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: Thu, 30 May 2013 15:52:57 -0000

No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata. 

See we are confused. Hence my worry. :-)

Phil

On 2013-05-30, at 8:48, John Bradley <ve7jtb@ve7jtb.com> wrote:

> I think Phil also had some processing reason why a Token endpoint or RS wouldn't want to tale the authentication as a header, as the processing was easier with them as parameters as they are potentially available to different parts of the stack.   That may have been mostly around RS, but the principal may apply to the token endpoint as well.
> 
> On 2013-05-30, at 10:21 AM, Justin Richer <jricher@mitre.org> wrote:
> 
>>>>> 
>>>>> "client_secret_post vs client_secret_basic"
>>>>> BASIC and POST are essentially the same just different ways to send the client secret. If an authorization server supports both, both should work for any client. So are both methods treated differently?
>>>> I agree, and this was one of my original arguments for making this field plural (or plural-able), but there hasn't been WG support for that so far.
>>> 
>>> I'm not arguing to make it plural. I think the authentication method is just "client_secret".
>> 
>> That was also an option that was brought up, but in the OIDC WG the counter-argument was (as I recall) that the two are syntactically separate and there's a desire to restrict to a single type, such as disabling client_secret_post. Basically, to make it unambiguous.
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth