Sounds good. I will open a spec PR that only adds "none" to the X-Iceberg-Access-Delegation enum and leaves the rest of the description as is.
Youngrae Kim 2026년 10월 13일 (화) 오전 7:39, Dmitri Bourlatchkov <[email protected]>님이 작성: > Hi All, > > I agree that we do not need any specific statement on failing requests in > this case. > > Cheers, > Dmitri. > > On Mon, Oct 12, 2026 at 4:12 PM Daniel Weeks <[email protected]> wrote: > >> I think we only need to add #1 above. >> >> For #2, a server may always reject/fail a request. I don't think we need >> to clarify that point. >> >> On Mon, Oct 12, 2026 at 12:46 AM youngrae kim <[email protected]> >> wrote: >> >>> Thanks everyone. Summarizing where the thread landed: >>> >>> 1. Add "none" to X-Iceberg-Access-Delegation, meaning the client does >>> not need delegated access from the catalog (Dan's suggestion, +1 from Yufei >>> and Dmitri). >>> 2. Clarify the header description so that failing the request is >>> explicitly allowed: "The server may choose to supply access via any or none >>> of the requested mechanisms, or fail the request." >>> >>> Unless someone objects, I am happy to open a spec PR with these two >>> changes so the discussion can continue on concrete wording. >>> >>> Youngrae Kim >>> >>> 2026년 10월 8일 (목) 오전 8:03, Dmitri Bourlatchkov <[email protected]>님이 작성: >>> >>>> Hi Alex, Dan, >>>> >>>> Thanks for proposing this change. "None" sounds like a good idea to >>>> me. It is certainly clearer than "local" in the >>>> context of X-Iceberg-Access-Delegation. >>>> >>>> Cheers, >>>> Dmitri. >>>> >>>> On Mon, Oct 5, 2026 at 4:18 PM Daniel Weeks <[email protected]> wrote: >>>> >>>>> Alex, >>>>> >>>>> Rather than 'local', I think I would prefer 'none'. Rather than >>>>> saying what the client is intending to do, express that the client isn't >>>>> asking for or doesn't need credentials/access from the catalog. >>>>> >>>>> At least then, the catalog could skip the generation. >>>>> >>>>> -Dan >>>>> >>>>> On Mon, Oct 5, 2026 at 12:51 AM Alex Dutra <[email protected]> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> How about at least introducing a new enum constant "local" in the >>>>>> X-Iceberg-Access-Delegation header? If the intent of that header was >>>>>> to express capabilities, this new constant would convey the notion of >>>>>> "I can work with my own credentials" more firmly than letting the >>>>>> server second-guess. E.g.: "local,remote-signing,vended-credentials" >>>>>> would mean the client can either work with vended credentials, remote >>>>>> signing, or its own credentials. >>>>>> >>>>>> Thanks, >>>>>> Alex >>>>>> >>>>>> On Tue, Sep 29, 2026 at 4:08 AM youngrae kim <[email protected]> >>>>>> wrote: >>>>>> > >>>>>> > Thanks Dan and Alex. >>>>>> > >>>>>> > Dan, that background is helpful, and I take the point: with >>>>>> storage-credentials and remote-signing-config >>>>>> > the catalog can state what it provides, so the spec does not need >>>>>> to mandate a failure when the requested >>>>>> > mechanisms cannot be provided. Polaris will keep its current >>>>>> behavior as an implementation choice, >>>>>> > documented as such, and I will report that outcome on the Polaris >>>>>> list. >>>>>> > >>>>>> > The one thing I would still find useful is Alex's narrower point: a >>>>>> sentence saying whether the >>>>>> > header is a capability statement or a requirement, and what an >>>>>> absent header means. >>>>>> > That does not constrain what the catalog decides to provide; it >>>>>> only tells servers and clients how to read the header. >>>>>> > If there is appetite for that I am happy to draft it; otherwise I >>>>>> am fine leaving the wording as is and >>>>>> > letting the catalog-driven model evolve with the File type work. >>>>>> > >>>>>> > Thanks, >>>>>> > Youngrae Kim >>>>>> > >>>>>> > 2026년 9월 29일 (화) 오전 6:28, Daniel Weeks <[email protected]>님이 작성: >>>>>> >> >>>>>> >> I'm not sure I agree with the model of a client bringing its own >>>>>> credentials if the catalog is also responsible for controlling access >>>>>> (can't really stop people from using that model, but as I said above, it >>>>>> feels like an anti-pattern). >>>>>> >> >>>>>> >> The current wording in the spec was intentionally loose so that >>>>>> the catalog can make decisions without being forced into specific >>>>>> security/access decisions. I still don't think that updating the wording >>>>>> would be flexible enough. >>>>>> >> >>>>>> >> I'm not sure what all catalogs do, but I can say that it's always >>>>>> safe for the catalog to return credentials/remote config even if the >>>>>> client >>>>>> was externally configured to use its own. The current reference >>>>>> implementation bypasses that, I believe, but conceptually a client does >>>>>> not >>>>>> need to use the mechanism provided by the catalog. This again feels like >>>>>> a >>>>>> bit of an anti-pattern: if there's a reason to bring sidecar credentials, >>>>>> it implies a gap in the delegation model that we should be looking into >>>>>> addressing. >>>>>> >> >>>>>> >> Dan >>>>>> >> >>>>>> >> On Mon, Sep 28, 2026 at 10:00 AM Alex Dutra <[email protected]> >>>>>> wrote: >>>>>> >>> >>>>>> >>> Hi all, >>>>>> >>> >>>>>> >>> > The delegation header intended to allow the client to >>>>>> communicate its capabilities, but we've aligned more clearly on catalogs >>>>>> controlling access as opposed to clients defining behavior. >>>>>> >>> >>>>>> >>> IMO, this header isn't ideal for communicating client >>>>>> capabilities. >>>>>> >>> Notably, it fails to represent a key capability: that of using the >>>>>> >>> client's own storage credentials to bypass access delegation >>>>>> entirely. >>>>>> >>> Right now, the only way to imply this capability is by omitting >>>>>> the >>>>>> >>> header altogether, which introduces ambiguity into the >>>>>> specification. >>>>>> >>> Put simply, a client cannot explicitly communicate e.g.: "I can >>>>>> >>> function either without access delegation or using vended >>>>>> credentials, >>>>>> >>> but I do not support remote signing." >>>>>> >>> >>>>>> >>> Therefore, Apache Polaris today treats this header as an explicit >>>>>> >>> requirement rather than just a capability statement. IOW, it >>>>>> treats >>>>>> >>> the header presence as an indication that the client cannot >>>>>> function >>>>>> >>> without access delegation, and that at least one specified mode >>>>>> must >>>>>> >>> be satisfied. >>>>>> >>> >>>>>> >>> I would be interested to hear how other catalog implementations >>>>>> are >>>>>> >>> approaching this. >>>>>> >>> >>>>>> >>> In any case, I still think that a minor spec clarification would >>>>>> be >>>>>> >>> welcome, if for nothing else, at least to lift the ambiguity >>>>>> around >>>>>> >>> what it means when the header is absent and clarify whether the >>>>>> header >>>>>> >>> is a capability statement, or a requirement. >>>>>> >>> >>>>>> >>> Thanks, >>>>>> >>> Alex >>>>>> >>> >>>>>> >>> >>>>>> >>> On Mon, Sep 28, 2026 at 5:03 PM Daniel Weeks <[email protected]> >>>>>> wrote: >>>>>> >>> > >>>>>> >>> > Youngrae, >>>>>> >>> > >>>>>> >>> > I think the issue with #2 above is that it's a bit of an >>>>>> anti-pattern for the client to concurrently own access. Either the >>>>>> catalog >>>>>> should be the authority on access or it shouldn't. Security around the >>>>>> physical data shouldn't really be a negotiation between the client and >>>>>> the >>>>>> server. If the catalog is delegating access to the data, it should be >>>>>> the >>>>>> sole source of truth. >>>>>> >>> > >>>>>> >>> > It feels like we're trying to make this a negotiation between >>>>>> the catalog and client, but the catalog should be responsible for access >>>>>> delegation in a secure environment. >>>>>> >>> > >>>>>> >>> > The background on this header is important: The original >>>>>> access control mechanism was remote signing only, which was not >>>>>> originally >>>>>> part of the REST protocol (it was separate and S3 specific). We later >>>>>> introduced vended credentials, but only through the config payload. >>>>>> Since >>>>>> then, a lot has changed: we introduced the Storage Credentials and now >>>>>> the >>>>>> Remote Signing Config, which means that we're in a much better position >>>>>> for >>>>>> the catalog to clearly indicate which mechanism the client should use. >>>>>> The >>>>>> mechanisms are more standardized, and clients should be able to report if >>>>>> they cannot support what the catalog has provided. >>>>>> >>> > >>>>>> >>> > While there may be some residual value in the client signaling >>>>>> its capabilities, I'm not convinced we need to change the wording in the >>>>>> spec and we need to improve the other mechanisms as we evolve to support >>>>>> new functionality like File type, which may mix different modes of >>>>>> access. >>>>>> >>> > >>>>>> >>> > The behavior you describe in Polaris is perfectly fine as an >>>>>> implementation choice, but I don't think catalogs SHOULD fail if they >>>>>> cannot provide any requested mechanism. The catalog can provide an >>>>>> alternative (e.g. you requested signing, but I'm only providing >>>>>> credentials), which the client can error on if it does not understand. >>>>>> Alternatively, the catalog could reject all requested forms and return >>>>>> only >>>>>> the metadata, effectively signaling that the client can only see the >>>>>> metadata, but has no access to the physical data. >>>>>> >>> > >>>>>> >>> > -Dan >>>>>> >>> > >>>>>> >>> > >>>>>> >>> > On Fri, Sep 25, 2026 at 8:18 PM youngrae kim < >>>>>> [email protected]> wrote: >>>>>> >>> >> >>>>>> >>> >> Thanks Alex, Yufei and Dan. >>>>>> >>> >> >>>>>> >>> >> Dan, I think the catalog-controlled direction and Alex's >>>>>> wording are compatible, and it may help to separate the two roles the >>>>>> header plays today: >>>>>> >>> >> >>>>>> >>> >> 1. Which mechanism to use. >>>>>> >>> >> That is already the catalog's decision in Polaris: the server >>>>>> picks among the mechanisms >>>>>> >>> >> it supports for that catalog and storage, and the header only >>>>>> tells it which ones the client can consume. >>>>>> >>> >> Nothing in the proposed sentence changes that. >>>>>> >>> >> >>>>>> >>> >> 2. Whether the client can access the data at all without >>>>>> delegation. Today the header is the >>>>>> >>> >> only signal a client has for "I have no storage credentials of >>>>>> my own". >>>>>> >>> >> If the catalog cannot provide any mechanism the client can >>>>>> consume, the request cannot succeed in any >>>>>> >>> >> useful sense, and the question is only where the failure >>>>>> surfaces: at load time with a >>>>>> >>> >> message naming the cause, or at the first data access with a >>>>>> storage error. >>>>>> >>> >> >>>>>> >>> >> The proposed SHOULD covers exactly the empty-intersection case >>>>>> in (2); a server that knows its >>>>>> >>> >> clients carry their own credentials can still return the >>>>>> table, which is why SHOULD rather than MUST seems right. >>>>>> >>> >> >>>>>> >>> >> If the longer-term direction is to rely less on the header, I >>>>>> would be interested in how a >>>>>> >>> >> catalog-driven model would express (2), for example the client >>>>>> learning from /v1/config which >>>>>> >>> >> mechanisms the catalog offers, so it can decide before loading >>>>>> a table. That seems like a >>>>>> >>> >> larger change than the clarification this thread started with, >>>>>> so I would suggest landing the >>>>>> >>> >> one-sentence clarification for the current header and taking >>>>>> the catalog-driven model as a >>>>>> >>> >> separate discussion, unless you see a conflict between the two. >>>>>> >>> >> >>>>>> >>> >> Thanks, >>>>>> >>> >> Youngrae Kim >>>>>> >>> >> >>>>>> >>> >> 2026년 9월 26일 (토) 오전 8:52, Daniel Weeks <[email protected]>님이 >>>>>> 작성: >>>>>> >>> >>> >>>>>> >>> >>> I'm not convinced that we're thinking about this the right >>>>>> way. >>>>>> >>> >>> >>>>>> >>> >>> The delegation header intended to allow the client to >>>>>> communicate its capabilities, but we've aligned more clearly on catalogs >>>>>> controlling access as opposed to clients defining behavior. >>>>>> >>> >>> >>>>>> >>> >>> If we leaned more into that direction, then access would be >>>>>> determined by the catalog based on the availability of vented credentials >>>>>> or the new remote signing configuration. >>>>>> >>> >>> >>>>>> >>> >>> There may be an opportunity here to rely less on the header >>>>>> and give responsibility back on th e catalog to determine the access >>>>>> model. >>>>>> >>> >>> >>>>>> >>> >>> -Dan >>>>>> >>> >>> >>>>>> >>> >>> On Fri, Sep 25, 2026, 4:39 PM Yufei Gu <[email protected]> >>>>>> wrote: >>>>>> >>> >>>> >>>>>> >>> >>>> I tend to agree with Alex and Youngrae. A fail-fast approach >>>>>> provides a clear behavioral contract between the server and clients, >>>>>> while >>>>>> the current spec introduces ambiguity. >>>>>> >>> >>>> >>>>>> >>> >>>> I am not sure if this ambiguity was intentional. Please >>>>>> chime in if you can provide more context; otherwise, I suggest we update >>>>>> the spec to eliminate it. >>>>>> >>> >>>> >>>>>> >>> >>>> Yufei >>>>>> >>> >>>> >>>>>> >>> >>>> >>>>>> >>> >>>> On Thu, Sep 24, 2026 at 10:12 AM Alex Dutra < >>>>>> [email protected]> wrote: >>>>>> >>> >>>>> >>>>>> >>> >>>>> Hi Youngrae, >>>>>> >>> >>>>> >>>>>> >>> >>>>> Thanks for starting this thread! >>>>>> >>> >>>>> >>>>>> >>> >>>>> I believe the phrase "via any or none of the requested >>>>>> mechanisms" >>>>>> >>> >>>>> requires clarification. >>>>>> >>> >>>>> >>>>>> >>> >>>>> If a client requests modes A and B, a server returning only >>>>>> mode B is >>>>>> >>> >>>>> perfectly acceptable. However, returning a 200 OK response >>>>>> with >>>>>> >>> >>>>> neither mode A nor B represents an ambiguous outcome. >>>>>> >>> >>>>> >>>>>> >>> >>>>> The current wording likely assumes the client could >>>>>> theoretically >>>>>> >>> >>>>> proceed using its own fallback storage credentials. In >>>>>> practice, >>>>>> >>> >>>>> operators configure clients intentionally; requesting access >>>>>> >>> >>>>> delegation "just in case" is unrealistic. A fail-fast error >>>>>> is a >>>>>> >>> >>>>> better outcome, as opposed to letting the client proceed, >>>>>> only to see >>>>>> >>> >>>>> it fail later on. >>>>>> >>> >>>>> >>>>>> >>> >>>>> I propose updating the specification to mandate an error >>>>>> response when >>>>>> >>> >>>>> no requested mechanism is available, while also clarifying >>>>>> whether >>>>>> >>> >>>>> providing multiple delegation modes is supported: >>>>>> >>> >>>>> >>>>>> >>> >>>>> "The server MAY supply access via any or all of the >>>>>> requested >>>>>> >>> >>>>> mechanisms. If none of the requested mechanisms is >>>>>> available, the >>>>>> >>> >>>>> server SHOULD return an HTTP 400 (Bad Request) response." >>>>>> >>> >>>>> >>>>>> >>> >>>>> Thanks, >>>>>> >>> >>>>> Alex >>>>>> >>> >>>>> >>>>>> >>> >>>>> On Wed, Sep 23, 2026 at 11:14 AM youngrae kim < >>>>>> [email protected]> wrote: >>>>>> >>> >>>>> > >>>>>> >>> >>>>> > Hi all, >>>>>> >>> >>>>> > The REST catalog spec describes >>>>>> X-Iceberg-Access-Delegation as an "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." [1] >>>>>> >>> >>>>> > >>>>>> >>> >>>>> > In Apache Polaris we recently discussed what a server >>>>>> should do when the header is present but it can satisfy none of the >>>>>> requested mechanisms, for example vended-credentials against an >>>>>> S3-compatible store without STS, or remote-signing on a server that does >>>>>> not implement it [2]. >>>>>> >>> >>>>> > >>>>>> >>> >>>>> > Polaris fails such requests with HTTP 400 and a message >>>>>> naming the reason, because in these cases the inability is a static >>>>>> property of the catalog and a 200 without credentials would only move the >>>>>> failure to the first data access. >>>>>> >>> >>>>> > >>>>>> >>> >>>>> > Two readings of "any or none" came up and the text does >>>>>> not settle which is intended: >>>>>> >>> >>>>> > (a) "none" means the server returns 200 with the table >>>>>> and no delegated access, and the client detects this from the response: >>>>>> an >>>>>> empty storage-credentials (and, we understand, an empty >>>>>> remote-signing-config once that field lands in 1.12), falling back to the >>>>>> config map for older servers [3]. >>>>>> >>> >>>>> > >>>>>> >>> >>>>> > (b) "none" also permits the server to reject the >>>>>> request when it cannot provide any of the requested mechanisms. >>>>>> >>> >>>>> > >>>>>> >>> >>>>> > Questions for the community: >>>>>> >>> >>>>> > 1. Is rejecting the request a permitted server choice >>>>>> under the current text, or is (a) the only intended behavior? >>>>>> >>> >>>>> > 2. If rejection is permitted, is there a preferred >>>>>> status code and error type, so clients can distinguish "delegation >>>>>> unavailable" from other 400s? >>>>>> >>> >>>>> > 3. If (a) is the intended behavior, should the spec >>>>>> state explicitly that the absence of credentials in both >>>>>> storage-credentials and config (and of remote-signing-config) is the >>>>>> signal >>>>>> that no delegation was applied? >>>>>> >>> >>>>> > >>>>>> >>> >>>>> > I'm happy to draft a clarification to the parameter >>>>>> description once there is agreement. >>>>>> >>> >>>>> > >>>>>> >>> >>>>> > [1] >>>>>> https://github.com/apache/iceberg/blob/778d103c0fa802be5e85e4cb2e4e4b4bcd8ac891/open-api/rest-catalog-open-api.yaml#L2151-L2161 >>>>>> >>> >>>>> > [2] >>>>>> https://lists.apache.org/thread/9oyv4v0vk3t8stv9832npl8t0yyp4j8r >>>>>> >>> >>>>> > [3] >>>>>> https://github.com/apache/iceberg/blob/778d103c0fa802be5e85e4cb2e4e4b4bcd8ac891/open-api/rest-catalog-open-api.yaml#L4246-L4249 >>>>>> >>> >>>>> > >>>>>> >>> >>>>> > Thanks, >>>>>> >>> >>>>> > Youngrae Kim >>>>>> >>>>>
