Hi,
In most cases where I've been involved with implementing a single RFC
defined .well-known URL for actually servicing all end points, it ends
up being one .well-known for default configuration, and multiple other
(not .well-known) URLs in order to handle other configurations in
multi-tennant
Hi Ludwig,
I'm confident that a well-known URI (or link relation) for discovery of RS
configuration/parameters would address the BCP 190 concerns. What we need
is an obvious path to not stomp on the server owner's namespace, and
whether we do that by letting the server tell us what what path to
We should make sure to keep draft-tiloca-core-oscore-directory in mind for
this. It has a relation link defined for the Authorization server.
Jim
-Original Message-
From: Ace On Behalf Of Carsten Bormann
Sent: Monday, June 1, 2020 7:52 AM
To: Seitz Ludwig
Cc: Benjamin Kaduk ;
On 2020-06-01, at 11:13, Seitz Ludwig wrote:
>
> Hi Ben,
>
> I had a look at the well-known URI list at IANA and it seems that for vanilla
> OAuth 2.0 endpoints (authorization, token, introspect) there are no
> well-known URI:s either. What exists is an URI used by the authorization
> server
Hi Ben,
I had a look at the well-known URI list at IANA and it seems that for vanilla
OAuth 2.0 endpoints (authorization, token, introspect) there are no well-known
URI:s either. What exists is an URI used by the authorization server to
self-describe (including attributes giving the values of
