Thanks Ayush and Dmitri. Ayush, you're right about storage-credentials: the signal is there, and the real objection to option 2 is that clients aren't reliably checking it. And the point that both failure cases are static properties of the catalog is what settles it for me as well: there is nothing a later request could do differently, so a clear error at load time loses nothing.
So the direction is option 1: keep fail-fast, and document it. Unless there are objections in the next couple of days, I'll open an issue to update the docs, covering the vended-credentials-only and remote-signing cases, what the client sees, and the recommendation to omit the header (or configure storage credentials) for catalogs that cannot vend. On the Iceberg spec: I'll leave it aside for now, given Dmitri's point that the current text already permits refusing, and revisit only if someone hits the ambiguity in practice. Thanks, Youngrae Kim 2026년 9월 19일 (토) 오전 12:05, Dmitri Bourlatchkov <[email protected]>님이 작성: > 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 > > > > > >
