Hi Dmitri, Agree, I'm also +1 on PR #5731.
Iceberg defines StorageCredential.config as a prefix-scoped string map, and the S3 and GCS FileIO impl overlay it on their base properties. Returning the access properties next to the credentials is consistent with that model. It also fixes a gap: /credentials currently can't return the full client-visible storage access config. Before merging, maybe we should be clear: - You mentioned that in the PR: the endpoint and other properties are omitted when no credentials are present. If the credentials entry is meant to be the complete access config, that rule should hold in every case, including remote signing. If not, the PR should clearly state which cases are excluded. - On the documentation side of the things, we should document how the config is an entry applies relative to its storage prefix. That keeps the single-location behavior well defined today and avoids ambiguity. - Clients overlay the whole selected credential config into their own FileIO properties. So endpoint, region, etc can now overide what the user set client-side. Maybe we should consider this as behavior change. We can do that as follow-ups, but maybe worth to do it. Regards JB On Thu, Oct 8, 2026 at 3:11 PM Dmitri Bourlatchkov <[email protected]> wrote: > Hi All, > > Adam proposed [5731] an interesting way to expand the information Polaris > puts in StorageCredential.config. > > The PR generally LGTM, but since it touches credential vending, I'm sending > this email for community awareness. > > There is also an interesting aspect regarding the interpretation of config > properties with respect to storage URI prefixes. GH has a comment thread > [1] on this. > > Thoughts? > > [1] https://github.com/apache/polaris/pull/5731#discussion_r4207793974 > > [5731] https://github.com/apache/polaris/pull/5731 > > Cheers, > Dmitri. >
