Hi All, I agree with Sung that we probably do not need another sync call right now.
PR [4409] looks good from my POV, but I also do not mind Yufei's suggestion to keep PolarisPrincipal inside AuthorizationRequest. [4409] https://github.com/apache/polaris/pull/4409 Cheers, Dmitri. On Tue, May 19, 2026 at 11:51 AM Sung Yun <[email protected]> wrote: > Hi JB, > > Thank you for the offer. I personally think we can follow up asynchronously > since it feels like we’ve already converged significantly on the topic. But > I’m happy to facilitate another sync if new questions come up on the > Authorization topic. > > And if we feel the need to start the recurring sync again in the future, we > can always do so. > > Sung > > On Tue, May 19, 2026 at 11:41 AM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Thanks for the update. > > > > I think Yufei's suggestion makes sense as well. > > > > Do you want me to extend the Google Calendar invite? > > > > Regards > > JB > > > > On Tue, May 19, 2026 at 5:13 PM Sung Yun <[email protected]> wrote: > > > > > Hi Yufei, > > > > > > I think the suggestion makes sense. > > > > > > Just a reminder for everyone that the recurring Authorization Sync > > cadence > > > has now ended on the Google Calendar. I think the syncs were very > > > productive overall and helped us converge meaningfully on the broader > > > authorization direction and SPI design tradeoffs. Thanks everyone for > the > > > thoughtful discussions and participation throughout the series. > > > > > > At this point, it feels like we are converging more concretely on the > SPI > > > shape directly in PR #4409 [1], so I’ll continue driving convergence > and > > > follow through on the remaining refactoring work there. And of course, > if > > > we feel there’s value in reviving the series in the future, we can > always > > > do so. > > > > > > Here are the Authorization Sync notes for reference [2]. > > > > > > [1] https://github.com/apache/polaris/pull/4409 > > > [2] > > > > > > https://docs.google.com/document/d/1C_SSaZH1i83UUGXrnVBur1fR_FHKYWZ75ISFfcb3kns/edit?tab=t.0#heading=h.wodibvbtg7qj > > > > > > > > > On 2026/05/13 23:59:24 Yufei Gu wrote: > > > > 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 > > > > > > > > > > > > > > > > > > > >
