Hey Corey, Thank you for the questions, I would recommend checking the ReadRestrictions sync videos [1], as almost all the questions you are asking are covered there, you can also check previous mailing threads with these keywords . I would also recommend checking this talk of mine from this year iceberg summit which dives on how we have been thinking this E2E [2] : 1. Why don't define trust inside the spec:The community came to a *consensus* that we don't want it defined in spec. The reason for this is multitudes one such is platform dependent, one might feel comfortable with mTLS, other might prefer OAuth On-behalf, then there are systems like AWS Lakeformation which expects stuff in STS token tags, check one such thread where we discuss this question again (ref thread [3]) 2. We plan to introduce iceberg SQL udfs in read restrictions i.e expression referencing SQL UDFs as fast follow up for these semantics, but it has its own quirks like views, presently a lot of platforms deny such requests with a 403 which they can continue doing if it's not translatable, the current one per our analysis covers a lot of existing landscape for example RANGER / BigQuery, and you can check the past read restrictions syncs on how we landed up on them. P.S : *I don't think we can have an universal policy definition which covers 100% of any arbitrary authored policy*. 3. The spec just puts the *requirement* that clients must make sure, how they do that is very client specific, and we refrain from that as well, for example SQL clients can use secure views, given they have a notion of secure view, but there are non sql clients too ... infact one of my POC is demonstrating this with iceberg generics ... Establishing trust is a shared model between Admin and Catalog, even if the engine correctly implements it and some one can ssh into the compute and inject custom code it defeats the purpose, as Admin one should ensure its trusting the client which meets the spec requirement and once the catalog returns the restrictions the client can enforce it [3] 4. I did brought view into the consideration in one of the read restrictions syncs and the stance there was we can always add that later but the read of the room was its not something which we require in phase 1
[1] https://docs.google.com/document/d/1iGNydKY7XT1N5Nz056vDPM0P8v0MFymGqNtOlUGUp-c/edit?tab=t.0#heading=h.tevndn85fps [2] https://www.youtube.com/watch?v=1C99NSu1tuI&list=PLkifVhhWtccxSA6VskdKdLnIwCJevOqFL&index=26 [3] https://lists.apache.org/thread/01gb9rygdd1gqks7lnl1o6440qocnh9m Best, Prashant Singh On Mon, Aug 17, 2026 at 10:34 AM Corey Sunwold via dev < [email protected]> wrote: > Hi folks, > > I've only recently started learning about the Read Restrictions proposal > and I'm trying to understand it better from an implementer's perspective. I > realize the spec isn't final but given the amount of work already done, I'm > hoping others have already thought about these topics. If there are past > email threads where these topics have already been discussed please let me > know. > > > 1. It appears that the trust relationship is considered outside the > scope of this proposal, but a solution for it feels critical to a working > implementation. How are other implementers approaching this? In my opinion > extending trust for Read Restrictions that we extend today to clients we > vend credentials to is not a good model. Today we vend credentials only if > you have full access to a table. Anything you can then do with the > underlying files is equivalent to what you can do with the table. However, > Read Restrictions breaks that model. If you have read restrictions you may > only have access to a subset of an individual file. We need a way to trust > that when we give a credential that implicitly gives access to a full file > (or set of files) to an engine that will properly protect the credential > and faithfully and correctly restrict the file contents returned to a > consumer. My concern is that without a solution to this (even one defined > outside this spec) we will have a spec that only ever exists on paper and > cannot be used in practice. > 2. A number of catalogs already have different fine grained access > control capabilities in their native formats and I expect these will also > get made available via Iceberg Rest Catalog interfaces. Many of the column > mask and row filter capabilities may or may not translate directly to the > pre-defined Read Restriction functions. How are other implementers > approaching the translation problem? If there is no clear translation, the > safe approach will certainly be to fail the request. Recognizing that an > arbitrary SQL UDF is functionally equivalent to the defined spec of a Read > Restriction function may be tricky to get right. > 3. Does the spec offer any opinion on how clients should execute Read > Restriction functions? Postgres has a great writeup in their documentation > on the danger of not including a security barrier in views and how > information can be leaked: > https://www.postgresql.org/docs/current/rules-privileges.html. I would > consider this closely related to my first question. As an implementer, I > may want to trust a client that correctly implements a security barrier and > not trust clients that don't. > 4. Does the spec apply only to tables or all table-like objects > including views? > > > Thanks, > Corey Sunwold >
