Hey Sung, Thanks for starting this thread, I wanted to bump it because I'd like to wait for the file implementation before settling on this.
One of the primary uses of this endpoint is for File type access, but we haven't yet discussed the overhead of the authorization cost. I know auth isn't part of the REST spec, but we should be considerate of the challenges. In the simple case, we can likely authorize file access that lives under the table, but for scenarios where files reference shared storage, we need to determine whether a request can be signed or not. This might require additional information (like the file containing the reference and the column name from the source table) in order for the server to validate access. This might require changing the request design. Originally, we (or I) assumed that the properties would be the same for all paths, but if we need to add contextual information like above, then we would need properties at the request level. -Dan On Mon, Oct 26, 2026 at 2:32 PM Sung Yun <[email protected]> wrote: > Hi folks, > > I'd like to start a discussion on adding a batch signing endpoint to the > REST catalog spec. This follows the earlier threads on File-level access > delegation[1], and Access Delegation for Iceberg FILE type in the REST > Catalog[2]. > > PR: https://github.com/apache/iceberg/pull/18254 > Design doc: https://s.apache.org/irc-batch-signing > > Today a client signs one object request per call to signRequest. For table > data this is bounded by the number of data and delete files touched by a > scan. However, with the recently adopted FILE type[3], where each row may > reference an external object, the number of signatures scales with rows. > > The PR proposes a new batch signing endpoint to support that scale. > > Reviews on the PR or replies here are both welcome. > > Thank you, > Sung > > [1] https://lists.apache.org/thread.html/4fxylxkfj0ngp0ksfysgkhn8s6o9x4n5 > [2] https://lists.apache.org/thread.html/s283f6obyqf6c14bn37sw7vtf9y1c9mj > [3] https://github.com/apache/iceberg/pull/17918 >
