I'm also generally in favor. Thanks, Alex! On Sun, Jan 18, 2026 at 11:58 PM Eduard Tudenhöfner < [email protected]> wrote:
> I'm generally in favor of this idea, so +1 > > 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 >> >
