Hi all, It was really nice to go through the proposal in the Iceberg catalog community sync (7/30)!
As next steps, I was expecting the doc to be updated according to the community feedback, specifically: - Using loadTable API to return the evaluated policies result. - Aligning on Iceberg expressions as the path forward for row filters, with UDFs to handle dialect-specific logic. I noticed the doc hasn’t yet been updated with this feedback. I completely understand the authors might be busy, so I’d like to offer help to push this forward. We’ve discussed this topic in depth across several syncs, so perhaps we could even move ahead by opening a spec PR to IRC and continue iterating there. I’m happy to help put that out if it would help keep things moving. Downstream projects such as Apache Polaris are eagerly waiting for this feature, so it would be great to make progress here! Thanks, Prashant Singh On Wed, Jul 23, 2025 at 7:45 AM Robert Stupp <sn...@snazy.de> wrote: > Hi all, > > Following up on the “Iceberg REST FGAC proposal” discussion [1], we > are happy to share the more detailed proposal [2] to extend the Apache > Iceberg REST specification to include a new API for retrieving > fine-grained access control (FGAC) "protection instructions" > (row-level filters and column transformations) from an Iceberg REST > Catalog. > > The aim is to standardize how query engines obtain these instructions > based on user identity, simplifying data protection enforcement. > > The proposal focuses solely on the new Iceberg REST API endpoint to > retrieve protection instructions, intentionally omitting catalog > specific policy management APIs. > > Having a truly interoperable way to represent the protection > instructions for both row filters and column transformations is a huge > benefit. This is why the support for Iceberg expressions is marked as > mandatory in the proposal. We think that it is a fair option to allow > people to use SQL expressions, not required by the proposal, to > satisfy their needs, assuming they are okay to accept that not all > catalogs or engines support SQL expressions or not all SQL > conformance/dialects. > > Thanks to all of those who have helped review & contribute - JB > Onofre, Prashant Singh, Russell Spitzer, Roy Hansson, & Kevin Liu. We > are excited about the community support! > > Cheers, > Robert, Laurent, Alex, Dmitri > > [1] https://lists.apache.org/thread/nfw1t0glfdfj1hwmzzzzwwyrfnq44yr5 > [2] > https://docs.google.com/document/d/108Y0E8XsZi91x-UY0_aHLEbmXDNmxmS5BnDjunEKvTM >
