Hi Sung, Dmitri,
After reviewing the PR, I'd push back on lifting PolarisPrincipal out of
AuthorizationRequest. (subject, action, resource) is the canonical tuple
for authorization, the principal is the "who" in "who did what on what" and
belongs with the operation and target as part of one authorization
question, not as a parallel argument threaded alongside.
Batching feels like an internal concern of the request model, not a reason
to split principal out. The targeted shapes are really (action, resource).
They don't need to know about the subject. So I'd factor that into its own
interface and let AuthorizationRequest compose principal on top:
// (action, resource)
public sealed interface AuthorizationIntent {
PolarisAuthorizableOperation operation();
record Untargeted(PolarisAuthorizableOperation operation)
implements AuthorizationIntent {}
record SingleTarget(PolarisAuthorizableOperation operation,
PolarisSecurable target)
implements AuthorizationIntent {}
record PairwiseTarget(
PolarisAuthorizableOperation operation,
@Nullable PolarisSecurable target,
@Nullable PolarisSecurable secondary)
implements AuthorizationIntent {}
}
// (subject, intents), single shape, batching is just N >= 1
record AuthorizationRequest(
PolarisPrincipal principal,
List<AuthorizationIntent> intents) {}
If a future flow ever needs mixed-principal batches, that's a new sealed
variant rather than an SPI signature change.
I think it's worth getting this right before handlers migrate, since
walking the SPI shape back later is much harder than now. Curious what you
and others think.
Yufei
On Wed, May 13, 2026 at 9:41 AM Yufei Gu <[email protected]> wrote:
> Hi Sung,
>
> Thanks for moving this forward. I agree PR #4409 is the right place to
> continue the concrete interface-shape discussion.
>
> At a high level, I like the direction of making authorization request
> shapes more explicit and keeping batch authorization in mind. I will take a
> look at the PR.
>
> Yufei
>
> On Wed, 13 May 2026 10:09:42 -0400, Dmitri Bourlatchkov [email protected]
> wrote:
>
> Hi Sung,
>
> Thanks for pushing this work forward!
>
> I commented on PR 4409 in GH.
>
> In general I like the direction this PR is going. Still, I think some more
> fine-tuning would improve interface clarity (as commented in GH).
>
> Thanks,
> Dmitri.
>
> On Wed, May 13, 2026 at 8:46 AM Sung Yun [email protected] wrote:
>
> Hi Dmitri, Yufei,
>
> Thank you for keeping the discussion going on the other thread [1]. I’m
> following up here on the proposal to fold this into the new authorization
> SPI work.
>
> Based on feedback from the Polaris Community Authorization Sync on May 7
> [2], I put together a PR [3] that changes the shape of the new authorize
> SPI and AuthorizationRequest so the request model makes the authorization
> target shape more explicit inside PolarisAuthorizer.
>
> At a high level, the PR:
> - introduces batch authorize APIs that take List
> - removes PolarisPrincipal from AuthorizationRequest, so caller context is
> not duplicated across batch requests
> - reworks AuthorizationRequest into a sealed hierarchy with explicit
> request shapes:
> - SingleTargetAuthorizationRequest
> - PairwiseTargetAuthorizationRequest
> - TargetlessAuthorizationRequest
>
> This is an SPI-breaking proposal, but since the new SPI is not yet used by
> the main request flow, I believe this is still a safe point to make the
> change.
>
> I’d appreciate feedback on whether this request shape is a better fit for
> the new SPI, especially given the earlier concern that AuthorizationRequest
> should make resource shape more explicit.
>
> [1] https://lists.apache.org/thread/o5hntqfvfhn5z9t78480nplpypddg200
> [2]
>
> https://docs.google.com/document/d/1C_SSaZH1i83UUGXrnVBur1fR_FHKYWZ75ISFfcb3kns/edit?tab=t.0#heading=h.wodibvbtg7qj
> [3] https://github.com/apache/polaris/pull/4409
>
> On 2026/04/06 20:23:11 Yufei Gu wrote:
>
> Given that, let’s keep them separate. See you guys tomorrow.
>
> Yufei
>
> On Mon, Apr 6, 2026 at 11:43 AM Dmitri Bourlatchkov [email protected]
> wrote:
>
> Hi All,
>
> I may not be available for the entire Community Sprint time slot
> tomorrow.
> I’d personally prefer to keep the old Authorization meeting time and
> video
> call format.
>
> Cheers,
> Dmitiri.
>
> On Mon, Apr 6, 2026 at 2:05 PM Sung Yun [email protected] wrote:
>
> Hi Yufei,
>
> That’s a good suggestion - I’m open to merging them. That said,
> since we
> already have a dedicated and well-established sync for
> Authorization, it
> might be better to use the Community Sprint for other topics and help
> create structure around those discussions.
>
> I’m fine either way. Happy to align with what works best for the
> group.
>
> Sung
>
> On 2026/04/06 17:59:32 Yufei Gu wrote:
>
> Hi folks,
>
> We have a Polaris Community Spring tomorrow afternoon. Can we
> merge the
> morning’s Polaris Authorizer Sync Meeting into the Sprint?
>
> Yufei
>
> On Tue, Mar 24, 2026 at 11:30 AM Dmitri Bourlatchkov <
> [email protected]
>
> wrote:
>
> Hi Sung,
>
> Thanks for driving this call! I think today’s session was very
> useful
> and
> productive.
>
> Just to sync up with everyone: I believe we will continue
> working on
> code
> refactorings (SPI PRs) between those community calls and discuss
> specific code-level issues via email or GH comments.
>
> Cheers,
> Dmitri.
>
> On Mon, Mar 23, 2026 at 8:23 AM Sung Yun [email protected]
> wrote:
>
> Thanks a lot JB!
>
> Confirming that I’m able to see the new recurring sync on my
> Google
> calendar.
>
> I’m looking forward to syncing up with everyone tomorrow at
> 1pm ET
> /
> 10am
> PT.
>
> Cheers,
> Sung
>
> On 2026/03/23 09:55:47 Jean-Baptiste Onofré wrote:
>
> The invite has been sent. Anyone member of the Polaris Google
> Group
> will
> receive it.
>
> Here’s the invite details:
>
> Polaris Authorizer Sync Meeting
> 10am PT
> Video call link: https://meet.google.com/hyj-fcdm-ydx
>
> NB: I’m creating a Calendar that will create a PR to share
> on the
> website.
>
> Regards
> JB
>
> On Mon, Mar 23, 2026 at 10:51 AM Jean-Baptiste Onofré <
> [email protected]
>
> wrote:
>
> Hi Sung,
>
> I propose moving the sync to 10:00 AM PT (starting March
> 24th)
> to
> avoid a
> conflict with the Iceberg meeting.
>
> I am sending the calendar invitation now.
>
> Regards,
> JB
>
> On Sat, Mar 21, 2026 at 12:52 AM Sung Yun [email protected]
> wrote:
>
> Hi JB, that’ll be fantastic.
>
> It looks like we have enough members interested in
> joining the
> sync.
>
> Could I ask for your help in adding a meeting to the
> Polaris
> Agenda
> group
> [1], for Tuesdays at 12:00 PM ET (9:00 AM PT), starting
> March
> 24th?
>
> Thanks a lot JB. And here’s the Google Doc [2] I created
> where
> we
> can
> keep track of the discussion topics for the sync as well.
>
> Looking forward to discussing auth with everyone.
>
> Sung
>
> [1]
> https://groups.google.com/u/1/g/polaris-community-sync
> [2]
>
>
> https://docs.google.com/document/d/1C_SSaZH1i83UUGXrnVBur1fR_FHKYWZ75ISFfcb3kns/edit?tab=t.0
>
> On 2026/03/20 14:15:40 Jean-Baptiste Onofré wrote:
>
> Hi
>
> As discussed together, I think it’s a great idea.
>
> I’m happy to add a meeting (recorded) on the Polaris
> agenda
> (Google
> Group).
>
> On a related topic, I will create a PR to add a Calendar
> with
> all
> our
> meetings on our website.
>
> Regards
> JB
>
> On Thu, Mar 19, 2026 at 7:30 PM Sung Yun <
> [email protected]
>
> wrote:
>
> Hi folks,
>
> Following the discussion in the Polaris community
> sync, it
> seems
> like
> we
> could benefit from a dedicated forum to work through
> the
> PolarisAuthorizer
> SPI and related questions.
>
> Some topics we can start with include:
>
> - Decoupling Polaris resolution and privilege from
> Polaris
> authorization
> - Mixed-mode authorization (continuing to use native
> principals
> and
> grants
> after decoupling)
> - Contract with external authorizers for Polaris
> (e.g.,
> PolarisAuthorizableOperation, PolarisEntityType)
> - Incorporating additional authorization context
>
> I’d like to propose a fortnightly authorization sync
> to
> drive
> these
> topics
> forward.
>
> I’m thinking Tuesdays at 12:00 PM ET (9:00 AM PT),
> starting
> March
> 25
> (the
> second sequence will be April 7th, and on). I’m happy
> to
> send
> out
> a
> calendar invite if there is general support in the
> community on
> the
> idea.
>
> Cheers,
>
> Sung
>
>
