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

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
> 