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

John Bradley <ve7jtb@ve7jtb.com> Tue, 09 February 2016 23:49 UTC

Return-Path: <ve7jtb@ve7jtb.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 5CFA61B30A4 for <oauth@ietfa.amsl.com>; Tue, 9 Feb 2016 15:49:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.5
X-Spam-Level:
X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001] autolearn=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 FzteCd9T_2jT for <oauth@ietfa.amsl.com>; Tue, 9 Feb 2016 15:49:46 -0800 (PST)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A681B30A6 for <oauth@ietf.org>; Tue, 9 Feb 2016 15:49:45 -0800 (PST)
Received: by mail-qg0-x230.google.com with SMTP id b35so2640207qge.0 for <oauth@ietf.org>; Tue, 09 Feb 2016 15:49:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=FpvaUHNQTKokPac4USHnMgfbPG++sYcu9SRDK3SOY+E=; b=TJek58FPG3yFuZDqPTHvM5CvK7ArstVAgN6vOjw/3bv2vNBcvFuehmBuKr21zOo29v Vzsd6e4XGfdWo9GbQfxTpOwzS8Eo7gyIOzmzDHCKFfl4UbXkNFPAD45Cyd/S0RAKX33m 7o5r+2cASGVelCGrRp8HUNN8ZVhSgabrLdMvCVpXQdudj9rB9eb63uC8kZguynaIQHDQ RWNzZ1Z9llzqcA0l5jVQFnGRbKzdDsxJbESkqZMVCnwCvtATJGZcmeOmof6P5XGjBG52 iwx2AT/Zt+qg4CXt1PYpx7NuV0JBqP9spcqUqbn5WOxPqmQvynM1nWFAT3KsLbWRlQxe zVwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=FpvaUHNQTKokPac4USHnMgfbPG++sYcu9SRDK3SOY+E=; b=aOlhSiAcsescDCKlbvBt3ihQhx4I/WoDONLp9AxC1Zybdcv04A/nhOvmpAg7ENGCrX elE/zChBrUTPRnE76QFv1n7x4woehX5atTTD+LSYpjVEWLMi3+ZiQE4ZkJY/8yoBDElF R9Vo9ybYVjtlnW2GLqfUcOlfb9PemLw7Nz4QLS5XF/UTRmeG+Ea1TSMzidncYINER5lt DJRBlwgl6wjlDqc9e8FrBIUqzR7cVF33mzK2Q8bCCmVhrfu+EsRnXZnfbFQK1a1DH22e WZgxhExsy8YKg2pcpB15kNghKE8rEVhX1pSvlZPjzbruvpI/R4WXAeKY1UlvEfH6xOSD CpwQ==
X-Gm-Message-State: AG10YOT8YnfxpsPjRJW6lN0phAC6kEW4Ltxvulql7e46G2n/XF99U72azsLURwMcjGOY5A==
X-Received: by 10.140.220.78 with SMTP id q75mr47160783qhb.77.1455061784765; Tue, 09 Feb 2016 15:49:44 -0800 (PST)
Received: from [192.168.8.100] ([181.202.64.23]) by smtp.gmail.com with ESMTPSA id t187sm177872qht.39.2016.02.09.15.49.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Feb 2016 15:49:43 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_1C59C430-D4A2-452B-B5AD-1EA6453ABBA5"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com>
Date: Tue, 9 Feb 2016 20:49:39 -0300
Message-Id: <CC09F82E-2863-480A-AA3A-94F1D00361A4@ve7jtb.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> <A3961211-AB1E-46E5-A328-C037359A2E0E@oracle.com> <F27C1AB7-B869-4EF5-9E5F-11373C771EFF@ve7jtb.com> <9A8F1DC7-AD9E-44AF-8E01-A02532296D65@oracle.com>
To: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/TIQcUaSsJFSFkMp2hybZN1D3dAI>
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:49:49 -0000

Have a look at
https://tools.ietf.org/html/rfc7033 <https://tools.ietf.org/html/rfc7033>

The way to do what you want would mean having multiple array objects with the same rel and somehow differentiating them via properties.

I think that is going to be more complicated for clients to parse.

I think that the difference is how you look at the actors involved.  I think clients look for a service and then go from there,  you are advocating that they would look for a authorization method and then find services that support that method.   

So yes we are looking at it from different ends.

I don’t know that defining OAuth genericly at the webfinger level of user discovery makes sense.   Perhaps for a enterprise custom API environment it might.

John B.

> On Feb 9, 2016, at 8:24 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> 
> Huh?
> 
> Our proposals are the opposite of one-another.  In your proposal you have people querying scim to get oauth.  I’m saying you query rel=scim to get information about SCIM.  Querying rel=SCIM and receiving OAuth seems bass- ackwards does it not?
> 
> Further, having rel=oauth lets us define one RFC for all that covers all the security concerns for oauth discovery.  If we do it your way then every resource that registers its own discovery also has to have an oauth section that copies the oauth discovery stuff because there is no longer an oauth discovery relationship.
> 
> Phil
> 
> @independentid
> www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
> 
> 
> 
> 
> 
>> On Feb 9, 2016, at 3:16 PM, John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>> wrote:
>> 
>> Please don’t break the webfinger RFC.
>> 
>> If you search for SCIM you can have additional properties returned as part of the entry, but you only search for one thing.
>>  
>> Webfinger is designed to be very simple to implement.  In general you just get back the whole document with all the rel. 
>> The query filter is a optional optimization. 
>> 
>> The JSON in the doc is by rel.
>> 
>>> On Feb 9, 2016, at 8:03 PM, Phil Hunt (IDM) <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> wrote:
>>> 
>>> 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 <mailto: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 <mailto: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 <http://example.com/>
>>>>> 
>>>>> Note i probably have the compound query syntax wrong. 
>>>>> 
>>>>> Phil
>>>>> 
>>>>> On Feb 9, 2016, at 14:03, John Bradley <ve7jtb@ve7jtb.com <mailto: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 <mailto: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 <mailto: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 <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 <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 <http://self-issued.info/?p=1534> and as @selfissued <https://twitter.com/selfissued>.
>>>>>>>>  
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>> 
>> 
>