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
