Re: [OAUTH-WG] OAuth Discovery

Phil Hunt <phil.hunt@oracle.com> Sat, 28 November 2015 04:43 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DDF1A8A5A for <oauth@ietfa.amsl.com>; Fri, 27 Nov 2015 20:43:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.784
X-Spam-Level:
X-Spam-Status: No, score=-4.784 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
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 IZ7liB-glHHb for <oauth@ietfa.amsl.com>; Fri, 27 Nov 2015 20:43:36 -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 9532A1A8A56 for <oauth@ietf.org>; Fri, 27 Nov 2015 20:43:36 -0800 (PST)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAS4hZCB021684 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 Nov 2015 04:43:36 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tAS4hYUV015627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 28 Nov 2015 04:43:35 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tAS4hYRS032053; Sat, 28 Nov 2015 04:43:34 GMT
Received: from [192.168.1.27] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 27 Nov 2015 20:43:34 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-AC0AF273-E1D9-41CE-833F-BCA34A2DFBFD
Mime-Version: 1.0 (1.0)
From: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (13B143)
In-Reply-To: <BY2PR03MB442BDB413693994CA405044F5020@BY2PR03MB442.namprd03.prod.outlook.com>
Date: Fri, 27 Nov 2015 20:43:32 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <5F43839D-06E7-4E56-BAAC-0F0DE3A553D7@oracle.com>
References: <BY2PR03MB4420981B312D92924AD6BFFF5050@BY2PR03MB442.namprd03.prod.outlook.com> <128376572.11963058.1448683100369.JavaMail.yahoo@mail.yahoo.com> <BY2PR03MB442BDB413693994CA405044F5020@BY2PR03MB442.namprd03.prod.outlook.com>
To: Mike Jones <Michael.Jones@microsoft.com>
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/8_vBqEWefebcYN8eUE6E7EIJAhY>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 28 Nov 2015 04:43:38 -0000

While it is good to start with the connect spec, i would caution on the assumption of compatibility. More than likely there will be changes based on broader cases. 

I would like to understand these broader requirements, use cases, and security considerations first. 



Phil

> On Nov 27, 2015, at 20:05, Mike Jones <Michael.Jones@microsoft.com> wrote:
> 
> It allows non-Connect implementation of OAuth 2.0 to also have a standard discovery capability – and one that can later be updated to also support OpenID Connect with no breaking changes, should that be desired in the future.
>  
>                                                           -- Mike
>  
> From: Bill Mills [mailto:wmills_92105@yahoo.com] 
> Sent: Friday, November 27, 2015 7:58 PM
> To: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Discovery
>  
> Can you elaborate on the advantage of having a separate parallel spec to OpenID Discovery?
>  
>  
> 
> On Wednesday, November 25, 2015 3:37 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>  
> 
> I’m pleased to announce that Nat Sakimura, John Bradley, and I have created an OAuth 2.0 Discovery specification.  This fills a hole in the current OAuth specification set that is necessary to achieve interoperability.  Indeed, the Interoperability section of OAuth 2.0 states:
> In addition, this specification leaves a few required components partially or fully undefined (e.g., client registration, authorization server capabilities, endpoint discovery).  Without these components, clients must be manually and specifically configured against a specific authorization server and resource server in order to interoperate.
>   
> This framework was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.
>  
> This specification enables discovery of both endpoint locations and authorization server capabilities.
>  
> This specification is based upon the already widely deployed OpenID Connect Discovery 1.0 specification and is compatible with it, by design.  The OAuth Discovery spec removes the portions of OpenID Connect Discovery that are OpenID specific and adds metadata values for Revocation and Introspection endpoints.  It also maps OpenID concepts, such as OpenID Provider, Relying Party, End-User, and Issuer to their OAuth underpinnings, respectively Authorization Server, Client, Resource Owner, and the newly introduced Configuration Information Location.  Some identifiers with names that appear to be OpenID specific were retained for compatibility purposes; despite the reuse of these identifiers that appear to be OpenID specific, their usage in this specification is actually referring to general OAuth 2.0 features that are not specific to OpenID Connect.
>  
> The specification is available at:
> ·         http://tools.ietf.org/html/draft-jones-oauth-discovery-00
>  
> An HTML-formatted version is also available at:
> ·         http://self-issued.info/docs/draft-jones-oauth-discovery-00.html
>  
>                                                                 -- Mike
>  
> P.S.  This note was also posted at http://self-issued.info/?p=1496 and as @selfissued.
> 
> _______________________________________________
> 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