Changing my vote to +1 since the separator has been addressed and the referenced-by discussion looks like we've concluded. Thanks!
On Fri, Jan 30, 2026 at 4:49 PM Russell Spitzer <[email protected]> wrote: > No problem, I know we’ve been going back on this one for a while so it’s > been a bit confusing > > On Fri, Jan 30, 2026 at 6:07 PM Daniel Weeks <[email protected]> wrote: > >> Thanks for the clarification Russel and Prashant. >> >> My initial concern was that we were introducing the definer/invoker >> constructs and assuming the trust relationship through the spec language, >> but it looks like we reference that in the PR description and discussion >> but not the spec language itself. At some point we need to address the >> intended usage here because the primary usage was within the context of the >> trust relationship (other usage like auditing seems a secondary >> motiviation). >> >> Apologies for the confusion and I'll happily retract my -1. >> >> -Dan >> >> >> >> On Fri, Jan 30, 2026 at 2:29 PM Prashant Singh <[email protected]> >> wrote: >> >>> Thank you for the feedback Ryan, I will update the separator in this >>> case to be the namespace separator ! I will do more research on other >>> feedback. >>> >>> Thanks for the feedback Dan, >>> >>> Agree with Russell here, I believe the whole reason why we wanted to >>> have a referenced-by chain is to give the catalog the complete context of >>> how to Authorize and since IRC don't go in the world of AuthZ >>> we thought just let the catalog do what they wanna do with >>> referenced-by, we are *not* defining actions what we want the catalog >>> to take in the spec. >>> We have additionally discussed this in the DISCUSS thread too [1]. >>> >>> Definitely for the E2E picture for making this work we need *Trusted >>> Engine,* *OWNER* privilege and then *AuthZ* to correctly give read >>> access to the table, but these are purely Catalog side constructs based on >>> AuthZ. >>> The simplest rationale of allowing this to be sent from the client to >>> server apart from DEFINER view is to help in audit as well. >>> >>> Please let us know if it helps address your concerns. >>> >>> [1] https://lists.apache.org/thread/01gb9rygdd1gqks7lnl1o6440qocnh9m >>> >>> Best, >>> Prashant Singh >>> >>> On Fri, Jan 30, 2026 at 1:03 PM Russell Spitzer < >>> [email protected]> wrote: >>> >>>> @Daniel I believe we talked about this only working in a situation >>>> where the client and catalog have already pre-established a trusted >>>> relationship. This was brought up again on the PR a few days ago, >>>> https://github.com/apache/iceberg/pull/13810#issuecomment-3816022525 >>>> and Prashant posted links again to the original thinking there. >>>> >>>> Wouldn't this mean that you just can't give access to a client which >>>> can make arbitrary calls against your catalog? >>>> >>>> If a client can fake a request to the catalog, then why wouldn't it >>>> just ask for the table through the view directly, get the files (ignoring >>>> the view) and then read the table? >>>> >>>> On Fri, Jan 30, 2026 at 2:30 PM Daniel Weeks <[email protected]> >>>> wrote: >>>> >>>>> I'm going to have to update my comment to -1. >>>>> >>>>> Based on some of the discussion in the PR, I went back and reviewed >>>>> the discussion and I don't think this approach works based on some >>>>> comments >>>>> I made in the recording (link with timestamp >>>>> <https://youtu.be/orAXA5e9pmU?si=CjIEQk__dcTWcdEi&t=1438> and again >>>>> here <https://youtu.be/orAXA5e9pmU?si=tvpIN6ytIu2JU_fj&t=1902>). >>>>> >>>>> The main issue I see is that we're not enabling a secure way to do >>>>> this because we cannot trust the client to provide the surrounding view. >>>>> What would prevent a client from just addressing a defender view in a load >>>>> table and accessing data the invoker should not have access to? >>>>> >>>>> I feel like there are security implications here that we haven't >>>>> properly addressed. >>>>> >>>>> -Dan >>>>> >>>>> >>>>> >>>>> On Fri, Jan 30, 2026 at 8:52 AM Ryan Blue <[email protected]> wrote: >>>>> >>>>>> -1 for now (will probably change) >>>>>> >>>>>> I think that there is a problem in that a dot is used to separate the >>>>>> namespace (which uses namespace separator) from the table name. If my >>>>>> namespace separator is `|` then it would require `name|space.table`. Why >>>>>> not use the same separator between the namespace and table name? If we >>>>>> use >>>>>> `.` then the last namespace part cannot have a `.`, which is an odd >>>>>> restriction. >>>>>> >>>>>> On Thu, Jan 29, 2026 at 12:07 PM Daniel Weeks <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> +1 (binding) >>>>>>> >>>>>>> Minor comments on the Spec PR. I'm assuming everyone is voting >>>>>>> specifically on the spec changes, but just want to clarify >>>>>>> (implementation >>>>>>> PR will go through normal review process). >>>>>>> >>>>>>> -Dan >>>>>>> >>>>>>> On Thu, Jan 29, 2026 at 9:38 AM Steve <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> +1 (non-binding) >>>>>>>> >>>>>>>> On Thu, Jan 29, 2026 at 12:57 AM Alexandre Dutra <[email protected]> >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > +1 (non-binding) >>>>>>>> > >>>>>>>> > Thanks, >>>>>>>> > Alex >>>>>>>> > >>>>>>>> > Le jeu. 29 janv. 2026 à 08:19, Bharath Krishna < >>>>>>>> [email protected]> a écrit : >>>>>>>> >> >>>>>>>> >> +1, that was a missing piece for view authorization! >>>>>>>> >> >>>>>>>> >> On 2026/01/29 07:03:31 roryqi wrote: >>>>>>>> >> > +1, excited to see this. I am working on related work about >>>>>>>> Apache Gravitino. >>>>>>>> >> > >>>>>>>> >> > Christian Thiel <[email protected]> 于2026年1月29日周四 >>>>>>>> 14:50写道： >>>>>>>> >> > > >>>>>>>> >> > > +1 (non-binding) >>>>>>>> >> > > >>>>>>>> >> > > Gábor Kaszab <[email protected]> schrieb am Do. 29. >>>>>>>> Jan. 2026 um 07:22: >>>>>>>> >> > >> >>>>>>>> >> > >> +1 (nb) >>>>>>>> >> > >> >>>>>>>> >> > >> Gábor >>>>>>>> >> > >> >>>>>>>> >> > >> On Thu, 29 Jan 2026, 00:02 Adnan Hemani via dev, < >>>>>>>> [email protected]> wrote: >>>>>>>> >> > >>> >>>>>>>> >> > >>> +1 (non-binding) >>>>>>>> >> > >>> >>>>>>>> >> > >>> On Wed, Jan 28, 2026 at 10:17 AM Steven Wu < >>>>>>>> [email protected]> wrote: >>>>>>>> >> > >>>> >>>>>>>> >> > >>>> +1 >>>>>>>> >> > >>>> >>>>>>>> >> > >>>> On Wed, Jan 28, 2026 at 8:02 AM Russell Spitzer < >>>>>>>> [email protected]> wrote: >>>>>>>> >> > >>>>> >>>>>>>> >> > >>>>> +1 >>>>>>>> >> > >>>>> >>>>>>>> >> > >>>>> On Wed, Jan 28, 2026 at 10:01 AM Eduard Tudenhöfner < >>>>>>>> [email protected]> wrote: >>>>>>>> >> > >>>>>> >>>>>>>> >> > >>>>>> +1 >>>>>>>> >> > >>>>>> >>>>>>>> >> > >>>>>> On Tue, Jan 27, 2026 at 6:29 PM Prashant Singh < >>>>>>>> [email protected]> wrote: >>>>>>>> >> > >>>>>>> >>>>>>>> >> > >>>>>>> Hello everyone ! >>>>>>>> >> > >>>>>>> The namespace separator for nested namespaces >>>>>>>> discussion is converged (thanks a ton Eduard) >>>>>>>> >> > >>>>>>> I additionally also added wording for the nested views >>>>>>>> per the feedback. >>>>>>>> >> > >>>>>>> The spec proposal [1] is ready for review again, I >>>>>>>> have also updated the reference implementation too from client side >>>>>>>> [2] per >>>>>>>> spec. >>>>>>>> >> > >>>>>>> >>>>>>>> >> > >>>>>>> Please do have a pass and vote based on how you all >>>>>>>> feel, when you get some time. Appreciate all the feedback so far ! >>>>>>>> >> > >>>>>>> >>>>>>>> >> > >>>>>>> [1] https://github.com/apache/iceberg/pull/13810 >>>>>>>> >> > >>>>>>> [2] https://github.com/apache/iceberg/pull/13979 >>>>>>>> >> > >>>>>>> >>>>>>>> >> > >>>>>>> Best, >>>>>>>> >> > >>>>>>> Prashant Singh >>>>>>>> >> > >>>>>>> >>>>>>>> >> > >>>>>>> >>>>>>>> >> > >>>>>>> >>>>>>>> >> > >>>>>>> On Fri, Sep 5, 2025 at 10:04 AM Prashant Singh < >>>>>>>> [email protected]> wrote: >>>>>>>> >> > >>>>>>>> >>>>>>>> >> > >>>>>>>> Thanks for the feedback, Ryan. I agree that we should >>>>>>>> leave the vote open longer and get the wording right. I'll work on >>>>>>>> addressing the new feedbacks. >>>>>>>> >> > >>>>>>>> >>>>>>>> >> > >>>>>>>> Best, >>>>>>>> >> > >>>>>>>> Prashant Singh >>>>>>>> >> > >>>>>>>> >>>>>>>> >> > >>>>>>>> On Fri, Sep 5, 2025 at 8:59 AM Ryan Blue < >>>>>>>> [email protected]> wrote: >>>>>>>> >> > >>>>>>>>> >>>>>>>> >> > >>>>>>>>> I think this is a good addition, but I think it may >>>>>>>> need a bit of work to get the wording right and there's still ongoing >>>>>>>> discussion. Maybe we should leave this vote open longer until the >>>>>>>> discussion settles? >>>>>>>> >> > >>>>>>>>> >>>>>>>> >> > >>>>>>>>> Also, I want to point out that this is another use >>>>>>>> of a specific separator char. I think it would be good to revisit our >>>>>>>> separator discussion and finally close on it. >>>>>>>> >> > >>>>>>>>> >>>>>>>> >> > >>>>>>>>> On Fri, Sep 5, 2025 at 12:33 AM John Zhuge < >>>>>>>> [email protected]> wrote: >>>>>>>> >> > >>>>>>>>>> >>>>>>>> >> > >>>>>>>>>> +1 (non-binding) >>>>>>>> >> > >>>>>>>>>> >>>>>>>> >> > >>>>>>>>>> On Thu, Sep 4, 2025 at 6:23 PM Yufei Gu < >>>>>>>> [email protected]> wrote: >>>>>>>> >> > >>>>>>>>>>> >>>>>>>> >> > >>>>>>>>>>> +1 on the spec change. It’s a solid first step >>>>>>>> toward enabling DEFINER views. As usual, the spec change is >>>>>>>> intentionally >>>>>>>> kept separate from access control. >>>>>>>> >> > >>>>>>>>>>> >>>>>>>> >> > >>>>>>>>>>> Yufei >>>>>>>> >> > >>>>>>>>>>> >>>>>>>> >> > >>>>>>>>>>> >>>>>>>> >> > >>>>>>>>>>> On Wed, Sep 3, 2025 at 8:18 AM huaxin gao < >>>>>>>> [email protected]> wrote: >>>>>>>> >> > >>>>>>>>>>>> >>>>>>>> >> > >>>>>>>>>>>> +1 (non-binding) >>>>>>>> >> > >>>>>>>>>>>> >>>>>>>> >> > >>>>>>>>>>>> On Tue, Sep 2, 2025 at 6:38 PM Prashant Singh < >>>>>>>> [email protected]> wrote: >>>>>>>> >> > >>>>>>>>>>>>> >>>>>>>> >> > >>>>>>>>>>>>> Hi All, >>>>>>>> >> > >>>>>>>>>>>>> I propose adding an optional referenced-by to >>>>>>>> the REST loadTable call, which will contain the fully qualified name >>>>>>>> of the >>>>>>>> view (namespace of the view name and the view name) in case the table >>>>>>>> is >>>>>>>> being referenced by a view. >>>>>>>> >> > >>>>>>>>>>>>> >>>>>>>> >> > >>>>>>>>>>>>> This will be really helpful in a couple of ways : >>>>>>>> >> > >>>>>>>>>>>>> 1. First step towards enabling DEFINER views >>>>>>>> >> > >>>>>>>>>>>>> 2. Audit, incase one wants to track what's the >>>>>>>> base objects accessed from the direct object accessed (example: doc) >>>>>>>> >> > >>>>>>>>>>>>> >>>>>>>> >> > >>>>>>>>>>>>> For details please check: >>>>>>>> >> > >>>>>>>>>>>>> >>>>>>>> >> > >>>>>>>>>>>>> - Spec change PR: >>>>>>>> https://github.com/apache/iceberg/pull/13810 >>>>>>>> >> > >>>>>>>>>>>>> - Reference Implementation PR: >>>>>>>> https://github.com/apache/iceberg/pull/13979 >>>>>>>> >> > >>>>>>>>>>>>> - Discuss Thread: >>>>>>>> https://lists.apache.org/thread/01gb9rygdd1gqks7lnl1o6440qocnh9m >>>>>>>> >> > >>>>>>>>>>>>> >>>>>>>> >> > >>>>>>>>>>>>> Please vote in the next 72 hours: >>>>>>>> >> > >>>>>>>>>>>>> >>>>>>>> >> > >>>>>>>>>>>>> [ ] +1 Add these changes to the spec >>>>>>>> >> > >>>>>>>>>>>>> [ ] +0 >>>>>>>> >> > >>>>>>>>>>>>> [ ] -1 I have questions and/or concerns >>>>>>>> >> > >>>>>>>>>>>>> >>>>>>>> >> > >>>>>>>>>>>>> Best, >>>>>>>> >> > >>>>>>>>>>>>> Prashant Singh >>>>>>>> >> > >>>>>>>>>> >>>>>>>> >> > >>>>>>>>>> >>>>>>>> >> > >>>>>>>>>> >>>>>>>> >> > >>>>>>>>>> -- >>>>>>>> >> > >>>>>>>>>> John Zhuge >>>>>>>> >> > >>>>>>>> >>>>>>>
