Hello Sung, thanks for sharing this!
I'd definitely be interested in seeing your ideas for the proposal. Especially your point about field-id binding had me thinking — since admins author against names and never see field-ids today, it'd be worth spelling out where and when that name→field-id binding happens, and how it handles drop+re-add. I think a number of interesting points are worth discussing such as coexistence with external policy engines and separation of duties on commit, while still keeping the field-id binding intact where it applies. Looking forward to it! Best, Christian On Fri, 5 Jun 2026 at 22:59, Sung Yun <[email protected]> wrote: > Hi folks, > > The FGAC / Read Restriction proposal [1] is introducing a read-side path > to standardize how we describe row filters and masks, and to do it safely > across schema evolution by binding them to field-ids. We don't yet have > anything matching on the write path. > > Today, policies are administered entirely outside the REST protocol, so > external systems reference columns by name, as they're not part of the > commit and never see field-ids. And two things break once schema and policy > have to change together: > - a policy bound to a column name silently re-targets when the column is > renamed > - a policy commits separately from the schema change it depends on, so a > column can exist before its protection does > > So far, policy administration has been left out of scope [2], and now that > the Read Restrictions Proposal is finding consensus, I believe it is a good > time to start thinking about it on the write path. > I have a rough direction in mind, of enabling co-committing policy and > binding it to field-ids on the server-side. So I wanted to gauge: > 1. whether people see this as a gap worth closing in the IRC protocol > 2. whether there are concerns or considerations that should be taken into > account > > If there's interest, I'm happy to put together a detailed proposal and > share it here for discussion. > > Sung > > [1] > https://docs.google.com/document/d/108Y0E8XsZi91x-UY0_aHLEbmXDNmxmS5BnDjunEKvTM/edit?tab=t.7l861fq8jo38 > [2] https://lists.apache.org/thread/2jx33fn7lq37oxxm7sd6rjy0dnvbm4t6 >
