Ben Kehoe

Fascinating! If I'm not mistaken, though, even though the fetcher does [interesting stuff to calculate an expiration](https://github.com/boto/botocore/blob/350331326f9fe364baf105526beccecb44043da1/botocore/utils.py#L649), the IMDS provider still ends up [creating a `RefreshableCredentials` with a static expiration...

Thanks. Seems like it should be part of the response shape. In this case, the `error_description` field is required by the OAuth spec: https://tools.ietf.org/html/rfc6749#section-5.2

I have a comprehensive implementation with `aws-assume-role-lib`, including type annotations, parameter validation, allowing nicer parameter types (policy as JSON, duration as timedelta, etc). It can also monkeypatch boto3 to add...

Actually, in looking at the other SDKs, an inconsistency is that botocore allows 169.254.170.2 in `AWS_CONTAINER_CREDENTIALS_FULL_URI`, where at least Go and JavaScript v2 only allow localhost/127.0.0.1 in `AWS_CONTAINER_CREDENTIALS_FULL_URI` and use...

I have solved this for now in my [`aws-export-credentials`](https://github.com/benkehoe/aws-export-credentials#credential-serving-options-eg-for-providing-creds-to-containers) tool by providing an IMDSv2-compatible endpoint; the IMDS endpoint is not subject to the same host checks. I think this issue...

What I _really_ want, though this is a tall order, is for the credential process spec to allow for interactivity. Let me send something like this to `stdout`: ```json {...

> Why is that preferable to attaching stderr? @jonathanmorley because then the SDK could provide hooks into the interaction, so an application could potentially include the authentication as part of...

I think there is confusion about "user" here. You've got "user" as part of the profile name, but a profile configured for an AWS SSO role *does not and cannot...

The token in `~/.aws/sso/cache` is **not** associated with a role. The token is associated with the *human* who has logged into AWS SSO, and grants access to any of account+roles...

To repeat, you are misunderstanding the relationship between the token in `~/.aws/sso/cache` and the profile: **the token in `~/.aws/sso/cache` is not "for" the profile used in `aws sso login`, it...