Hi Youngrae, +1 to option 1, with one correction to the premise.
The spec does have a signal for "delegation not applied": LoadTableResult carries storage-credentials, and clients are obliged to look at it — "Clients must first check whether the respective credentials exist in the storage-credentials field before checking the config for credentials" [1]. An empty storage-credentials on a 200 is observable. The practical objection to option 2 is that "must check" isn't "does check", not that the information is missing. What decides it for me is that in Polaris both failure cases are static properties of the catalog: stsUnavailable is configuration and remote signing is unimplemented, so neither will start working on a later request or for a different table. The usual case for returning 200 without delegation is that the server might satisfy it some other time — that doesn't apply here, so failing at load with a message naming the reason is strictly more diagnosable and nothing is lost. Raising the ambiguity upstream sounds worthwhile either way — "any or none" doesn't say whether refusing the request is a permitted choice, and that's the real gap. -Ayush [1] https://github.com/apache/iceberg/blob/778d103c0fa802be5e85e4cb2e4e4b4bcd8ac891/open-api/rest-catalog-open-api.yaml#L4246-L4249 On 2026/09/18 08:44:49 김영래 wrote: > 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 >
