Subject: [OAUTH-WG] Product Support for RFC8414 well-known URIs

From: Daniel Fett <[email-masked]>
Date: Mon, 8 Jun 2020 09:45:58 +0200

Hi all,

RFC8414 says that the URI where the OAuth metadata document is published is

formed by inserting a well-known URI string into the authorization
   server's issuer identifier between the host component and the path
   component, if any.  By default, the well-known URI string used is
   "/.well-known/oauth-authorization-server".

I found that some OAuth servers and clients instead follow the
convention used by OpenID Connect, where the suffix
"/.well-known/openid-configuration" (or
"/.well-known/oauth-authorization-server") is appended to the issuer URL.

Is this a common deviation from the spec?

Do you know how specific products handle this?

Does it make sense to serve the metadata document from both locations?

-Daniel

---

From: Filip Skokan <[email-masked]>
Date: Mon, 8 Jun 2020 09:54:50 +0200

Some products publish both, but they don’t always return the same content, eventho as far as i can tell they should be aliases. 

The uri normalization of 8414 is also implemented wrong in some cases, since it differs from OIDC as far as issuer path component is concerned.

I find it best for AS to have just one or both with the same content, client software doing discovery can check both locations. 

Odesláno z iPhonu

> 8. 6. 2020 v 9:46, Daniel Fett <[email-masked]>:
> 
> 
> Hi all,
> 
> I found that some OAuth servers and clients instead follow the convention used by OpenID Connect, where the suffix "/.well-known/openid-configuration" (or "/.well-known/oauth-authorization-server") is appended to the issuer URL.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Daniel Fett <[email-masked]>
Date: Mon, 8 Jun 2020 11:15:07 +0200

Hi Filip,

Thanks for your answers!

I'm not quite sure if the wording in my question was clear: My main
concern is the difference between
https://example.com/some/path*/.well-known/oauth-authorization-server*
and
https://example.com*/.well-known/oauth-authorization-server*/some/path,
i.e., the usage of the well-known URI as a postfix or as an infix.

Am 08.06.20 um 09:54 schrieb Filip Skokan:
> Some products publish both, but they don’t always return the same
> content, eventho as far as i can tell they should be aliases.
> The uri normalization of 8414 is also implemented wrong in some cases,
> since it differs from OIDC as far as issuer path component is concerned.
This is where I'm not sure whether all products follow RFC8414 and
properly use the well-known part as an infix.
>
> I find it best for AS to have just one or both with the same content,
> client software doing discovery can check both locations.

That would be the safe implementation, but I was wondering if
prescribing this is a good choice for an ecosystem. That would mean that
all authorization servers in the ecosystem would need to implement both
https://example.com/some/path/.well-known/oauth-authorization-server and
https://example.com/.well-known/oauth-authorization-server/some/path.
Even if it is only an alias this could mean a considerable overhead for
some implementations.

-Daniel

-- 
https://danielfett.de

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 8 Jun 2020 15:50:31 -0700

> i.e., the usage of the well-known URI as a postfix or as an infix.

.well-known is only defined at the root of the path component of a URI.
Usage such as
https://example.com/some/path*/.well-known/oauth-authorization-server* is
noncompliant with RFC 5785.

-Ben

---

From: Daniel Fett <[email-masked]>
Date: Tue, 9 Jun 2020 09:42:27 +0200

> noncompliant with RFC 5785.

I know, but my impression is that since OIDC did it this way, some
clients are expecting the same behavior for RFC8414. Thus the question
if AS should be allowed or even required to offer the postfix variant in
an ecosystem.

-Daniel

-- 
https://danielfett.de

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 9 Jun 2020 13:08:00 +0300

On 08/06/2020 12:15, Daniel Fett wrote:
> prescribing this is a good choice for an ecosystem.

Postfix vs infix:

If we reason about the common ways ASes (as web apps) get deployed, then
(perhaps) it will become obvious which method is the most natural and
likely to be taken.

  * For an AS which gets deployed in a dedicated host, e.g. as
    as.example.com , the app root is likely to be
    https://as.example.com/ and hence the config URL becoming a simple
    postfix.

  * Multi-tenant ASes where each AS has a dedicated domain for each
    issuer also.

  * For an AS which gets deployed as part of some larger app (e.g. as
    module or package) on the same host, the AS is likely to end up at
    some path like https://example.com/as/ and hence the config being
    easier for a postfix URL.

  * Multi-tenant ASes which share a domain - this is not clear, but I
    suppose both postfix and infix can be made to work without the one
    method demanding more effort.

The infix is not natural, IMO, given the way apps get deployed. Postfix
seems more natural.

I may be wrong about these assumptions. But that's one good way to
approach the problem and specify something which implementers actually
find easier / natural. This, to me, is what an "ideal" technical
standard is.

Vladimir

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 21 Jun 2020 17:58:29 -0700

> if AS should be allowed or even required to offer the postfix variant in

Hmm, we don't seem to have gotten many replies on this question.  My own
individual opinion is "no", roughly on the grounds that doing it in the
wild starts a slippery slope and we don't want to get in the business of
encouraging BCP 190 violations.

-Ben