@harkamaljot you had worked on optimizing this call somewhere else in the code recently. Can you PTAL at this method and see if there are any issues in doing this call or something can be optimized.

I optimized this call when getting token for the service account, however for getting the trust boundary looks like we need service account email. Based on the documentation(http://cloud/iam/docs/reference/credentials/rest/v1/projects.serviceAccounts/getAllowedLocations) and also trying it out manually as well, I get 400 error when querying this endpoint using default.

Lets revert these changes and keep them for a future PR. We should only add this with the changes for supporting the feature

One suggestion for a potential refactoring to improve the design:

Currently, each class that inherits fromCredentialsWithTrustBoundary (e.g.,compute_engine.Credentials,impersonated_credentials.Credentials,service_account.Credentials) is required to explicitly callself._refresh_trust_boundary(request) within its ownrefresh method.

To enhance encapsulation and reduce the burden on subclasses, it would be preferable if this call was handled automatically by the base class. Could this be refactored?

That's a great suggestion!
I've refactored the CredentialsWithTrustBoundary base class to handle this. The base refresh() method now handles the entire refresh process. It calls a new abstract method, _refresh_token(), which subclasses must implement, and then it calls _refresh_trust_boundary() itself.

How does this work for self signed JWTs?

I've updated service_account.Credentials to handle self signed JWTs. When a credential that uses a self-signed JWT also needs to perform a trust boundary lookup, the refresh() method now follows a two-step process:

1. IAM-Specific JWT for Lookup: It first generates a temporary self-signed JWT where the audience is specifically set to the IAM Credentials API. This token is used exclusively to authenticate the request that fetches the trust boundary information.

2. Final JWT for Target API: After the trust boundary is successfully retrieved, the method then proceeds to generate the final self-signed JWT with the audience required by the application's target API (e.g., Pub/Sub, Storage).

This approach ensures that the trust boundary lookup is authenticated correctly using a token the IAM service expects, while the final token used by the application is properly configured for its intended service.

Is this method necessary? When would it be used?

The with_* method is part of a design pattern used for credential objects throughout this library.

We treat credential objects as mostly immutable. You'll see similar factory methods like with_scopes(), with_quota_project(), and with_universe_domain().

Would prefer to not have commented placeholders here and just add in another PR

Thanks for the feedback—I agree it's best to avoid placeholders.

The challenge here is that the commented-out value ("x-allowed-locations": "0x0") is from two years ago and is incorrect under the new design.. Since support for external accounts is out of scope for this particular PR, uncommenting this line would cause tests to fail with the wrong assertion.

I've kept it commented to preserve the test structure for the follow-up PR that will correctly implement this feature for external accounts.

Given this context, would you be okay with keeping these placeholders for this PR, or would you prefer I remove the them and create a separate tracking issue?

Same here

Why do we have to pass trust boundary header for id token request?_get_trust_boundary_header might not give the headers because an access token is not available in this credential.

You're right. Thank you for catching this. Initially we thought idtoken would need trust boundary too, but we determined that it's not a supported credential and I reverted these changes.

This seems to be welcoming race conditions. What happens if one thread is updating trust boundary and setself.token to iam audience and another thread tries to readself.token

Reverted this change since we're still waiting to hear back from the backend team on whether or not the workaround is necessary. We'll address self signed jwt flow if necessary in a future PR.

you will get NotImplementedError here, thrown from ln 863?

Also, there is no access token in this cred to call trust boundary endpoint

I reverted the changes to idtoken as it turns out it doesn't need trust boundaries. Thanks for flagging it!