Hey Sung, I'm not sure I fully understand the use case here. Generally, readers can have different policies when they consume data (what's restricted/hidden/obfuscated). However, on the write path, I'm not aware of scenarios where similar policies would be applied. A writer typically has the highest level of access because they need to read (metadata at minimum) and write (both metadata and data).
What use cases are you envisioning for write side policy enforcement? Thanks, Dan On Sun, Jun 14, 2026 at 11:43 PM Christian Thiel <[email protected]> wrote: > 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 >> >
