Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

[Nat Sakimura <[e-mail]>]

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 <[e-mail]>:

> 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
> [e-mail]
>
>
>
>
>
> On Feb 18, 2016, at 6:55 AM, John Bradley <[e-mail]> 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 <[e-mail]> 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
> [e-mail]
>
>
>
>
>
> On Feb 17, 2016, at 11:48 PM, Mike Jones <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>