Re: [OAUTH-WG] Initial OAuth working group Discovery specification

"Phil Hunt (IDM)" <phil.hunt@oracle.com> Tue, 09 February 2016 23:03 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 75EC21B2DA0 for <oauth@ietfa.amsl.com>; Tue, 9 Feb 2016 15:03:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3
X-Spam-Level:
X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_92=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 FeCGokBB1H_I for <oauth@ietfa.amsl.com>; Tue, 9 Feb 2016 15:03:32 -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 D34EA1B2D9E for <oauth@ietf.org>; Tue, 9 Feb 2016 15:03:31 -0800 (PST)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u19N3UND007306 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Feb 2016 23:03:31 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u19N3TWo030501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 Feb 2016 23:03:29 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u19N3StD014920; Tue, 9 Feb 2016 23:03:29 GMT
Received: from [25.83.59.80] (/24.114.39.49) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Feb 2016 15:03:28 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-99C222DB-4273-464C-BF0C-B56037FEF630
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (13D15)
In-Reply-To: <F0E2E297-DDB0-4EF3-B31C-E9207E75EE5F@ve7jtb.com>
Date: Tue, 9 Feb 2016 15:03:23 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <A3961211-AB1E-46E5-A328-C037359A2E0E@oracle.com>
References: <BY2PR03MB4427E9DAFDE674F71F6074AF5D60@BY2PR03MB442.namprd03.prod.outlook.com> <F6DD25EE-8B49-45E4-BACC-872CA98F2D7B@mit.edu> <2CB5C3E1-BF3B-4766-8761-CAF54F3C5170@ve7jtb.com> <F0681C96-1AFA-472C-899F-3E6952292DAA@oracle.com> <F0E2E297-DDB0-4EF3-B31C-E9207E75EE5F@ve7jtb.com>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/hSRBpaA3hUJmmYaa6n0HY-IME0k>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Initial OAuth working group Discovery specification
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: Tue, 09 Feb 2016 23:03:34 -0000

The rel for scim returns the endpoint for scim. 

The rel for oauth returns endpoints for oauth. 

The query lets the client say i want the endpoint for oauth used for scim. 

I suppose you could reverse it but then we'll have oauth discovery happening in different ways across many different specs. One set of considerations is enough. :-)

Phil

> On Feb 9, 2016, at 14:52, John Bradley <ve7jtb@ve7jtb.com> wrote:
> 
> You would define a rel uri for SCIM.   The SCIM entry can have sub properties if it supported more than one auth type,  or you could have a SCIM discovery document that the URI points to.
> 
> There are probably multiple ways to do it.
> 
> I don’t think trying to have a oauth rel and then sub types is going to make sense to developers.  It is also not a good fit for Webfinger.
> 
> I also suspect that SCIM is more naturally part of a authentication service It may be that the authentication service points at the SCIM service.
> 
> Remember that webfinger is a account alias and may not be the subject that the SP/RP knows the user as.
> 
> Each service will need to be thought through for webfinger as the account identity may mean different things depending on the protocol, and not every protocol needs per user discovery.
> 
> John B
>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
>> 
>> Another example is to look at scim discovery(in contrast with connect).
>> 
>> When asked separately the answers may be different. 
>> 
>> Asking what is the oauth server for scim is yet another relation.  So may be we need a scheme for oauth where query is rs:someval and optionally an acnt value to. 
>> 
>> For example
>> Get ./well-known/webfinger?rel=oauth&query=rs:scim&acnt:phunt@example.com
>> 
>> Note i probably have the compound query syntax wrong. 
>> 
>> Phil
>> 
>>> On Feb 9, 2016, at 14:03, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>> 
>>> If we keep webfinger I don’t think that having a generic OAuth rel makes sense.   It should be up to each API/Protocol to define it’s own rel value like Connect has done.
>>> 
>>> It is not reasonable to think that a persons ID provider is going to be the same as the one for calendaring or photo sharing.
>>> 
>>> So I could go two ways with webfinger,  leave it out completely, or leave it in but make it up to the application to define a rel value.
>>> I expect that some things using UMA in web-finger would point directly to the resource and the resource would point the client at the correct UMA server.
>>> 
>>> The config file name in .well-known could stay as openid-configuration for historical reasons or we could change it.
>>> 
>>> I think we first need to decide if every protocol/API is going to have its own config file, we are going to get apps to retrieve multiple files,  or everything is going to go into one config-file and applicatins just add to that?
>>> 
>>> I prefer not to change the file name if we are going for one config file, but if we do one alias/link is probably not the end of the world, as I doubt people will ever remove openid-configuration one if they have it now.
>>> 
>>> John B.
>>> 
>>>  
>>>> On Feb 9, 2016, at 2:19 PM, Justin Richer <jricher@mit.edu> wrote:
>>>> 
>>>> Mike, thanks for putting this up.
>>>> 
>>>> 
>>>> I would like to propose for two changes that have been brought up before:
>>>> 
>>>> 1) The wholesale removal of section 2, Webfinger lookup. 
>>>> 
>>>> 2) The changing of "/.well-known/openid-configuration” to "/.well-known/oauth-authorization-server” or something else not openid-related.
>>>> 
>>>> 
>>>> 
>>>>  — Justin
>>>> 
>>>> 
>>>>> On Feb 9, 2016, at 9:09 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>> 
>>>>> We have created the initial working group version of OAuth Discovery based on draft-jones-oauth-discovery-01, with no normative changes.
>>>>>  
>>>>> The specification is available at:
>>>>> ·       http://tools.ietf.org/html/draft-ietf-oauth-discovery-00
>>>>>  
>>>>> An HTML-formatted version is also available at:
>>>>> ·       http://self-issued.info/docs/draft-ietf-oauth-discovery-00.html
>>>>>  
>>>>>                                                           -- Mike
>>>>>  
>>>>> P.S.  This notice was also posted at http://self-issued.info/?p=1534 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
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>