Federating into GCP via AWS , STS token API Fails with "AWS request has invalid format" Despite Following GCP Docs Exactly

I’m encountering an issue while trying to exchange a signed AWS
GetCallerIdentity request for a Google Cloud access token via the
Workforce Identity Federation mechanism. Despite following your official
documentation line by line, I consistently receive the following error from the
GCP STS token endpoint:
“error_description”: "AWS request has invalid format."​

Documentation Followed
I’ve strictly implemented the process using the steps outlined in your official
documentation:
1.​ Workload Identity Federation with Other Clouds​
2.​ STS token API Reference​
The error occurs during the final step — calling
sts.googleapis.com/v1/token with the signed AWS request as
the subjectToken.
What I’ve Done
●​ I assumed a role via AWS STS and obtained temporary credentials
successfully.​
●​ I constructed the GetCallerIdentity request and signed it using AWS
Signature V4, including the required headers.​
●​ I serialized the request following GCP’s requirements:{
“url”:“https://sts.amazonaws.com?Action=GetCallerIdentity&Version=2011-06-15
“method”: “POST”,
“headers”: [
{ “key”: “authorization”, “value”: “AWS4-HMAC-SHA256 …” },
{ “key”: “host”, “value”: “sts.amazonaws” },
{ “key”: “x-amz-date”, “value”: “…” },
{ “key”: “x-amz-security-token”, “value”: “…” },
{ “key”: “x-amz-content-sha256”, “value”: “…” },
{ “key”: “x-goog-cloud-target-resource”, “value”: “…” }
]
}
Problems & Inconsistencies in the Documentation
1.​ Misleading Error Message​
The error “AWS request has invalid format” is too generic to
help identify the actual issue. There’s no indication of which part is invalid
— the header, signature, request body, etc. This makes troubleshooting
extremely difficult.​
2.​ Discrepancies Between Docs and What GCP Expects​
○​ There’s no working example payload or curl equivalent showing
what the final subjectToken should look like.​3.​ Lack of Concrete Examples​
Unlike other Google APIs, this one offers no test tool or verified example
request that a developer can replicate and debug against. This is
especially problematic when the failure response gives no actionable
feedback.​

Request
I would greatly appreciate if you could:
●​ Provide a verified working example of a full signed AWS request and
how it should be encoded for use as a subjectToken.​
●​ Clarify exactly which headers must be included in the signed AWS
request and which of them must appear in the SignedHeaders list.​
●​ Confirm whether the x-goog-cloud-target-resource header must
be included in both the headers array and the AWS Signature, or only
sent as a regular header.​
●​ Improve the STS token API error reporting (or suggest a debug mode) so
developers aren’t left guessing what part of the request is considered
invalid.


Summary
I’ve followed your official guidance to the letter, yet the error I receive is
vague, and the docs seem to omit critical information. As a developer
trying to correctly implement a cross-cloud integration using secure,
documented approaches, this experience has been unexpectedly opaque
and frustrating.
Your support in resolving this — or simply confirming a working end-to-end
example — would be greatly appreciated.