Hi all, The PR is up for review:
https://github.com/apache/iceberg/pull/15112 Thanks, Alex On Wed, Jan 21, 2026 at 6:49 PM Ryan Blue <[email protected]> wrote: > > A VOTE for REST spec updates usually happens after the changes are available > to review. > > On Wed, Jan 21, 2026 at 9:39 AM Alexandre Dutra <[email protected]> wrote: >> >> 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
