Thank you for starting this thread Alex ! I think it's a nice idea ! especially since we wanna optimize these endpoints for extremely huge tables, for example tables with millions / billions of files, since now for each file (data / metadata file) we need to come to the catalog and get the equivalent signed url based on the operation we wanna do.
The way we are thinking of this is Apache Polaris community is we send back the RBAC info (i.e grants / locations etc) as part of loadTable (signed by a key catalog maintains) which when sent to catalog back from the client would help catalog avoiding the grants etc lookup etc and catalog can simply use this since its signed by catalog. Note:From the spec we just expect the catalog to send back the properties sent as part of loadTable back to the POST of the sign endpoint, rest all can be catalog specific handling. I personally think this is way cleaner than embedding this info in the signer url and the catalog supporting multiple custom endpoints for achieving this functionality, having this in the spec helps the catalog ! I am supportive of it in general. Best, Prashant Singh On Fri, Jan 16, 2026 at 6:29 AM Alexandre Dutra <[email protected]> wrote: > Hi all, > > We also agreed last Wednesday on the fact that the signer endpoint > lacks a standard way to pass catalog-specific information, especially > RBAC data. > > The status quo today is that open-source catalogs are generally > leveraging the signer URI to pass the extra information, since that's > the only possible way today. We agreed this is suboptimal, and a > proper request body parameter would be better. > > It turns out that the current signer spec already has support for > arbitrary properties in the request body [1]. Unfortunately, in > Iceberg OSS there is no way for the server to communicate those > properties to the signer client – these are always empty (see Java [2] > and Python [3] impls). > > We would need to introduce a new table configuration property that > could be a JSON-encoded bag of properties; if this property is present > in the loadTable response, then the signer client would be *required* > to include it in *every* request to the signer endpoint. > > What are your thoughts on this? Moving forward on this topic would be > beneficial to Apache Polaris ongoing effort to support remote signing. > > Thanks, > Alex > > > [1]: > https://github.com/apache/iceberg/blob/55bfc7e82d03b5038bc5d0da852bd16615486926/aws/src/main/resources/s3-signer-open-api.yaml#L120-L123 > [2]: > https://github.com/apache/iceberg/blob/08d9ee02092f6fd59f8103c1c4de1a7f1e9fa1fe/aws/src/main/java/org/apache/iceberg/aws/s3/signer/S3V4RestSignerClient.java#L90-L93 > [3]: > https://github.com/apache/iceberg-python/blob/155af262724a42f18a08450c43a021791fb29880/pyiceberg/io/fsspec.py#L129-L134 >
