I think this is a really interesting approach as we've talked about in a few community syncs as well as in some other chats. If I understand the proposal correctly, we are essentially formalizing a way to return the FGAC "protection expressions" from the catalog to a trusted engine for execution.
The only aspects I'm a little more nervous about are allowing dialects into the api (Sql or Substrait) .. I think the UDFs being worked on can probably handle that sort of complexity when it is required and we can stick to Iceberg expressions and transforms (which could refer to udfs) at least for a first version of these end points. I believe the are already efforts and discussions around constraints using this approach as well as corresponding work within Spark to make these exchanges more straightforward. I think if we minimize the surface area here we can probably figure out this API relatively quickly. On 2025/06/18 14:47:19 Robert Stupp wrote: > Hi all, > > We, the authors of the proposal [1], have been thinking about support > for fine grained access control for quite some time and would like to > propose both row-level access control and column-level transformation > (“masking”) to the Iceberg REST catalog in an interoperable way. > > The three main drivers for the proposed approach are > * interoperability between catalogs and query engines > * securely applying the FGAC policies > * ability to integrate any query engines > > The proposal describes the general, high-level approach and does > intentionally not go into specific internal & technical details to focus > on the concept as a whole. If there is consensus on the concept > described in the proposal, we can start a follow-up proposal considering > all the feedback - that would include details about the REST > specification and the technical interaction and between catalogs and > query engines, as well as portable representation of the policies and > “protection instructions” (details what the latter is are in the proposal). > > We would love to get your feedback and are happy to answer any questions! > > Robert > > [1] Proposal document > https://docs.google.com/document/d/1A5EHXZoluvW7GtEth3GzQz6n5N-fErYLtUbf6B93Pmw > > >
