Hi all, Just a kind reminder. I would really appreciate if we could get two more binding +1 votes.
Thanks On Mon, Apr 8, 2024, 2:08 PM Manikumar <manikumar.re...@gmail.com> wrote: > Thanks for the KIP. > > +1 (binding) > > > > > On Mon, Apr 8, 2024 at 9:49 AM Kirk True <k...@kirktrue.pro> wrote: > > > > +1 (non-binding) > > > > Apologies. I thought I’d already voted :( > > > > > On Apr 7, 2024, at 10:48 AM, Nelson B. <bachmanity...@gmail.com> > wrote: > > > > > > Hi all, > > > > > > Just wanted to bump up this thread for visibility. > > > > > > Thanks! > > > > > > On Thu, Mar 28, 2024 at 3:40 AM Doğuşcan Namal < > namal.dogus...@gmail.com> > > > wrote: > > > > > >> Thanks for checking it out Nelson. Yeah I think it makes sense to > leave it > > >> for the users who want to use it for testing. > > >> > > >> On Mon, 25 Mar 2024 at 20:44, Nelson B. <bachmanity...@gmail.com> > wrote: > > >> > > >>> Hi Doğuşcan, > > >>> > > >>> Thanks for your vote! > > >>> > > >>> Currently, the usage of TLS depends on the protocol used by the > > >>> authorization server which is configured > > >>> through the "sasl.oauthbearer.token.endpoint.url" option. So, if the > > >>> URL address uses simple http (not https) > > >>> then secrets will be transmitted in plaintext. I think it's possible > to > > >>> enforce using only https but I think any > > >>> production-grade authorization server uses https anyway and maybe > users > > >> may > > >>> want to test using http in the dev environment. > > >>> > > >>> Thanks, > > >>> > > >>> On Thu, Mar 21, 2024 at 3:56 PM Doğuşcan Namal < > namal.dogus...@gmail.com > > >>> > > >>> wrote: > > >>> > > >>>> Hi Nelson, thanks for the KIP. > > >>>> > > >>>> From the RFC: > > >>>> ``` > > >>>> The authorization server MUST require the use of TLS as described in > > >>>> Section 1.6 when sending requests using password authentication. > > >>>> ``` > > >>>> > > >>>> I believe we already have an enforcement for OAuth to be enabled > only > > >> in > > >>>> SSLChannel but would be good to double check. Sending secrets over > > >>>> plaintext is a security bad practice :) > > >>>> > > >>>> +1 (non-binding) from me. > > >>>> > > >>>> On Tue, 19 Mar 2024 at 16:00, Nelson B. <bachmanity...@gmail.com> > > >> wrote: > > >>>> > > >>>>> Hi all, > > >>>>> > > >>>>> I would like to start a vote on KIP-1025 > > >>>>> < > > >>>>> > > >>>> > > >>> > > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1025%3A+Optionally+URL-encode+clientID+and+clientSecret+in+authorization+header > > >>>>>> , > > >>>>> which would optionally URL-encode clientID and clientSecret in the > > >>>>> authorization header. > > >>>>> > > >>>>> I feel like all possible issues have been addressed in the > discussion > > >>>>> thread. > > >>>>> > > >>>>> Thanks, > > >>>>> > > >>>> > > >>> > > >> > > >
