Default sensitive query parameter list is stale relative to semantic conventions (SigV2 instead of SigV4)

Start in instrumentation-api/src/main/java/io/opentelemetry/instrumentation/api/internal/HttpConstants.java and trace the default set through UrlQuerySanitizer.java, especially redactInternal. Check UrlAttributesExtractor.java to confirm how the set is used, then run the relevant instrumentation-api tests. Done means SigV4 sensitive values are redacted by default while the deprecated SigV2 names are no longer included.

Describe the bug

HttpConstants.SENSITIVE_QUERY_PARAMETERS still lists the AWS SigV2 query parameter names. Semantic conventions replaced these with the SigV4 names in open-telemetry/semantic-conventions#3779 (2026-06-10, "Update broken links and deprecated AWS signature v2 examples"), and we haven't caught up.

Matching is exact — redactInternal does paramsToRedact.contains(currentParamName) — so Signature does not cover X-Amz-Signature. The indexOf check in containsParamToRedact is only an allocation fast path and doesn't affect what gets redacted.

This affects every instrumentation on the standard path (all HTTP clients plus the server-side url.query extractor), at default configuration.

Steps to reproduce

1. Attach the javaagent to any application that makes an HTTP client call.
2. Have it request a SigV4 presigned S3 URL, i.e. one carrying X-Amz-Algorithm, X-Amz-Credential, X-Amz-Date, X-Amz-Expires, X-Amz-SignedHeaders, X-Amz-Signature (plus X-Amz-Security-Token when using temporary credentials).
3. Inspect the url.full attribute on the resulting client span.

Expected behavior

Per semantic conventions, X-Amz-Signature, X-Amz-Credential, and X-Amz-Security-Token values are replaced with REDACTED, with the keys preserved.

Actual behavior

All three are emitted verbatim. Conversely, AWSAccessKeyId and Signature are redacted even though the spec no longer lists them.

Javaagent or library instrumentation version

main (a459b7f)

Environment

JDK: any
OS: any

Additional context

The constant was introduced in #16097 (2026-03-09), which matched the spec as it stood at the time; the spec moved afterwards.

Two related things worth looking at while in here:

• UrlAttributesExtractor hardcodes HttpConstants.SENSITIVE_QUERY_PARAMETERS rather than accepting the configured set, so that standalone extractor isn't user-overridable. May well be intentional — worth confirming.
• Whether it's worth a test that pins the default list against the spec, so the next semconv change doesn't silently drift again.

Note that fixing this constant alone does not cover AWS Lambda behind API Gateway, which is the place SigV4 query-string parameters are most likely to show up on the server side. That path never reaches the sanitizer at all — see the companion issue on instrumentations that bypass URL sanitization.