Hi all,

I agree. Personally, I think we already have quite a few meetings, and we
should also aim to do a better job of syncing with the dev@ mailing list
after our calls. As a reminder, we don't take final decisions during the
meetings themselves.
Async/mailing list/PR is way more efficient than meeting imho, and allow
anyone in the community (wherever they are located, etc) to be involved.

Regards,
JB

On Tue, May 19, 2026 at 6:07 PM Dmitri Bourlatchkov <[email protected]>
wrote:

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

Reply via email to