Hi All, I agree with option 1.
The basic question is whether the client should use local credentials or get vended credentials from Polaris. I do not think it is a runtime choice. I believe it is a fundamental design decision that administrators should resolve at deployment time. Consequently, the client should either delegate access controls to Polaris via X-Iceberg-Access-Delegation or not use that header at all. >From another angle, if the client already has access credentials, what could be the rationale for also requesting different access channels via X-Iceberg-Access-Delegation? I do not see any :) With that in mind, I think Polaris can interpret the presence of X-Iceberg-Access-Delegation as a strong request for server-controlled access methods (request signing or cred. vending). If the server cannot provide any, it is effectively a deployment / configuration mistake, so a clear error response is quite appropriate from my POV. General non-vending Polaris configuration is considered deprecated per earlier discussion [1]. The only case when Polaris cannot vend credentials is when the Storage System does not support it. Re: Iceberg spec discussion, I'm not sure it is worth the trouble. The IRC spec clearly opted for the most lenient interpretation of X-Iceberg-Access-Delegation that does not impose any strong protocol-level requirements on either the client or the server. I do not think it would be wise for the IRC spec to venture into deployment-level recommendations because it defines a protocol, not an end-to-end system. I think the current IRC spec allows the behaviour proposed by option 1 in Polaris. This is just my personal opinion, feel free to open an Iceberg discussion on this if you prefer. [1] https://lists.apache.org/thread/1trcnbm04zzqztpxkzrzs1pvrlyd49bg Cheers, Dmitri. On Fri, Sep 18, 2026 at 7:40 AM Ayush Saxena <[email protected]> wrote: > 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 > > >
