Hi all, The KIP-1025 is now accepted with 3 +1 binding votes(Manikumar, Mickael, Chris) and 2 +1 non-binding votes(Doğuşcan, Kirk).
Thanks to everyone who took part in the discussion and voting! I've opened a PR implementing this KIP here: https://github.com/apache/kafka/pull/15475. Please feel free to review it if you have time. Thanks! On Sun, Jun 30, 2024 at 1:52 AM Chris Egerton <fearthecel...@gmail.com> wrote: > Hi Nelson, > > Thank you for your patience! I like the plan for 4.0.0 and agree it'd be > nice to land this KIP in time for 3.9.0. > > +1 (binding) > > Cheers, > > Chris > > On Wed, Jun 26, 2024 at 8:44 PM Nelson B. <bachmanity...@gmail.com> wrote: > > > 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, > > >> > > > >>>>> > > >> > > > >>>> > > >> > > > >>> > > >> > > > >> > > >> > > > > > >> > > > > >> > > > > > >
