Re: [OAUTH-WG] Initial OAuth working group Discovery specification
George Fletcher <gffletch@aol.com> Wed, 10 February 2016 18:10 UTC
Return-Path: <gffletch@aol.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 900471B2E9B for <oauth@ietfa.amsl.com>; Wed, 10 Feb 2016 10:10:43 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 JYx0rbtbHSRn for <oauth@ietfa.amsl.com>; Wed, 10 Feb 2016 10:10:38 -0800 (PST)
Received: from omr-m002e.mx.aol.com (omr-m002e.mx.aol.com [204.29.186.2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68931B2E84 for <oauth@ietf.org>; Wed, 10 Feb 2016 10:10:09 -0800 (PST)
Received: from mtaout-laa01.mx.aol.com (mtaout-laa01.mx.aol.com [172.27.2.97]) by omr-m002e.mx.aol.com (Outbound Mail Relay) with ESMTP id 8E6DA380009B; Wed, 10 Feb 2016 13:10:08 -0500 (EST)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-laa01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id D789738000083; Wed, 10 Feb 2016 13:10:07 -0500 (EST)
To: Justin Richer <jricher@mit.edu>, John Bradley <ve7jtb@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> <CC09F82E-2863-480A-AA3A-94F1D00361A4@ve7jtb.com> <6580B8BC-49CD-4DF3-8056-ABD7F785E613@oracle.com> <70C486FA-BCB2-4FED-B8B9-8104CD74AEB9@ve7jtb.com> <1D6E8E98-B8F2-43A9-82FA-2D326237BB1F@mit.edu>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <56BB7CFF.100@aol.com>
Date: Wed, 10 Feb 2016 13:10:07 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <1D6E8E98-B8F2-43A9-82FA-2D326237BB1F@mit.edu>
Content-Type: multipart/alternative; boundary="------------000707040108040601040203"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1455127808; bh=oyML6WPGse7HfKKeHugw265dsRQyMlwjnlviWaZc7Dg=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=L2+yVGfYVsPNvQenHpnEnmPJ1/Njf1bPgnwAgA7CNwNhc1jiz9wohKUEJT5zLqsSS oUbqdge4ZqHnbLja7a89mY7J8HMMfq37n4v8UKPbtWRU4DNEEv7sLF7YM+4dMIZT96 MvQT/FA5RQ9nImynWvGet2QIIMo7ivCl5d8KnahM=
x-aol-sid: 3039ac1b026156bb7cff18dc
X-AOL-IP: 10.172.102.179
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/3A4HkuWC1K7DpvQdzxUUEA9EYaM>
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: Wed, 10 Feb 2016 18:10:43 -0000
I have to disagree that Webfinger is just about *per-user* service discovery. It can definitely be used that way, but even in the spec there is the example of finding the meta data about a resource which includes in the JSON response a "rel":"author". Which means webfinger is designed for queries such as "who is the author of this webpage". GET /.well-known/webfinger?resource=http%3A%2F%2Fblog.example.com%2Farticle%2Fid%2F314&rel=author I do agree that OAuth should focus on the details of the discovery document and possibly its location within .well-known. Thanks, George On 2/9/16 9:00 PM, Justin Richer wrote: > +1 to John’s point. Webfinger is, as designed, about doing per-user > service discovery. Let’s keep the OAuth service discovery away from > that. What does it mean to find the OAuth server for a user, anyway? > Without the context of a resource protocol, I don’t think it does. If > you already have the domain and you don’t need to do a transform from > a user-identifier, just go straight to .well-known and have an OAuth > service discovery document. > > I think the current discovery draft has tried much too hard to copy > what’s in OIDC, where it does make sense to use webfinger and per-user > discovery systems in the context of a specific identity protocol. It’s > a great starting place, but I think we decidedly need to get away from > it now. > > — Justin > >> On Feb 9, 2016, at 7:34 PM, John Bradley <ve7jtb@ve7jtb.com >> <mailto:ve7jtb@ve7jtb.com>> wrote: >> >> OK I was talking about discovering user services via webfinger, (The >> way connect uses it and most other things) and you are talking about >> using it to discover things about a server. >> >> Your first example had phunt@example.com <mailto:phunt@example.com> >> as the account you were querying, and that seemed like a user >> discovery to me. >> >> If you are looking up the OAuth config for a server why would you not >> just go strait to the .wellknown >> >> By the way in your example you would need to run a webfinger server >> on scim.example.com <http://scim.example.com/> to be able to answer >> the query. >> >> looking for .wellknown on examle.com <http://examle.com/> seems more >> direct. >> >> You seem to be looking more for where is the service for the domain >> rather than the user. >> >> >> John B. >> >>> On Feb 9, 2016, at 9:20 PM, Phil Hunt <phil.hunt@oracle.com >>> <mailto:phil.hunt@oracle.com>> wrote: >>> >>> John, >>> >>> I am following 7033. The rel parameter is not the query it is the >>> sub set of the resource you want information about. >>> >>> There is nothing complex here. In most cases this would be responded >>> to by a simple transformation pattern. >>> >>> Correcting my previous example (but showing it in easy to read >>> form)…the proper query that returns information for both SCIM and >>> OAuth endpoints would be: >>> >>> GET /.well-known/webfinger?resource=https://scim.example.com&rel=oauth >>> >>> This would return something like: >>> HTTP/1.1 200 OK >>> Access-Control-Allow-Origin: * >>> Content-Type: application/jrd+json >>> >>> { >>> "subject" : “http://scim.example.com <http://scim.example.com/>", >>> >>> "links" : >>> [ >>> { >>> "rel" : “oauth", >>> "href" : "https://oauth.example.com/" >>> } >>> ] >>> } >>> >>> This tells me that the OAuth server used for SCIM at >>> scim.example.com <http://scim.example.com/> is at oauth.example.com >>> <http://oauth.example.com/> >>> >>> Note that 7033 has an extension mechanism to define other schemes. >>> E.g. “acct” is just one scheme. Others can be defined. For example, >>> “rs:” could be registered allowing URIs to be used for the resource >>> instead of an actual https endpoint (which is also allowed). >>> >>> GET /.well-known/webfinger?resource=rs:scim&rel=oauth >>> >>> This would return something like: >>> HTTP/1.1 200 OK >>> Access-Control-Allow-Origin: * >>> Content-Type: application/jrd+json >>> >>> { >>> "subject" : “rs:scim", >>> >>> "links" : >>> [ >>> { >>> "rel" : “oauth", >>> "href" : "https://oauth.example.com/" >>> } >>> ] >>> } >>> >>> This says something different. This says that for scim services the >>> oauth service is oauth.example.com <http://oauth.example.com/>. >>> >>> The first example actually has more granularity. The second example >>> does not require the client to know the scim endpoint in advance. >>> >>> >>> Phil >>> >>> @independentid >>> www.independentid.com <http://www.independentid.com/> >>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> >>> >>> >>> >>> >>> >>>> On Feb 9, 2016, at 3:49 PM, John Bradley <ve7jtb@ve7jtb.com >>>> <mailto:ve7jtb@ve7jtb.com>> wrote: >>>> >>>> Have a look at >>>> 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 >>>>> <mailto: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 >>>>>>>>>>>> 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 >>>>>>>>>>>> athttp://self-issued.info/?p=1534and as@selfissued >>>>>>>>>>>> <https://twitter.com/selfissued>. >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>> >>>>> >>>> >>> >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- Re: [OAUTH-WG] Initial OAuth working group Discov… John Bradley
- Re: [OAUTH-WG] Initial OAuth working group Discov… Phil Hunt
- [OAUTH-WG] Initial OAuth working group Discovery … Mike Jones
- Re: [OAUTH-WG] Initial OAuth working group Discov… Justin Richer
- Re: [OAUTH-WG] Initial OAuth working group Discov… John Bradley
- Re: [OAUTH-WG] Initial OAuth working group Discov… Justin Richer
- Re: [OAUTH-WG] Initial OAuth working group Discov… Phil Hunt (IDM)
- Re: [OAUTH-WG] Initial OAuth working group Discov… John Bradley
- Re: [OAUTH-WG] Initial OAuth working group Discov… Phil Hunt (IDM)
- Re: [OAUTH-WG] Initial OAuth working group Discov… John Bradley
- Re: [OAUTH-WG] Initial OAuth working group Discov… Phil Hunt
- Re: [OAUTH-WG] Initial OAuth working group Discov… John Bradley
- Re: [OAUTH-WG] Initial OAuth working group Discov… Justin Richer
- Re: [OAUTH-WG] Initial OAuth working group Discov… Phil Hunt
- Re: [OAUTH-WG] Initial OAuth working group Discov… Justin Richer
- Re: [OAUTH-WG] Initial OAuth working group Discov… George Fletcher
- Re: [OAUTH-WG] Initial OAuth working group Discov… Nat Sakimura