We previously made a change to several of the request APIs to return UNKNOWN_TOPIC_OR_PARTITION if the principal does not have Describe access to the topic. The thought was to avoid leaking information about which topics exist. The problem with this is that a client which sees this error will just keep retrying because it is usually treated as retriable. It seems, however, that we could return TOPIC_AUTHORIZATION_FAILED instead and still avoid leaking information as long as we ensure that the Describe authorization check comes before the topic existence check. This would avoid the ambiguity on the client.