[ACR] [Before GA] Update cloud configuration API

[annelo-msft]

Once the service team has added data plane scopes, we will update the AuthenticationScope property on ClientOptions as follows:

• Remove AuthenticationScope property
• Add Audience (or similarly named) property instead
• Audience is an extensible enum, containing the audience strings for known clouds; the user can override with a string if needed
• If Audience is set, client library will append /.default to Audience value to specify the default scope
• Audience will default to data-plane scope root, which should be common across clouds

In Java, we will need to determine whether we will also use prior approach with Credential Scope

• Python will not support this even though they also have this precedent
• .NET will not support this

Please see Azure/azure-sdk-for-net#21603 for more details.

[annelo-msft]

@pallavit @alzimmermsft @schaabs FYI

[pallavit]

@srnagar adding you to the thread to get guidance on this one.

[alzimmermsft]

@annelo-msft, after reading the issue filed in the .NET repository it appears that there is an options bag specific to Container Registry that is being used to pass the AuthenticationScope, is that correct? If so, ClientOptions in Java is a much broader concept in azure-core which is meant for high-level, sharable properties such as logging configurations, so would that be the correct location to add AuthenticationScope? Or, instead should AuthenticationScope be added as a configuration to the client builders that Java uses?

cc: @srnagar

[annelo-msft]

@alzimmermsft, I don't have a good enough understanding of the difference between ClientOptions in Java and configuration passed to builders. In .NET (you can see the ACR API here) each service library subclasses the Azure.Core ClientOptions type, which is then used for general Azure.Core concepts as well as service-specific configurations.

If adding it to Java's ClientOptions is effectively adding it to azure-core, then we probably don't want to do this. There is broader SDK-wide guidance for cloud configuration coming at some point (see Johan's PR on this if you haven't already). If client builder configuration is the recommended way to add service-specific options in Java, that would be the right thing, as AuthenticationScope (and the Audience property we'll migrate too once the service has made its audience/scope changes) are intended to be service-specific until the broader guidance lands.

[alzimmermsft]

@alzimmermsft, I don't have a good enough understanding of the difference between ClientOptions in Java and configuration passed to builders. In .NET (you can see the ACR API here) each service library subclasses the Azure.Core ClientOptions type, which is then used for general Azure.Core concepts as well as service-specific configurations.

If adding it to Java's ClientOptions is effectively adding it to azure-core, then we probably don't want to do this. There is broader SDK-wide guidance for cloud configuration coming at some point (see Johan's PR on this if you haven't already). If client builder configuration is the recommended way to add service-specific options in Java, that would be the right thing, as AuthenticationScope (and the Audience property we'll migrate too once the service has made its audience/scope changes) are intended to be service-specific until the broader guidance lands.

Yes, that is correct, ClientOptions in Java is the azure-core concept, so this will be an update to the client builder.