Hi All, On permissions and federated catalogs: If we assume that tag/label visibility is a product of authorization rules, then it will be critical to propagate the client's identity to Federated catalogs, I think.
Note that this is not how Federation currently works. If we filter local tags by local Authorizer decisions, but forward Federated labels based on the service identity, it will create an authorization skew. A similar skew exists with vended credentials for federated tables. However, for tables the recommendation currently is to create mirror entities in Polaris [5528][5548], which subsequently allows Polaris-side Authorization deciusions. (Note that the referenced Federation RBAC doc changes have not been released yet.) However, this does not seem to be possible with labels (due to limited provenance information, as discussed previously). Cheers, Dmitri. [5528] https://github.com/apache/polaris/issues/5528 [5548] https://github.com/apache/polaris/pull/5548 On Mon, Oct 12, 2026 at 6:49 AM Andrei Tserakhau via dev < [email protected]> wrote: > Hi JB, > > Thanks, good to keep the Glasgow conversation going. Glad we're aligned on > opt B. > > On your questions: > > 1/ Permissions / leakage: I'd reuse the existing tag visibility rules > rather than add a label-specific privilege. On `loadTable` / `loadView`, > labels would only include tags the caller is already allowed to see through > the Tag API. Table access alone would not expose anything extra. > > 2/ Performance: Agreed, `loadTable` is too hot to resolve inheritance on > every call. I'd cache the effective tags per table, invalidate on tag > changes, then apply the caller-specific visibility filter on top. That > should keep the added cost small. > > 3/ Default vs gated: I'd gate it initially with something like > `polaris.label.enabled` per catalog, default off. We can move toward > on-by-default later once the behavior and cost are proven. > > Best, > Andrei > > On Mon, Oct 12, 2026 at 9:43 AM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi Andrei > > > > Thanks for starting this thread after our discussion during Lakehouse > > Day/CommunityOverCode in Glasgow. > > > > I'm +1 to option B (labels as a read-only projection over tags). Tags > > already have definitions, allowed values, inheritance and reverse lookup, > > and both models are keyed by Iceberg field-id. A separate labels entity > > would give us two source of truth to reconcile, with no benefit imho. > > > > The tag work isn't merged yet, so it's cheap (good timing :)) to reserve > > what the consumer role needs. Postponing this later would be much more > > painful. I would keep the actual federation impl out of the first tag PR. > > > > About collisions, "native wins" is reasonable. Polaris is the asserting > > catalog at the point of access, so I'm fine with that rule. > > > > I have a few questions: > > - We have to be careful that tag-definition visibility (permission) > > doesn't leak through labels. Do we plan to see labels on > loadTable/loadView > > relying on the table read privileges? Or do we want specific privileges > for > > label/tag? > > - Resolving tags with inheritence on every loadTable can be significant > > for performence. What are your thoughts about that? Opt caching? > > - Do we want to have label emitted by default, or do you want to guate by > > catalog configuration (polaris.label.enabled=on)? > > > > Thanks! > > Regards > > JB > > > > On Sun, Oct 11, 2026 at 11:26 AM Andrei Tserakhau via dev < > > [email protected]> wrote: > > > >> Hi all, > >> > >> Now that the IRC "labels" field has merged in Iceberg Spec ([0]) and the > >> Polaris Tag work is close ([1]), I'd like to open a thread on how > Polaris > >> should support labels. > >> > >> There are two ways Polaris could do labels: > >> > >> A) Labels as a separate entity - their own definitions/store, parallel > to > >> Tags. > >> B) Labels as a projection over Tags - read-only IRC view / projection of > >> the existing tag model. > >> > >> I propose B. Tags already are the structured model: definitions, > >> assignments, allowed values, inheritance, reverse lookup. IRC labels are > >> designed as the flat read surface of such models (object-level > key/values > >> plus per-field labels by field-id). A separate labels entity would > >> duplicate the tag model and create two sources of truth to reconcile; a > >> projection keeps one model with two surfaces, a structured authoring > API > >> and an interoperable flat read field. Column identity already lines up: > >> Tags use the Iceberg field-id, and IRC labels fields are keyed by > >> field-id. > >> > >> Given B, a Polaris catalog plays two roles: > >> > >> 1. Producer. Polaris resolves a target's effective tags (inheritance > >> applied, closest-wins) and projects them into IRC labels on > >> loadTable/loadView. The Tag API stays the authoring/management surface > and > >> labels is the read projection for IRC compliant engines. > >> > >> 2. Consumer. When Polaris federates a foreign IRC catalog, it reads that > >> catalog's labels and stores them as tags owned by the source catalog: > >> read-only in Polaris and clearly marked as foreign. A Polaris user > cannot > >> edit them (they change only when Polaris re-syncs from the source) and > >> they > >> stay separate from Polaris's own natively-authored tags. That is how a > >> foreign catalog's metadata becomes usable in Polaris without pretending > it > >> is local. > >> > >> Mostly I'd like the community read on whether projection-over-tags feels > >> right, and whether the producer/consumer split is worth keeping in mind > in > >> the Tag design so the contract leaves room for it. Would like to hear if > >> this framing is wrong, or where a separate entity would actually serve > >> better. > >> > >> Thanks, > >> Andrei > >> > >> [0] IRC Labels spec PR - https://github.com/apache/iceberg/pull/15750 > >> [1] Tags discussion thread - > >> https://lists.apache.org/thread/28h8bvg3pwwmpob2p4gcrpfs1x5cgkmn > >> > > > -- Dmitri Bourlatchkov Senior Staff Software Engineer, Dremio Dremio.com <https://www.dremio.com/?utm_medium=email&utm_source=signature&utm_term=na&utm_content=email-signature&utm_campaign=email-signature> / Follow Us on LinkedIn <https://www.linkedin.com/company/dremio> / Get Started <https://www.dremio.com/get-started/> The Agentic Lakehouse The only lakehouse built for agents, managed by agents
