Hi Yun, The proposal looks reasonable to me in general after a quick review of the doc.
I have one concern, though, which may be a whole can of worms, I'm afraid :) How are clients supposed to know the meaning of credential properties in the "config" section? The doc proposes to define it as a generic property bag. The example appears to use properties that Iceberg (java?) clients might use in a similar situation. However, the Generic Tables API is not related to Iceberg in any way (AFAIK). Plus, I do not think these properties are well-defined even in Iceberg specifications. WDYT? Thanks, Dmitri. On Fri, Feb 6, 2026 at 1:29 PM yun zou <[email protected]> wrote: > Hi All, > > Generic Tables have been available since Polaris 1.0.0 and have seen > growing interest from an increasing number of customers. > > However, the current Generic Table capability has some limitations. One > key gap is the lack of credential vending support. Without credential > vending, query engines must access tables using long-lived, static cloud > credentials configured directly in the engine runtime, which limits both > usability and security. > > To address this, we propose adding credential vending support for Generic > Tables. This enhancement would allow a Polaris catalog to dynamically vend > short-lived, scoped storage credentials to query engines at runtime when > accessing Generic Tables. > > The goals of this proposal are to: > > 1. > > Enable credential vending support for Generic Tables in Polaris > 2. > > Deliver an end-to-end experience for currently supported table > formats, including Delta, Hudi, and Lance > 3. > > Maintain consistency with the existing Iceberg credential vending model > > Please find the attached short design document with additional details. We > would appreciate your review and valuable feedback. > > link to google doc: > https://docs.google.com/document/d/1QzTx4tcS23_mF-gc77GbTqtwuRHY5f_Aa_6E4VSKFU4/edit?tab=t.0#heading=h.rpqtaz73xt4v > > Best Regards, > > Yun >
