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