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
>
