resource service X could be any http accessible service: * CRM * Finance * Payroll * ERP * any application on the web.
The spec seems to suggest that we use /.well-known/crm to discover OAuth config for crm. But that may cause conflict if crm has its own discovery. Which leads us down the path of doing something like “crm-oauth”. Then there is confusion about what host the discovery is done on. For example, hypothetically do I do: GET /.well-known/crm Host: example.com But what about the CRM’s configuration information. Is this stomping on it? Or, what If we put the oauth configuration at the host for the crm service: GET /.well-known/openid-configuration Host: crm.example.com I think the point is that there is a relationship between a protected resource and its designated OAuth service. The client needs to discover: * Where is its designated resource service and what security does it use * If it is OAuth, where is the intended OAuth configuration for that resource service instance? Phil @independentid www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com <mailto:phil.h...@oracle.com> > On Feb 18, 2016, at 7:19 AM, John Bradley <ve7...@ve7jtb.com> wrote: > > Can you clarify what you mean by “resource service x”? > > Is that the RS base URI for the resource, a specific URI that the client is > requesting? > > That is getting UMA ish. > > The concept of a base RS URI is a rat hole that I prefer not to go down, as > it is something everyone thinks exists but like SCIM if it exists it is > protocol or deployment specific. > > The notion that you would send the URI you are planning on requesting to a > Webfinger server to find the OAuth server, is probably going to have privacy > issues. > > I suspect that you need to hand back a error from the resource to say where > the AS is, or have a .well-known for the RS. > > RS discovery probably wants to be separate from AS discovery. (Yes I do > think we need something, UMA rpt or something like it might be a way to go) > > John B. > >> On Feb 18, 2016, at 9:06 AM, Phil Hunt <phil.h...@oracle.com >> <mailto:phil.h...@oracle.com>> wrote: >> >> Maybe SCIM was a bad example. It functions as a RESTful resource in the >> context of OAuth. >> >> I find the use of OIDC to be confusing as an example (and the default) >> because it is both an OAuth resource and a security service. It is a >> modification of OAuth. >> >> Start thinking about every application ever written that uses OAuth. Are we >> expecting 100s of thousands of these to each register? >> >> To me, this specification is a fine specification for OIDC and it should be >> published there because the specification defines how to discovery OAuth and >> OpenID information. >> >> Likewise you suggest it is ok for SCIM to do the same. >> >> How do we expect normal applications to set up and do discovery? >> >> It seems to me that an “OAUTH” discovery spec should have a parameter to >> ask, I want to discover OAuth configuration for resource service X. >> >> That still allows me to have a separate discovery service that says, tell me >> about resource service X itself. >> >> BTW. I think we are FAR from Last Call on this topic. >> >> Phil >> >> @independentid >> www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com >> <mailto:phil.h...@oracle.com> >> >> >> >> >> >>> On Feb 18, 2016, at 6:55 AM, John Bradley <ve7...@ve7jtb.com >>> <mailto:ve7...@ve7jtb.com>> wrote: >>> >>> Diffrent protocols like Connect and SCIM may have different configurations, >>> endpoints , keys , authentication methods, scopes etc. >>> >>> It should be posable to have them as one document, but forcing them to use >>> one document is going to cause a explosion of claim registration for >>> discovery. >>> >>> I think it is better for SCIM to register one well known than to have to >>> register 20 claims with scim prefixes or something silly like that. >>> >>> Name-spacing the claims by allowing them to be in different well known >>> files is not unreasonable. >>> >>> Remember some of these protocols may be hosted on SaaS so there is no >>> guarantee that all protocols will have the same OAuth Config. >>> >>> Nothing stops a protocol from doing what it likes with webfinger if it >>> wants to use that for discovery. >>> >>> In principal I like the idea of having another protocol as an example. >>> >>> My only concern is that I haven’t seen any discussion of your SCIM >>> discovery document in the SCIM WG. >>> I personally think sorting out discovery for SCIM is a good idea, but >>> OAUTh is but one of several authentication methods for SCIM, and there are >>> probably other non OAuth things that want to be described. >>> >>> I would feel better about using it as an example if it were adopted by the >>> WG and some general interest shown. >>> >>> I encourage you to do that so we can use it as a example. >>> >>> John B. >>> >>>> On Feb 18, 2016, at 8:35 AM, Phil Hunt <phil.h...@oracle.com >>>> <mailto:phil.h...@oracle.com>> wrote: >>>> >>>> I still find the following text objectionable and confusing… >>>> By default, for historical reasons, unless an application-specific >>>> well-known URI path suffix is registered and used for an application, >>>> the client for that application SHOULD use the well-known URI path >>>> suffix "openid-configuration" and publish the metadata document at >>>> the path formed by concatenating "/.well-known/openid-configuration" >>>> to the authorization server's issuer identifier. As described in >>>> Section 5 >>>> <http://tools.ietf.org/html/draft-ietf-oauth-discovery-01#section-5>, >>>> despite the identifier >>>> "/.well-known/openid-configuration", appearing to be OpenID-specific, >>>> its usage in this specification is actually referring to a general >>>> OAuth 2.0 feature that is not specific to OpenID Connect. >>>> >>>> Further, as a default “openid-configuration” as the default further gives >>>> people the impression that a plain OAuth server *is* an authentication >>>> server and that the normal access token received is evidence of a >>>> successful authentication. >>>> >>>> It would be better to point out that application may include oauth >>>> discovery in their discovery URI and that OAuth is an example of this. It >>>> might be good to include two examples. E.g. OIDC and SCIM (as another >>>> referenceable example). >>>> >>>> GET /.well-known/openid-configuration >>>> and >>>> GET /.well-known/scim >>>> Retrieve the OAuth configuration for the application openid and scim >>>> respectively. >>>> >>>> The use of: >>>> GET /.well-known/oauth2/ >>>> Should be the default used when there is no known application based >>>> well-known application based URI discovery. >>>> >>>> Of course, the concern I raised earlier is that this approach of >>>> application specific URIs ends up requiring every application to make an >>>> IANA registration if they don’t want to use the default of “oauth2” (or >>>> “openid-configuration”). Is that what the authors expect? >>>> >>>> It seemed better to me to use the webfinger syntax to allow the client to >>>> say “I want the designated OAuth configuration for the resource service X” >>>> would be a better design that avoids extensive IANA registration. >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com >>>> <mailto:phil.h...@oracle.com> >>>> >>>> >>>> >>>> >>>> >>>>> On Feb 17, 2016, at 11:48 PM, Mike Jones <michael.jo...@microsoft.com >>>>> <mailto:michael.jo...@microsoft.com>> wrote: >>>>> >>>>> In response to working group input, this version of the OAuth Discovery >>>>> specification has been pared down to its essence – leaving only the >>>>> features that are already widely deployed. Specifically, all that >>>>> remains is the definition of the authorization server discovery metadata >>>>> document and the metadata values used in it. The WebFinger discovery >>>>> logic has been removed. The relationship between the issuer identifier >>>>> URL and the well-known URI path relative to it at which the discovery >>>>> metadata document is located has also been clarified. >>>>> >>>>> Given that this now describes only features that are in widespread >>>>> deployment, the editors believe that this version is ready for working >>>>> group last call. >>>>> >>>>> The specification is available at: >>>>> · http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 >>>>> <http://tools.ietf.org/html/draft-ietf-oauth-discovery-01> >>>>> >>>>> An HTML-formatted version is also available at: >>>>> · http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html >>>>> <http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html> >>>>> >>>>> -- Mike & Nat & >>>>> John >>>>> >>>>> P.S. This notice was also posted at http://self-issued.info/?p=1544 >>>>> <http://self-issued.info/?p=1544> 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 https://www.ietf.org/mailman/listinfo/oauth
