Re: [OAUTH-WG] OAuth 2.0 Discovery Location

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 <jricher@mit.edu> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>