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
