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

[Filip Skokan <[e-mail]>]

Preemptive send, sorry. That question was not clear from your text to me. 

When it comes to client’s discovery, at least my software does the following - when issuer is passed in it does oidc’s well known (openid-configuration) as a suffix and 8414’s well known (oauth-authorization-server) as an infix. According to both specs. Whichever returns first gets used as they as far as i can tell should be aliases. 

When discovery is performed with a URL that contains the keyword well-known, it just fetches that resource directly. 

This way the software is working as intended for conform ASs’ and developers can still use the non conform ones by passing the well known location directly.

Odesláno z iPhonu

> 8. 6. 2020 v 11:47, Filip Skokan <[e-mail]>:
> 
> That question was not clear from your text, you 
> 
> Odesláno z iPhonu
> 
>> 8. 6. 2020 v 11:15, Daniel Fett <[e-mail]>:
>> 
>> 
>> 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
>> 
>>> 
>>> Odesláno z iPhonu
>>> 
>>>> 8. 6. 2020 v 9:46, Daniel Fett <[e-mail]>:
>>>> 
>>>> 
>>>> 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
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> -- 
>> https://danielfett.de