Hi all, I want to bring up this thread once more.
I am hoping to include this KIP in the 3.9.0 release. The KIP freeze is on July 3rd (next Wednesday), so it would be great if we could finalize the vote by then. We are targeting the 3.9.0 release because we plan to piggyback on KIP-1030 and change the default value of the `sasl.oauthbearer.header.urlencode` parameter to `true` starting from release 4.0.0. This change will align the oauthbearer handler implementation with RFC-6749. Thanks. On Tue, Jun 11, 2024 at 10:39 PM Nelson B. <bachmanity...@gmail.com> wrote: > Hi all, > > I want to bump up this thread for visibility. > Currently, this KIP is one binding vote short of being accepted. > > Thanks! > > > On Thu, May 16, 2024 at 1:07 AM Mickael Maison <mickael.mai...@gmail.com> > wrote: > >> Hi, >> >> +1 (binding) >> Thanks for the KIP! >> >> Mickael >> >> On Sun, Apr 21, 2024 at 7:12 PM Nelson B. <bachmanity...@gmail.com> >> wrote: >> > >> > 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, >> > > > >>>>> >> > > > >>>> >> > > > >>> >> > > > >> >> > > > >> > > >> >
