Sorry to chime in late as well…
I support adoption of this draft. I have read the thread and to me it seems
like there is a mechanism being proposed that solved a concrete problem in
a simple manner. Some of the discussion can happen after the draft is
adopted.
Best,
Kristina
On Wed, Jun 26, 2024
> If we have a tenant" distinguished by a path, there is already a security
issue with giving it the X509 certificate. It could then imitate any
other tenant
on that server already. That's why we use reverse proxies and put the
certificate only on the proxying machines.
In large deployments, like
Sorry to chime in late here. I'm in favor of adopting this draft. While I
realize that X.509 isn't for everyone, there is an established community of
users out there that overlaps with OAUTH users. I think there are needs to
both separate the distribution of the keys from the establishment of tru
On Tue, Jun 25, 2024 at 2:56 PM Michael Jones
wrote:
>
> The other critique I voiced of the approach is that the application-level
> X.509 certificate can be used to secure the HOST part of the issuer, but not
> the entire issuer, since in general, the issuer will contain a PATH. Yes,
> the se
The other critique I voiced of the approach is that the application-level X.509
certificate can be used to secure the HOST part of the issuer, but not the
entire issuer, since in general, the issuer will contain a PATH. Yes, the
service hosting the issuers controls all the paths, as Richard rep
Hi all,
Replying to the top of the thread again to recap the arguments so far.
(Hoping the chairs will give us a moment more to discuss before calling
cloture.)
It seems like Sharon, Rohan, Watson, and I are all on the same page w.r.t.
the X.509-based mechanisms in the current draft. In particul
