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