Hi Phil, >From the RESTful perspective, it is the resource that should specify where the client should find the configuration etc. through RFC5988. As RFC5785 states, /.well-known/ uri is a last resort when this approach does not work, e.g., when you cannot access the resource before knowing the metadta. If I read your message correctly, your use case seems to be able to be accessed first. Then RFC5988 approach seems to work perfectly. I am advocating oauth-meta [1] for such cases.
[1] https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-2 Nat 2016年2月18日(木) 23:06 Phil Hunt <[email protected]>: > 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 > [email protected] > > > > > > On Feb 18, 2016, at 6:55 AM, John Bradley <[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]> 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 > [email protected] > > > > > > On Feb 17, 2016, at 11:48 PM, Mike Jones <[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 > > An HTML-formatted version is also available at: > · 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 and > as @selfissued <https://twitter.com/selfissued>. > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
