Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

Phil Hunt <phil.hunt@oracle.com> Thu, 06 June 2013 15:20 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 5F8CD21F93D4 for <oauth@ietfa.amsl.com>; Thu, 6 Jun 2013 08:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level:
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HehRu8wkaBie for <oauth@ietfa.amsl.com>; Thu, 6 Jun 2013 08:20:13 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB5B21F9349 for <oauth@ietf.org>; Thu, 6 Jun 2013 08:20:13 -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 r56FK9MU012144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Jun 2013 15:20:10 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 r56FKA4R005080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 15:20:10 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r56FK9mV025447; Thu, 6 Jun 2013 15:20:09 GMT
Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Jun 2013 08:20:09 -0700
References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com> <B33BFB58CCC8BE4998958016839DE27E08F97708@IMCMBX01.MITRE.ORG> <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com> <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <F293690C-1E82-4350-80D4-2E2C0EF86E55@oracle.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <F319CA95-B5A8-4BD5-A8BA-F57BCBA6806B@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <CA+ZpN24S9fEfFsgMtu8pN-ct-100+HVSHAfqO4Yy2SksrYt1eA@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1151B105DA5@WSMSG3153V.srv.dir.telstra.com> <CA+ZpN25_tguPtPDkt! m M8q=72EgnesignTuWE19wi61gCTLLL_g@mail.gmail.com> <1373E8CE237FCC43BCA36C6558612D2A9F26D0@USCHMBX001.nsn-intra.net> <919FB49B-2705-42E4-B5C3-B433C3F81C7F@ve7jtb.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <919FB49B-2705-42E4-B5C3-B433C3F81C7F@ve7jtb.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-622D69C7-8447-4DC6-84B1-DF10418C9A8C"
Content-Transfer-Encoding: 7bit
Message-Id: <9209089C-5B60-4212-88EA-376855DBCEA0@oracle.com>
X-Mailer: iPhone Mail (10B329)
From: Phil Hunt <phil.hunt@oracle.com>
Date: Thu, 06 Jun 2013 08:20:08 -0700
To: John Bradley <ve7jtb@ve7jtb.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens
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, 06 Jun 2013 15:20:23 -0000

As I've said before the initial auth token should nothing to do with auth. It is simply an assertion given to the developer to distribute in order to pass on signed claims about the software. 

Bearer or not bearer is a distraction. The fact that the contents and format of this token is out of scope leaves a HUGE interop gap. 

Finally never-mind bearer bias, how are  client credentials rotated interoperably if the only thing rotated is client_secret?

I would say the spec only works for client secrets and/or all-in-one domain where there is no interop. 

Phil

On 2013-06-06, at 1:53, John Bradley <ve7jtb@ve7jtb.com> wrote:

> There are a couple of reasons.    
> 
> One criticism Hannes and others make of OAuth specs is they are not tightly profiled enough to be interoperable without further out of band configuration and profiling.
> 
> Making registration work with minimal ambiguity was a priority for Connect and that has carried over.
> 
> I am not opposed to having this extended at some point in the future, once we have a second token type.   The new token type should be available to do updates as well.
> 
> The problem is that starting down the HoK route potentially requires a registered client that may need to be registered to do the registration.   
> I think that is best left to another spec to sort out the possible turtles.
> 
> So the default needs to be bearer tokens unless registration is extended by another profile.
> 
> John B.
> On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> wrote:
> 
>> Because bearer tokens have a stable RFC-numbered spec and are widely implemented and the registration flow as documented seems like it should work?  -T
>>  
>> That’s the answer for why there is support for bearer tokens but it is not the answer to why that’s the only supported mechanism.
>> If we want to support stronger security mechanisms (which the group has decided to work on already) then we need to have a story on how to support the other mechanisms as well .
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth