Hi all,
This came out of the review of PR #5473 (merged), where Dmitri
suggested moving the spec-alignment question to the list. Short version:
today Polaris fails a request whose X-Iceberg-Access-Delegation header
cannot be satisfied, while the Iceberg REST spec reads as if the server may
instead return the table without delegated access. I'd like to agree on the
intended behavior and document it.
Current behavior (main, after #5473):
- "vended-credentials" against a catalog that cannot vend credentials (e.g.
S3 with stsUnavailable=true) fails with 400 "Credential vending was
requested ... but no credentials are available".
- Anything that resolves to remote signing (not implemented) fails with 400
"This catalog cannot vend credentials or sign requests; request without
X-Iceberg-Access-Delegation and configure storage credentials on the
client". This covers "remote-signing" alone
and "vended-credentials,remote-signing" when vending is not possible.
What the spec says (iceberg-rest-catalog-open-api.yaml, parameter
X-Iceberg-Access-Delegation):
"Optional signal to the server that the client supports
delegated access via a comma-separated list of access mechanisms. The
server may choose to supply access via any or none of the requested
mechanisms."
Arguments raised in the PR review:
- For fail-fast (current): a client that asks for delegation usually has no
storage credentials of its own, so a 200 without credentials only moves the
failure to the first data access, where it is much harder to diagnose. It
is also consistent with how "vended-credentials" alone has always behaved.
- For following the spec literally: the header is a hint, and clients that
do have their own storage credentials (instance profile, environment
variables) but send the header as a shared setting would simply work.
Options:
1. Keep fail-fast and document it explicitly. The docs currently only say
to omit the header for stsUnavailable catalogs.
2. Follow the spec literally and return the table without delegated access.
The spec has no field to signal "delegation not applied", so clients would
only find out at data access time.
3. Make it configurable per realm or catalog (feature flag, default
fail-fast) for deployments that know their clients carry storage
credentials.
I lean towards option 1 unless someone has a concrete client that depends
on option 2. If there is interest, I can also raise the ambiguity on the
Iceberg side, since the spec text leaves the choice to the server.
Context: issue #5472, PR #5473 (see the CHANGELOG review thread), and the
earlier threads "[DISCUSS] S3 Credential vending without STS" (July 2025)
and "[DISCUSS] S3 Remote Signing" (August 2025).
Thanks,
Youngrae Kim
