Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header

2024-06-30 Thread Nelson B. 
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 
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.  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. 
> > 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. 
> > >> 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 
> > >> wrote:
> > >> >
> > >> > > Thanks for the KIP.
> > >> > >
> > >> > > +1 (binding)
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Mon, Apr 8, 2024 at 9:49 AM Kirk True 
> 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
> > >> > > > > <
> > >> > > > >
> > >> > > > 
> > >> > > > >>>
> > >> > > > >>
> > >> > >
> > >

Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header

2024-06-29 Thread Chris Egerton 
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.  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. 
> 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  >
> > wrote:
> >
> >> Hi,
> >>
> >> +1 (binding)
> >> Thanks for the KIP!
> >>
> >> Mickael
> >>
> >> On Sun, Apr 21, 2024 at 7:12 PM Nelson B. 
> >> 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 
> >> wrote:
> >> >
> >> > > Thanks for the KIP.
> >> > >
> >> > > +1 (binding)
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On Mon, Apr 8, 2024 at 9:49 AM Kirk True  wrote:
> >> > > >
> >> > > > +1 (non-binding)
> >> > > >
> >> > > > Apologies. I thought I’d already voted :(
> >> > > >
> >> > > > > On Apr 7, 2024, at 10:48 AM, Nelson B.  >
> >> > > 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,
> >> > > > >
> >> > > > 
> >> > > > >>>
> >> > > > >>
> >> > > >
> >> > >
> >>
> >
>

Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header

2024-06-26 Thread Nelson B. 
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.  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 
> wrote:
>
>> Hi,
>>
>> +1 (binding)
>> Thanks for the KIP!
>>
>> Mickael
>>
>> On Sun, Apr 21, 2024 at 7:12 PM Nelson B. 
>> 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 
>> wrote:
>> >
>> > > Thanks for the KIP.
>> > >
>> > > +1 (binding)
>> > >
>> > >
>> > >
>> > >
>> > > On Mon, Apr 8, 2024 at 9:49 AM Kirk True  wrote:
>> > > >
>> > > > +1 (non-binding)
>> > > >
>> > > > Apologies. I thought I’d already voted :(
>> > > >
>> > > > > On Apr 7, 2024, at 10:48 AM, Nelson B. 
>> > > 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. > >
>> > > 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,
>> > > > >
>> > > > 
>> > > > >>>
>> > > > >>
>> > > >
>> > >
>>
>

Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header

2024-06-11 Thread Nelson B. 
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 
wrote:

> Hi,
>
> +1 (binding)
> Thanks for the KIP!
>
> Mickael
>
> On Sun, Apr 21, 2024 at 7:12 PM Nelson B.  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 
> wrote:
> >
> > > Thanks for the KIP.
> > >
> > > +1 (binding)
> > >
> > >
> > >
> > >
> > > On Mon, Apr 8, 2024 at 9:49 AM Kirk True  wrote:
> > > >
> > > > +1 (non-binding)
> > > >
> > > > Apologies. I thought I’d already voted :(
> > > >
> > > > > On Apr 7, 2024, at 10:48 AM, Nelson B. 
> > > 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. 
> > > 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,
> > > > >
> > > > 
> > > > >>>
> > > > >>
> > > >
> > >
>

Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header

2024-05-15 Thread Mickael Maison 
Hi,

+1 (binding)
Thanks for the KIP!

Mickael

On Sun, Apr 21, 2024 at 7:12 PM Nelson B.  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  wrote:
>
> > Thanks for the KIP.
> >
> > +1 (binding)
> >
> >
> >
> >
> > On Mon, Apr 8, 2024 at 9:49 AM Kirk True  wrote:
> > >
> > > +1 (non-binding)
> > >
> > > Apologies. I thought I’d already voted :(
> > >
> > > > On Apr 7, 2024, at 10:48 AM, Nelson B. 
> > 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. 
> > 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. 
> > > >> 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,
> > > >
> > > 
> > > >>>
> > > >>
> > >
> >

Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header

2024-04-21 Thread Nelson B. 
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  wrote:

> Thanks for the KIP.
>
> +1 (binding)
>
>
>
>
> On Mon, Apr 8, 2024 at 9:49 AM Kirk True  wrote:
> >
> > +1 (non-binding)
> >
> > Apologies. I thought I’d already voted :(
> >
> > > On Apr 7, 2024, at 10:48 AM, Nelson B. 
> 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. 
> 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. 
> > >> 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,
> > >
> > 
> > >>>
> > >>
> >
>

Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header

2024-04-07 Thread Manikumar 
Thanks for the KIP.

+1 (binding)




On Mon, Apr 8, 2024 at 9:49 AM Kirk True  wrote:
>
> +1 (non-binding)
>
> Apologies. I thought I’d already voted :(
>
> > On Apr 7, 2024, at 10:48 AM, Nelson B.  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 
> > 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.  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  >>>
> >>> 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. 
> >> 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,
> >
> 
> >>>
> >>
>

Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header

2024-04-07 Thread Kirk True 
+1 (non-binding)

Apologies. I thought I’d already voted :(

> On Apr 7, 2024, at 10:48 AM, Nelson B.  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 
> 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.  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 >> 
>>> 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. 
>> 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,
> 
 
>>> 
>>

Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header

2024-04-07 Thread Nelson B. 
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 
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.  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  >
> > 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. 
> 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,
> > > >
> > >
> >
>

Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header

2024-03-27 Thread Doğuşcan Namal 
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.  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 
> 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.  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,
> > >
> >
>

Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header

2024-03-25 Thread Nelson B. 
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 
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.  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,
> >
>

Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header

2024-03-20 Thread Doğuşcan Namal 
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.  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,
>

[VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header

2024-03-19 Thread Nelson B. 
Hi all,

I would like to start a vote on KIP-1025
,
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,