Hi Iceberg community, I’d like to get feedback on a small REST Catalog docs change that introduces the term "Trusted Iceberg Client".
PR: https://github.com/apache/iceberg/pull/15545 My intention is to establish shared terminology for an assumption that already shows up in several active design discussions including UDF [1], read restrictions [2], and DEFINER/INVOKER view [3] discussions. In summary, there seems to be general consensus that catalog-driven obligations only have security meaning when they are enforced by a trusted client, and we are beginning to rely heavily on this concept to introduce granular authorization strategies. Right now we keep re-stating that assumption in each proposal, often with slightly different wording. This proposal adds a short subsection to "rest-catalog-spec.md" [4] to define that trust boundary in one place. The goal is consistency and clarity, and the language in the PR is also intentionally non-normative. If a future REST Catalog feature needs enforceable requirements, that Spec language of the feature could define its own normative clauses and reference this term. I’d appreciate feedback on: - whether it is worth formalizing this term now - whether "rest-catalog-spec.md" is the right place to introduce this term for the goals stated above - and whether `Trusted Iceberg Client` is the right name. [1] https://lists.apache.org/thread/5mo9sqff7t7c7yphhnzloyr7dkjf3osn [2] https://lists.apache.org/thread/v0w6s3hcogkftjxw70fm1z4n8r14bvcq [3] https://lists.apache.org/thread/01gb9rygdd1gqks7lnl1o6440qocnh9m [4] https://iceberg.apache.org/rest-catalog-spec/ Cheers, Sung
