Thanks for putting this together Yufei, I think this is a very useful discussion.
For context, the notion of “binding” in the new SPI came out of the earlier PR discussion [1], and at the time it felt like a reasonable direction, especially since we don’t have concrete M:N or even 1:N use cases today. One thing I’m still trying to understand is the intended semantic model behind having two lists (targets and secondaries) without an explicit binding. For example, for operations like ATTACH_POLICY_TO_TARGET, the name suggests a pairwise relationship between the policy and target. With the existing shape (List<PolarisResolvedPathWrapper> targets, List<PolarisResolvedPathWrapper> secondaries), it’s not immediately clear whether we’re evaluating over pairs, or over the Cartesian product of targets and secondaries, or treating the two lists completely independently. I don’t have a strong preference on enforcing 1:1 vs reverting to two independent lists, but I do think it would help to make the evaluation semantics explicit. Otherwise different implementations may interpret the same request differently. Curious how you’re thinking about this: - Should these generally be treated as independent sets, where each target and secondary is evaluated on its own without any pairing semantics? - Or should some operations still be interpreted as relationship-oriented, even without explicit bindings? And importantly, should these two questions be open to interpretation per each PolarisAuthorizer implementation? Sung [1] https://github.com/apache/polaris/pull/3760#discussion_r2830890135 On 2026/04/14 21:30:44 Yufei Gu wrote: > Hi folks, > > I’d like to get feedback on a proposal to simplify the authorization API: > https://github.com/apache/polaris/pull/4201. This PR removes > AuthorizationTargetBinding and replaces it with a simpler model based on > two lists: a target list and a secondary list. > > This avoids enforcing a 1:1 mapping in the binding class (I might miss > something regarding this enforcement, feel free to chime in), making it > more flexible to support 1:1, 1:N or even N:M relationships. For example, > supporting the attachment of one policy to multiple tables requires > duplicating bindings, which are then flattened anyway. This design also > aligns better with the existing RBAC semantics, where target securables are > evaluated as one group and secondary securables as another, instead of > enforcing pairwise mappings. > > Open question: We may not need N:M relationships. I couldn’t come up with a > clear use case. > > Note: This interface was introduced recently and is not part of any > release, so it can be removed without deprecation. > > Would love to hear feedback, especially on the intended semantics and real > use cases. > > Yufei >
