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 <ve7...@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.h...@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:ph...@example.com >> >> Note i probably have the compound query syntax wrong. >> >> Phil >> >>> On Feb 9, 2016, at 14:03, John Bradley <ve7...@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 <jric...@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.jo...@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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
