Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

"Phil Hunt (IDM)" <phil.hunt@oracle.com> Fri, 11 March 2016 03:18 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 80F0812DFD2 for <oauth@ietfa.amsl.com>; Thu, 10 Mar 2016 19:18:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NW2Oli3sAaos for <oauth@ietfa.amsl.com>; Thu, 10 Mar 2016 19:18:06 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74BD12DEF4 for <oauth@ietf.org>; Thu, 10 Mar 2016 19:18:06 -0800 (PST)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2B3I4U7030905 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Mar 2016 03:18:05 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2B3I4AO025524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Mar 2016 03:18:04 GMT
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2B3I4v5016565; Fri, 11 Mar 2016 03:18:04 GMT
Received: from [25.168.182.215] (/72.143.226.153) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 Mar 2016 19:18:03 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail-54E62AAE-06F5-4E34-AE93-A05C74478DCA"
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (13D20)
In-Reply-To: <CABzCy2D0P0NZW573g6NG3yYtbdVBifio=4hZi4QkYc3EKxOV5Q@mail.gmail.com>
Date: Thu, 10 Mar 2016 19:17:59 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <DADBDF61-8C6F-4E58-9A0A-6AAC7D3738EC@oracle.com>
References: <56C5C9D5.6040703@gmx.net> <D5D8B85B-68E6-4E88-89F7-88E6851381E4@adm.umu.se> <CA+k3eCQOX6DgiJFp4b0A8R0boVQxVwGJP2-dY8_TbrCpJowOtw@mail.gmail.com> <56E19B6D.6060509@connect2id.com> <64D743EA-3F8D-403B-B05E-74539124A847@oracle.com> <CABzCy2D0P0NZW573g6NG3yYtbdVBifio=4hZi4QkYc3EKxOV5Q@mail.gmail.com>
To: Nat Sakimura <sakimura@gmail.com>
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/DhuQRV__P_-ivoVdWI1GQ9asycU>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 11 Mar 2016 03:18:14 -0000

Nat,

Agree with your points. 

Regarding the last, I am not sure an AS should release the set of valid rs's. I think the returned data has to be limited somehow. Maybe by aud uri or maybe just a yes/no to a uri the client provides. This needs discussion. 

Am worried about the resource side discovery and how much we can intrude here. It may have similar issues disclosing approved ASs. 

Finally since we might not control rs discovery it may be possible that the discovery is fake. Maybe this is where something like software statements comes into play as it would at least prevent a mitm from changing the assertions in its discovery. It would not have the RS's private key and this signed statements might build trust.  

Phil

> On Mar 10, 2016, at 18:24, Nat Sakimura <sakimura@gmail.com> wrote:
> 
> Phil, 
> 
> Right. So what my conditional approvals (11 conditions in total) said was to drop the word "discovery" from everywhere. This is not a discovery spec. This is a configuration lookup spec as you correctly points out. So, I am with you here. 
> 
> Also, my 2nd conditiion is essentially saying to drop section 3. 
> 
> One thing that I overlooked and am with you is that we need to be able to express the AS-RS relationships. I have been preaching this in the other thread for so many times as you know so I thought I pointed it out, but missed apparently in my previous comment. So, I would add my 12th condition: 
> 
> 12. A way to express a list of valid RSs for this AS needs to be added to section 2. 
> 
> Best, 
> 
> Nat
> 
> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) <phil.hunt@oracle.com>:
>> I strongly oppose. 2 major issues. 
>> 
>> This is not service discovery this is configuration lookup. The client must have already discovered the oauth issuer uri and the resource uri. 
>> 
>> The objective was to provide a method to ensure the client has a valid set of endpoints to prevent mitm of endpoints like the token endpoint to the resource server. 
>> 
>> The draft does not address the issue of a client being given a bad endpoint for an rs. What we end up with is a promiscuous authz service giving out tokens to an unwitting client. 
>> 
>> Phil
>> 
>>> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
>>> 
>>> +1 to move forward with these
>>> 
>>>> On 10/03/16 17:35, Brian Campbell wrote:
>>>> +1
>>>> 
>>>> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <roland.hedberg@umu.se>
>>>> wrote:
>>>> 
>>>>> I support this document being moved forward with these two changes:
>>>>> 
>>>>> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
>>>>> proposed by Brian and
>>>>> - use the URI path suffix ’oauth-authorization-server’ instead of
>>>>> ’openid-configuration’ as proposed by Justin.
>>>>> 
>>>>>> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <hannes.tschofenig@gmx.net
>>>>>> :
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> This is a Last Call for comments on the  OAuth 2.0 Discovery
>>>>> specification:
>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>>>>>> 
>>>>>> Since this document was only adopted recently we are running this last
>>>>>> call for **3 weeks**.
>>>>>> 
>>>>>> Please have your comments in no later than March 10th.
>>>>>> 
>>>>>> Ciao
>>>>>> Hannes & Derek
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> — Roland
>>>>> 
>>>>> ”Everybody should be quiet near a little stream and listen."
>>>>> From ’Open House for Butterflies’ by Ruth Krauss
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en