Try to make configauth public API independent from extensionauth

[mx-psi]

Component(s)

No response

Describe the issue you're reporting

Right now configauth depends on extensionauth explicitly in its API. Can we make it so that this is hidden from the user?

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[mx-psi]

@bogdandrutu Do you think this is doable? Is the approach in #12702 still the best way to go? I am happy to take this up if you share your thoughts

[jade-guiton-dd]

My understanding of this issue and the two PRs (#12702 and #13586) associated to it is that the goal is two-fold:

1. make the configauth API easier to use directly, by integrating the code from configgrpc / confighttp which wraps the extensionauth interfaces into gRPC/HTTP options
2. decouple the config APIs from the extension APIs, in a way that is similar to the vision for the dependency hierarchy outlined in Define dependency hierarchy between core modules  #9491

Regarding point 1: I don't think this is a significant advantage unless we expect or want to encourage gRPC/HTTP components to use configauth directly, instead of relying on configgrpc/confighttp. Moreover, the gRPC/HTTP auth interfaces are straightforward enough that writing the wrappers (auth*Interceptor) manually is not much trouble. So, while it could be slightly more elegant, I don't think it has a very big impact.

Regarding point 2: I don't think this issue really helps with establishing a "dependency hierarchy", since configauth will still depend on extensionauth internally, just not in its API. And considering our config packages contain many helper methods, I think there are significant use cases for these methods to use extension interfaces, and for extension interfaces to refer to config structs. So I would be tempted to say that extension interfaces and config packages should not be on separate levels on hierarchy, but should be allowed to depend on each other. (Note that I'm drawing a distinction between extension interfaces and extension implementations, which should remain high in the hierarchy.)

So overall, I'm not certain that there are strong benefits to completing this issue, and I think that we may want to forgo it in favor of stabilizing configauth if there is no push to implement it in the near future.

[mx-psi]

I discussed this with Jade and tend to agree with her. @open-telemetry/collector-approvers any thoughts?

I will close this as wontfix in one week unless somebody opposes this before then.

[mx-psi]

Closing this as wontfix per discussion above