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
