I suspect that the configuration well-knowns are going to be on the root domain. You could try and get a user to put in crm.example.com, but I suspect that is not going to work.
If the app doesn’t have a specific protocol identifier then it would use the default. I don’t know if you can get around having some sort of app/protocol identifier configured in the app. John B. > On Feb 18, 2016, at 9:49 AM, Phil Hunt <[email protected]> wrote: > > 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 <http://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 <http://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/>[email protected] > <mailto:[email protected]> > > > > > >> On Feb 18, 2016, at 7:19 AM, John Bradley <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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/>[email protected] >>> <mailto:[email protected]> >>> >>> >>> >>> >>> >>>> On Feb 18, 2016, at 6:55 AM, John Bradley <[email protected] >>>> <mailto:[email protected]>> 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 <[email protected] >>>>> <mailto:[email protected]>> 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/>[email protected] >>>>> <mailto:[email protected]> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Feb 17, 2016, at 11:48 PM, Mike Jones <[email protected] >>>>>> <mailto:[email protected]>> 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 >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
