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 > > I think we can follow up > > 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 > > > > > > > > >
