Thanks Yufei. Agreed that the spec text is ambiguous and worth clarifying upstream. I'll focus on the Polaris documentation first; if nobody else picks up the Iceberg-side question, I can raise it on dev@iceberg afterwards and link back to this thread.
For the documentation, I'll open the Polaris issue as planned: the vended-credentials page and the S3 stsUnavailable section will describe what a client sees when delegation cannot be satisfied (HTTP 400 and the two messages), and recommend omitting the header, or configuring storage credentials on the client, for catalogs that cannot vend. I'll post the link to the issue here once it is up. Thanks, Youngrae Kim 2026년 9월 22일 (화) 오전 2:59, Yufei Gu <[email protected]>님이 작성: > I support keeping fail-fast in Polaris and documenting it. > > I’d still suggest a discussion in the Iceberg community. The spec > < > https://github.com/apache/iceberg/blob/778d103c0fa802be5e85e4cb2e4e4b4bcd8ac891/open-api/rest-catalog-open-api.yaml#L2151-L2161 > > > says the server may provide “any or none” of the requested access > mechanisms, but it’s unclear whether that includes rejecting the request. > Clarifying this would help clients work consistently across catalogs. > > This can happen alongside the Polaris documentation update. > Yufei > > > On Fri, Sep 18, 2026 at 5:01 PM youngrae kim <[email protected]> > wrote: > > > 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 > > > > > > > > > > > > > > >
