Thanks all for your feedback. Hi Arnav, The current convention for the REST server implementation is to throw a `NotImplementedException` if a specific method has not been implemented. I believe this is something users can clearly accept.
Best, Jingsong On Mon, Aug 24, 2026 at 7:32 PM Arnav Balyan <[email protected]> wrote: > > Hi Jingsong, > Thank you for raising this thread, having a unified security layer would be > incredibly helpful for clients attempting to standardize permission > management and allow organizations to implement their own governance and > compliance. > > My thoughts on the proposal are: > 1. I support defining this contract as part of rest catalog. Standardizing > the transport would allow the clients to avoid vendor specific SDKs. > 2. Exposing this capability through the rest catalog can keep policies > unified across individual catalogs and may help avoid maintenance overhead. > 3. I support keeping it as an OpenAPI contract to allow a clear distinction > between catalog operations vs admin operations. > 4. To maintain interoperability, maybe the spec could define a > `supportedCapabilities` to indicate the server specific capabilities to map > the endpoint shapes to the proposed model. > 5. I support having Spark procedures as a reasonable SQL integration. > > Thank you for initiating this discussion and this new direction. I would be > happy to support with testing/implementation. > > Warm Regards, > Arnav > > On Mon, Aug 24, 2026 at 4:42 PM Dapeng Sun <[email protected]> wrote: > > > Hi Jingsong, > > > > Thanks for driving this. +1 on the overall direction. > > > > A few thoughts on the design: > > > > - Keep the first version flat and simple. > > - Leave room to extend resource fields in the future. > > - Keep the management API separate from the core catalog API. > > - It may also be worth considering behaviors such as owner permission and > > grant option in the detailed design. > > > > The proposed REST APIs and Spark procedures look like a good starting > > point. > > > > Best, > > Dapeng > > > > yijie shao <[email protected]> 于2026年8月24日周一 18:53写道： > > > > > Hi Jingsong, > > > > > > +1 from me. > > > > > > I support introducing a language-neutral permission management contract > > for > > > the REST Catalog ecosystem. Keeping it scoped to `RESTCatalog` looks > > like a > > > reasonable initial boundary, and the proposed APIs and Spark procedures > > > seem like a practical starting point. > > > > > > Thanks for driving this discussion and preparing the POC. > > > > > > Best, > > > Yijie Shao > > > > > > Jiajia Li <[email protected]> 于2026年8月24日周一 18:46写道： > > > > > > > Hi Jingsong, > > > > +1 for defining this contract as part of the REST Catalog ecosystem. > > We > > > > run a production Paimon REST Catalog server and very much need a > > neutral > > > > permission management contract like this — it is exactly what engine > > > > integrations and tools need as well. The proposed model and boundaries > > > look > > > > right to me. > > > > Best, > > > > Jiajia > > > > ------------------------------------------------------------------ > > > > From:Jingsong Li <[email protected]> > > > > Send Time:Mon, Aug 24, 2026, 18:21 > > > > To:dev<[email protected]> > > > > Subject:[DISCUSS] Introduce REST permission management APIs > > > > Hi community, > > > > I'd like to discuss introducing a language-neutral permission > > > > management contract for Paimon's REST Catalog support. > > > > RESTCatalog is becoming the common catalog interface across engines > > > > and services. Authentication and authorization decisions should remain > > > > responsibilities of the REST server, but clients still need an > > > > interoperable way to list, grant, and revoke permissions without > > > > depending on a vendor-specific SDK. > > > > I prepared a POC in the following draft PR: > > > > https://github.com/apache/paimon/pull/9377 < > > > > https://github.com/apache/paimon/pull/9377 > > > > > The current proposal has the following boundaries: > > > > - Add a small PermissionManagement contract with list, grant, and > > > > revoke operations. > > > > - Expose PermissionManagement directly from RESTCatalog instead of > > > > changing the generic Catalog interface. Other catalog implementations > > > > are therefore not required to support it. > > > > - Make the corresponding RESTApi methods public so Java clients and > > > > engine integrations can use the same transport contract. > > > > - Define a separate rest-management-open-api.yaml with these endpoints: > > > > - GET /v1/catalogs/{catalog}/permissions > > > > - POST /v1/catalogs/{catalog}/permissions/grant > > > > - POST /v1/catalogs/{catalog}/permissions/revoke > > > > - Use a flat resource-oriented permission model covering catalog, > > > > database, table, view, function, column, row filter, and column > > > > masking permissions, with optional expiration. > > > > - Keep user and role lifecycle, authentication, policy persistence, > > > > and authorization enforcement outside this API and under the > > > > responsibility of the REST server implementation. > > > > - Initially expose the capability to Spark SQL through > > > > grant_permission, list_permissions, and revoke_permission procedures. > > > > Future GRANT/REVOKE SQL syntax could be layered on the same Java and > > > > REST contracts without changing the server API. > > > > I would appreciate feedback on the following questions: > > > > 1. Should Paimon define this permission management contract as part of > > > > its REST Catalog ecosystem? > > > > 2. Is exposing it only through RESTCatalog the right initial boundary, > > > > or should it be modeled as a generic Catalog capability? > > > > 3. Should the management OpenAPI contract remain separate from > > > > rest-catalog-open-api.yaml? > > > > 4. Are the proposed resource model and endpoint shapes suitable for > > > > different REST Catalog server implementations? > > > > 5. Are Spark procedures a reasonable first SQL integration, while > > > > leaving dedicated permission SQL syntax for a follow-up? > > > > The PR is intended as a POC for discussion, and I am happy to adjust > > > > the design based on community feedback. > > > > Best, > > > > Jingsong > > > > > > > > >
