+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 <[email protected]> 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 [email protected] <mailto:[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 >> <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/ <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/ <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/>[email protected] >> <mailto:[email protected]> >> >> >> >> >> >>> On Feb 9, 2016, at 3:49 PM, John Bradley <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> 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 <[email protected] >>>> <mailto:[email protected]>> 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/>[email protected] >>>> <mailto:[email protected]> >>>> >>>> >>>> >>>> >>>> >>>>> On Feb 9, 2016, at 3:16 PM, John Bradley <[email protected] >>>>> <mailto:[email protected]>> 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) <[email protected] >>>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>> <mailto:[email protected]>> 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) <[email protected] >>>>>>>> <mailto:[email protected]>> 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:[email protected] >>>>>>>> <http://example.com/> >>>>>>>> >>>>>>>> Note i probably have the compound query syntax wrong. >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>>> On Feb 9, 2016, at 14:03, John Bradley <[email protected] >>>>>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>>>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>>>>>>> <mailto:[email protected]>> 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 >>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>> >>>>> >>>> >>> >> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
