Currently there is single feature TOKEN_EXCHANGE for various token exchange use-cases:

• Internal to internal token exchange (specification compliant)
• Federated token exchange (for external-internal or internal-external)
• Subject impersonation use-cases (Changing the subject, which include also direct naked impersonation)

It can be good to divide this into 3 dedicated features, so we can introduce support for some of them (EG. internal-internal) and keep the others in preview.

The goal of this task is to divide the feature into 3 features introduced in the Profile and still have all of them in preview for now. There would need to be note in the release notes and upgrading guide added about this.

NOTE: For the 3rd case, I've rather propose feature like TOKEN_EXCHANGE_SUBJECT_IMPERSONATION . The TOKEN_EXCHANGE_IMPERSONATION is shorter, but could be confusing because token-exchange specification itself has a concept called "impersonation" (see here), but it is not about changing the subject, but regular specs compliant token-exchange request. So the name like TOKEN_EXCHANGE_IMPERSONATION may imply that it is about this specs-compliant impersonation rather than "subject impersonation" .

Implementation notes

Not 100% sure if it is best, but maybe we can keep single implementation of TokenExchangeGrantType, but have 3 implementations of TokenExchangeProvider ?

I can imagine something like TokenExchangeGrantTypeFactory updated to something like this:

    @Override
    public boolean isSupported(Config.Scope config) {
        return Profile.isFeatureEnabled(Profile.Feature.TOKEN_EXCHANGE) || 
                  Profile.isFeatureEnabled(Profile.Feature.FEDERATED_TOKEN_EXCHANGE) || 
                  Profile.isFeatureEnabled(Profile.Feature.TOKEN_EXCHANGE_SUBJECT_IMPERSONATION);
    }

And then have 3 implementations of TokenExchangeProviderFactory, which would themselves implement EnvironmentDependentFactory and be enabled just if particular feature of the three features above is enabled. The method supports of each of this provider will need to be implemented, so the provider can decide if token-exchange request is suited for it's needs (For example if request contains parameter requested_subject, then it is subject-impersonation request, if the subject_token_type is urn:ietf:params:oauth:token-type:jwt or parameter subject_issuer is included, then it is external-to-internal tc).