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

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. > >

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

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.

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

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!

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

+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.

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

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.

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

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

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

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.

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

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

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

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