Thank you all! I think we have an agreement here. I'm happy to start working on the PR, but I recall that a VOTE thread is necessary for this type of modification. Should we initiate the vote now, or wait until the PR is ready for merging (and vote on the PR contents)?
Thanks, Alex On Wed, Jan 21, 2026 at 1:08 AM Yufei Gu <[email protected]> wrote: > > +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
