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 > <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
