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 <jric...@mit.edu
<mailto:jric...@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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
