Hi Yun, > This means there is currently some overlap between the config and > storage-credentials fields. Is my understanding correct?
That is my understanding too, and this will be the case until we consider that we can drop support for credentials in config for old clients. Thanks, Alex On Sat, Feb 28, 2026 at 12:27 AM yun zou <[email protected]> wrote: > > Hi Eduard and Alexandre, > > Thank you both for chiming in on this — I really appreciate the clarification. > > If I understand correctly, the storage-credentials field contains only > credential-related configurations and was introduced mainly for the > following reasons: > > There was a lack of clear documentation around credential-related > entries within the existing config field in the LoadTable response. > > It is used by the credential endpoint to support credential refresh. > > As Alexandre mentioned, all credential configurations are still > included in the config field of LoadTableResult for backward > compatibility. This means there is currently some overlap between the > config and storage-credentials fields. Is my understanding correct? > > Best regards, > Yun > > On Fri, Feb 27, 2026 at 5:40 AM Alexandre Dutra <[email protected]> wrote: > > > > Hi Yun, > > > > In addition to what Eduard said, I would like to stress this sentence > > from the design doc: "In order to maintain backward compatibility with > > older clients, credentials still need to be passed as properties via > > the config field for LoadTableResult and LoadViewResult." > > > > IOW, servers must send credentials in both places: config and > > storage-credentials, to stay compatible with older clients; this is > > what Apache Polaris does [1]. > > > > Thanks, > > Alex > > > > [1]: > > https://github.com/apache/polaris/blob/579b271b8c41cd26339bccfd771c1a591ad27039/runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/IcebergCatalogHandler.java#L856-L861 > > > > On Fri, Feb 27, 2026 at 7:52 AM Eduard Tudenhöfner > > <[email protected]> wrote: > > >> > > >> 1) What is the intended boundary between storage-credentials and > > >> config in LoadTableResult? > > > > > > > > > We used to send back all sorts of configurations in the config of a > > > LoadTableResponse (examples are shown here) but those configurations > > > weren't well documented for different storage providers. Later we > > > introduced the concept of storage credentials which are sent back in the > > > storage-credentials field. Those will only contain storage credentials, > > > such as access-key-id / secret-access-key / session-token / > > > session-token-expires-at-ms in the case of S3 and no other > > > configurations. Also the storage-credentials field takes precedence over > > > whatever is sent in the config. > > > > > > > > >> 2) What is the motivation behind this design choice? > > > > > > > > > Storage credentials offer more flexibility because they let you use > > > different credentials for different storage prefixes. Additionally, those > > > credentials are being refreshed automatically, which is not the case with > > > the vended credentials that are sent as part of the config. > > > > > > Here's the original design that outlines why we standardized credentials > > > into the storage-credentials field. > > > > > > > > > On Thu, Feb 26, 2026 at 9:22 PM yun zou <[email protected]> > > > wrote: > > >> > > >> Hi All, > > >> > > >> I’m looking into the credential vending support for Iceberg and got a > > >> bit confused about the config and storage-credentials fields in > > >> LoadTableResult. > > >> > > >> From what I understand: > > >> > > >> storage-credentials can contain configurations that are not strictly > > >> credential-related, such as client.region. > > >> > > >> The description for "config" states that it is "table-specific > > >> configuration for the table's resources, including its HTTP client and > > >> FileIO. For example, config may contain a specific FileIO > > >> implementation class for the table depending on its underlying > > >> storage." > > >> > > >> In our current implementation, we kind of merge both fields when > > >> initializing the client, which makes me wonder: > > >> > > >> 1) What is the intended boundary between storage-credentials and > > >> config in LoadTableResult? > > >> > > >> 2) What is the motivation behind this design choice? > > >> > > >> Thanks in advance for clarifying! > > >> > > >> Best regards, > > >> Yun
