Re: [OAUTH-WG] draft-ietf-oauth-jwsreq-21

2020-06-08 Thread Nat Sakimura
Hi Brock, Starting from the easy one: 3) has been addressed. It does not break the existing OIDC implementation either as there is no requirements as to the mime-type checking there. Now, 2) will break all OIDC implementations. It is quite late to bring this in and I and my colleagues did not fin

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

2020-06-08 Thread Benjamin Kaduk
On Mon, Jun 08, 2020 at 11:15:07AM +0200, Daniel Fett wrote: > 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:

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

2020-06-08 Thread Joseph Heenan
Hi James, > On 5 Jun 2020, at 03:23, Manger, James > wrote: > If you merely want to trigger a different look-n-feel, define a “brand” > parameter to add the to the authorization request. Unfortunately this doesn’t work when the authorization endpoint is a claimed https url for a mobile app:

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

2020-06-08 Thread Filip Skokan
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

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

2020-06-08 Thread Daniel Fett
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 usa

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

2020-06-08 Thread 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. I find it best for AS

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

2020-06-08 Thread Daniel Fett
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 "/.w