Should we add Core::Credentials::TokenCredential::GetName()?

[antkmsft]

Currently, that would be used for log messages that get emitted by ChainedTokenCredential, and would eliminate the need for internal constructor that is used by DefaultAzureCredential.

See #4409 (comment) and #4409 (comment)

[antkmsft]

@LarryOsterman in #4427 (comment):

Taking a second look at the changes to ChainedTokenCredential and I'm concerned about the use of the sourcesFriendlyNames parameter.

That parameter is pretty fragile, it needs to exactly match the parameters in the Sources list.
Instead of adding this parameter, why not add a GetFriendlyName virtual method to the TokenCredential base class and have the different credential classes implement that method. To avoid a breaking change, add a default implementation for GetFriendlyName which returns something neutral ("unknown"?), but that way we don't need to keep the order in sync.

I also suspect that having the GetFriendlyName method may be useful in other situations.

Once that happens, it's not clear that we need a private constructor for the ChainedTokenCredential, which reduces the complexity of the design.

[antkmsft]

I like GetFriendlyName(), let's implement it. We could not add it in time this time around, because it would require us to ship Core.

Practically, the constructor with sourcesFriendlyNames should not be that fragile, because it is only used by DefaultAzureCredential, and we should review the code if we change it. But I still agree with you, it is better to have GetName() method.

It is not, however, clear, what to do with the enclosingCredentialName parameter, how to keep that constructor internal only for identity.