Hi Yufei, I appreciate having this discussion, as it will hopefully lead to more clarity on the AuthZ SPI use cases.
However, at this point I find the many-to-many (N:M) association between targets and secondaries very confusing (mainly because there are no realistic use cases). Transferring my comment from GH [1] for visibility: If targets and secondaries form a non-trivial (size > 1) set, I believe a more coherent approach would be for the caller to perform multiple authorization checks for each <op, target, secondary> tuple as appropriate for the use case. I believe the existing SPI covers that by List<AuthorizationTargetBinding>. Re: the Cartesian product of targets and secondaries - does anyone have such a use case in practice? [1] https://github.com/apache/polaris/pull/4201#issuecomment-4247944484 Thanks, Dmitri. On Mon, Apr 20, 2026 at 2:25 PM Yufei Gu <[email protected]> wrote: > Thanks for sharing more context. I copied the reason for introducing the > binding here. > > Given current use cases, I wonder if a List-to-List relationship between > > targets and secondary is actually correct in general. I'd imagine in all > > relevant cases it is a 1:1 association. When there are multiple targets, > > there are going to be multiple target/secondary pairs. > > > I think the intuition may well be right for many current use cases, many of > them do look like 1:1 associations in practice. But I am not sure that > means 1:1 should be treated as a required constraint in the model. > > I am hesitant to make that assumption for a few reasons. > > First, from a modeling perspective, the relationship is not necessarily > 1:1. A target may depend on multiple secondaries, for example, it might > grant multiple privileges to a role. You might argue this could be done by > flattening them into multiple pairs, but the flattening itself seems > unnecessary. Conversely, multiple targets may also share the same > secondary, such as supporting the attachment of one policy to multiple > tables. > > Second, even if today's cases mostly look 1:1, keeping the API as list to > list gives us more flexibility going forward. It avoids having to redesign > the API when new operations introduce more complex dependency > relationships, and also prevents the SPI from being constrained to an > overly narrow expressive model. > > To answer your questions and concerns: > > > Should these generally be treated as independent sets, where each target > and secondary is evaluated on its own without any pairing semantics? > > I'd prefer to treat them as independent sets because the privileges are the > same for either the whole target list or secondary list, using RBAC as an > example. I think the paring semantics make more sense when we can apply > different privileges to different pairs. > > > 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. > > Maybe we just need to document the behavior here? I'm open to the ideas. > > > Yufei > > > On Tue, Apr 14, 2026 at 3:49 PM Sung Yun <[email protected]> wrote: > > > 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 > > > > > >
