Hi Sung, Thanks for raising this. The overlap with the labels write-side work I've been drafting with @Sebastian Baunsgaard <[email protected]> is structural -- same lifecycle, field-id binding, co-commit and concurrency questions, different payload.
But what stands out more than the specific overlap is that this is the first sighting of a pattern the spec doesn't yet have a framework for: catalog-authored, lifecycle-managed write APIs that reach deep into catalog-owned space. Read Restrictions already does this on the read side — policies are very much catalog territory. Your authoring proposal extends it to write. Labels CRUD lands in the same neighborhood from a different direction. Kevin asked something close to this at the May 28 labels sync: what's the pattern for introducing new first-class concepts in the REST spec? Ryan's answer pointed at the shape (CRUD verb + transactional path), but the deeper question hasn't been worked through — should the spec standardize the write side of catalog-owned territory at all, or is this best left ad-hoc per proposal with capability negotiation governing client expectations? I lean toward Capabilities being the right frame here. Catalogs opt in, clients discover what's supported, the spec doesn't force standardization deep into catalog territory. A unified write-side surface has real value for clients — engines, custom tools, one shape to learn — but real cost too: catalog innovation space shrinks to differentiators inside a spec-prescribed envelope. So before aligning on specific conventions, worth asking the meta-question: shall we go this direction at all? And if yes — ad-hoc per proposal, or a deliberate meta-framework? This is broader than labels alone, so probably worth raising at one of the upcoming catalog community syncs as a meta-topic rather than the labels-specific sync. Labels sync can pick up labels-side implications afterward, once the broader direction is clearer. Best, Andrei On Mon, Jun 15, 2026 at 9:10 AM Sung Yun <[email protected]> wrote: > 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 > > >> > > > > > >
