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

[George Fletcher <[e-mail]>]

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 <[e-mail] 
>> <mailto:[e-mail]>> 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 [e-mail] <mailto:[e-mail]> 
>> 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 <[e-mail] 
>>> <mailto:[e-mail]>> 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/>
>>> [e-mail] <mailto:[e-mail]>
>>>
>>>
>>>
>>>
>>>
>>>> On Feb 9, 2016, at 3:49 PM, John Bradley <[e-mail] 
>>>> <mailto:[e-mail]>> 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 <[e-mail] 
>>>>> <mailto:[e-mail]>> 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/>
>>>>> [e-mail] <mailto:[e-mail]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Feb 9, 2016, at 3:16 PM, John Bradley <[e-mail] 
>>>>>> <mailto:[e-mail]>> 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) 
>>>>>>> <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] 
>>>>>>> <mailto:[e-mail]>> 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) 
>>>>>>>>> <[e-mail] <mailto:[e-mail]>> 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:[e-mail] 
>>>>>>>>> <http://example.com/>
>>>>>>>>>
>>>>>>>>> Note i probably have the compound query syntax wrong.
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>> On Feb 9, 2016, at 14:03, John Bradley <[e-mail] 
>>>>>>>>> <mailto:[e-mail]>> 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 <[e-mail] 
>>>>>>>>>>> <mailto:[e-mail]>> 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 
>>>>>>>>>>>> <[e-mail] 
>>>>>>>>>>>> <mailto:[e-mail]>> 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
>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth