> > 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 <https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml#L3468-L3480>) 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 <https://docs.google.com/document/d/1lySd_5hMZNtISLKsOvAq7xiNzdXU6TAoHF_yrOXWQvM/edit?tab=t.0#heading=h.hs6r9d26w1y2> 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 >
