Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Justin Richer <[e-mail]>]

I think you can really do both parts in the document without harm. 
Specifying a ".well-known" location doesn't preclude you from including 
the same metadata elsewhere as well, such as with oauth-meta or with a 
service-specific discovery document (like openid-configuration). But it 
would be nice to have a generic authorization server discovery endpoint 
that I can build for a domain so I don't have to always find somewhere 
to put it.

  -- Justin

On 2/22/2016 4:44 AM, Thomas Broyer wrote:
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want 
> to do discovery, and leave it open to implementers / to other specs to 
> define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any 
> URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a 
> basis for other metadata specs (like OpenID Connect).
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of 
> WWW-Authenticate response header, you have everything you need to 
> proceed (well, except if there are several ASs each with different 
> scopes; sounds like an edge-case to me though; maybe RFC6750 should 
> instead be updated with such a parameter such that an RS could return 
> several WWW-Authenticate: Bearer, each with its own "scope" and "duri" 
> value?)
>
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     The newly-trimmed OAuth Discovery document is helpful and moving
>     in the right direction. It does, however, still have too many
>     vestiges of its OpenID Connect origins. One issue in particular
>     still really bothers me: the use of
>     “/.well-known/openid-configuration” in the discovery portion. Is
>     this an OAuth discovery document, or an OpenID Connect one? There
>     is absolutely no compelling reason to tie the URL to the OIDC
>     discovery mechanism.
>
>     I propose that we use “/.well-known/oauth-authorization-server” as
>     the default discovery location, and state that the document MAY
>     also be reachable from “/.well-known/openid-configuration” if the
>     server also provides OpenID Connect on the same domain. Other
>     applications SHOULD use the same parameter names to describe OAuth
>     endpoints and functions inside their service-specific discovery
>     document.
>
>      — Justin
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>