Google Cloud X.509 WIF — attribute_condition_rejected with an authority-less URN URI SAN

We are investigating a production authentication issue involving Google Cloud X.509 Workload Identity Federation.

A client presents an existing CA-issued X.509 certificate to https://sts.mtls.googleapis.com/v1/token.

The STS exchange returns:

HTTP 400
unauthorized_client
The given credential is rejected by the attribute condition.

Our provider uses the following mapping:

google.subject = assertion.san.uri

And a condition equivalent to:

assertion.san.uri == "urn:example:backup:node-1" &&
assertion.sha256Fingerprint == "<standard-padded-Base64-SHA256-of-leaf-DER>"

The identifiers above are representative, not our actual production values.

Already established:

• The certificate contains the expected single URI SAN.

• Its locally computed DER SHA-256 fingerprint matches the configured value.

• The configured trust anchor matches the intended public CA.

• The request construction follows Google's published X.509 WIF format.

• Local OpenSSL verification succeeds.

• LibreSSL 3.3.6 reports error 53 (unsupported or invalid name syntax) for the authority-less URI SAN. Its published source explains that local parser behavior.

• The provider's stored mapping and condition were read back and matched the intended configuration.

• No successful STS exchange has been observed.

We have not established Google's actual evaluated assertion values.

We need an authoritative answer to four specific questions:

1. Does Google Cloud X.509 Workload Identity Federation support authority-less, non-hierarchical URI SAN values such as urn:example:backup:node-1 in assertion.san.uri? Is the exact IA5String preserved, or does the extractor require a //host authority component?

2. Is assertion.sha256Fingerprint guaranteed to use standard RFC 4648 Base64 with padding, as produced by the OpenSSL example in Google's X.509 documentation? Can this attribute ever use Base64URL or an unpadded representation?

3. Does unauthorized_client with the attribute-condition rejection message guarantee successful full certificate-chain verification and mTLS-to-subject-token binding, or is that processing order undocumented?

4. Is there an officially supported read-only diagnostic or evaluation mechanism that can identify which attribute-condition clause failed without changing the provider or making another live STS exchange?

Please cite official documentation, maintained implementation source, or a confirmed Google engineering statement.

We are not looking for a generic troubleshooting checklist, replacement credentials, a new CA, or a suggestion to remove the attribute condition.

Our objective is to identify the smallest correction that preserves the existing X.509 identity and fingerprint restrictions.

Thank you.