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 <phil.h...@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.h...@oracle.com > <mailto:phil.h...@oracle.com> > > > > > >> On Feb 9, 2016, at 3:16 PM, John Bradley <ve7...@ve7jtb.com >> <mailto:ve7...@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.h...@oracle.com >>> <mailto:phil.h...@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 <ve7...@ve7jtb.com >>> <mailto: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 >>>>> <mailto: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 >>>>> <http://example.com/> >>>>> >>>>> Note i probably have the compound query syntax wrong. >>>>> >>>>> Phil >>>>> >>>>> On Feb 9, 2016, at 14:03, John Bradley <ve7...@ve7jtb.com >>>>> <mailto: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 >>>>>>> <mailto: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 >>>>>>>> <mailto: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 >>>>>>>> <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 >>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
