+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 >
