+1 from me. Promoting the signer endpoint to the table level makes it more consistent with other table scoped APIs, and it cleanly provides the catalog(warehouse), namespace and table context without relying on provider specific properties.
Yufei On Tue, Jan 20, 2026 at 12:08 PM Christian Thiel <[email protected]> wrote: > +1 from me too, thanks Alex! > I tested returning the new Endpoint as the `s3.signer.endpoint` config of > a LoadTableResult against all Iceberg Releases from 1.6.1 with Spark as > well as pyiceberg 0.9 and 0.10 without problems. As long as the behaviour > of the Endpoint stays the same for S3, I don't see any issues. > > On Tue, 20 Jan 2026 at 18:43, Jean-Baptiste Onofré <[email protected]> > wrote: > >> +1 >> >> Regards >> JB >> >> On Fri, Jan 16, 2026 at 3:29 PM Alexandre Dutra <[email protected]> >> wrote: >> >>> Hi all, >>> >>> We discussed remote signing last Wednesday during the catalog sync >>> meeting and we all agreed that the default signing endpoint [1] is too >>> rigid. It lacks information about the table and namespace, but is also >>> unaware of catalogs/warehouses, which can be challenging when the same >>> signer client has to access multiple catalogs. >>> >>> One of the ideas that emerged was to promote the signer endpoint to >>> the "top-level" spec, under the table path. In short, it would become >>> something like this: >>> >>> /v1/{prefix}/namespaces/{namespace}/tables/{table}/sign >>> >>> Promoting the endpoint makes it more aligned with similar ones, like >>> the table credentials endpoint. It also solves the problem of passing >>> the namespace, table and warehouse identifiers to the server. >>> >>> The endpoint would become provider-agnostic though. The current >>> endpoint structure appears to be sufficiently generic, showing no >>> S3-specific quirks. For example, implementing Azure support using SAS >>> tokens seems feasible at first glance without any apparent obstacles >>> (that I could think of). But there might be implications that I'm not >>> immediately seeing. >>> >>> Of course, we would need to migrate the existing table properties to >>> more neutral names, e.g.: >>> >>> s3.signer.uri -> signer.uri >>> s3.signer.endpoint -> signer.endpoint >>> >>> What are your thoughts on this idea? >>> >>> Thanks, >>> Alex >>> >>> [1]: >>> https://github.com/apache/iceberg/blob/55bfc7e82d03b5038bc5d0da852bd16615486926/aws/src/main/resources/s3-signer-open-api.yaml#L61 >>> >>
