Hi Dan, Apologies for the confusion. "Write" was a poor word choice on my part. I didn't mean enforcing policy on writers and you're right that a writer holds the highest level of access, and there's little to restrict there. By "write" I meant to refer to the lifecycle of the policies themselves: creating, updating, and deleting them. Enforcement stays on the read side (#13879). This is the complementary authoring path discussion on policies.
The problem I'm looking at is that a policy bound to a column by name can detach or retarget when that column is renamed or dropped. A policy also can't land in the same commit as the column it protects, so the column can exist before its protection does. I've written up the analysis and a direction that could close it [1], and I'd appreciate your review. Christian, thanks. I agree with your pointers. Drop+re-add is a good example of the general case and it faces the same exposure as any schema change when policy is managed separately from the schema change that introduces it, which is exactly the problem the doc works through. I'd value your review on the shared doc. Sung [1] https://docs.google.com/document/d/1yL2Yv70hJ569dpLdW_upTzzK8Zb3fAFEKEH4JRdosjU/edit?tab=t.0 On 2026/06/15 15:19:12 Daniel Weeks wrote: > 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 > >> > > >
