+1 for my end too. On Tue, Jan 20, 2026 at 9:09 AM Ryan Blue <[email protected]> wrote:
> 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 >>> >>
