we shouldn't need to expose this since it's only necessary to provide it when using instance profile credentials. Instance profile credentials will be used when no access key or sercret are provided.

It is actually needed when we use role credentials. Storing credentials in config files is discouraged in favour of using roles, and to follow that route we will need the token. That is exactly my case by the way - I run my app in a docker container which is registered in an ECS task. The task is assigned a role which is different from the instance's role and has all the necessary permissions. I extract credentials from my task role and have to pass them along with the token to be able to use them. There are other scenarios when we might need to pass the token. For example, when we want to work with assumed roles or want to use temporary (session) credentials derived from other credentials. In fact, I was thinking that since the user knows best what credentials they want to use including the token, they should always pass all authentication data to the library. Or we can call internally Amazon.Runtime.FallbackCredentialsFactory.GetCredentials() which will create dependency on AWSSDK.Core, but it's still better than always assuming that we should get the instance role. These further changes are perhaps subject of a longer conversation, so let's leave it as it is for now.

Okay, that makes sense then.

This can be internal. I'd rather expose only what the consumer needs.

I agree.

internal.

internal

internal