Hi, Kirk,

Thanks for the KIP. A few comments below.

JR1. OAuthBearerConfigurable.configure(): Could you describe the possible
values for saslMechanism? Is it always OAUTHBEARER?

JR2. If sasl.oauthbearer.jwt.retriever.class is not configured, what other
configs lead to the selection of JwtBearerJwtRetriever?

JR3. If sasl.oauthbearer.jwt.validator.class is not configured, how do we
choose which built-in class to use?

JR4. Could we document what type can be returned for Object in the
following?
public interface AssertionJwtTemplate extends OAuthBearerConfigurable {

    /**
     * Returns a map containing zero or more header values.
     *
     * @returns Values to include in the JWT header
     */
     Map<String, Object> header();

    /**
     * Returns a map containing zero or more JWT payload claim values.
     *
     * @returns Values to include in the JWT payload
     */
     Map<String, Object> payload();

JR5. "alg": RS256 : Should  RS256 be quoted?

JR6. "Step 2 is to create the JWT payload from the claims provided to
{@link #create(Map)}": The parameter for create() is not a Map.

JR7. For the new configuration table, could we document the type of each
new config?

JR8. Could we describe the format of sasl.oauthbearer.assertion.file?

JR9. sasl.oauthbearer.assertion.private.key.passphrase: In the "Mutually
exclusive configuration" part, it should say "If the
sasl.oauthbearer.assertion.file is used, this will be ignored.", right?

JR10. sasl.oauthbearer.assertion.expiration.minutes and
sasl.oauthbearer.assertion.not.before.minutes: Why are they in minutes
instead of seconds?

JR11. "Two of the JAAS options (clientId and clientSecret) for the existing
client_credentials grant type are deprecated." Should we
include sasl.oauthbearer.scope too?

Thanks,

Jun

On Fri, Mar 14, 2025 at 11:52 AM Kirk True <k...@kirktrue.pro> wrote:

> Hi all,
>
> I would like to start a discussion for KIP-1139: Add support for OAuth
> jwt-bearer grant type:
>
> https://cwiki.apache.org/confluence/x/uIxEF
>
> The proposal is twofold:
>
> * Add support for the OAuth 2.0 JWT Bearer grant type to avoid use of
> plaintext client secrets
> * Promote internal APIs for public use by this and future OAuth work
>
> Thanks!
> Kirk

Reply via email to