...

• What impact (if any) will there be on existing users?
  • Users will get error when trying to add Principal types that authorizer does bot support. So, less silent errors.
• If we are changing behavior how will we phase out the older behavior?
  • There is no behavior change. KIP proposal is to make sure users don't make unintended mistakes.
• If we need special migration tools, describe them here.
  • None.
• When will we remove the existing behavior?
  • NA.

Rejected Alternatives

The KIP discusses a couple of ways to specify supported principal types. Based on what we choose to go ahead with, one of them will come here.

• Add validation at Authorizer level. Having validation done at client side enables clients to fail fast for invalid principal types, whereas implementing it at authorization level removes the requirement of having the validation done on each client implementation.
• An alternative of providing supported Principal types via interface is via a config option. Having a config option will be helpful for certain third party implementations that uses SimpleAclAuthorizer but support more PrincipalTypes. However, it requires adds one more config.