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 > > >
