permissions for user-managed tables

[pdowler]

The range of implementations allowed by the create/update/drop table API means that permissions need to be handled carefully and be fully optional.

In addition, the two payload formats that can be used to create or update a table do not have a clear mechanism to carry along permission-related info.

minimally, if table ownership and permissions are explicitly managed and exposed by a service (eg CANFAR youcat), the minimal and I think viable set of items is:

• owner
• boolean flag to indicate anon query is allowed
• a group that is allowed to read (GMS group URI)
• a group that is allowed to write

All of these need to optional and an implementation could completely ignore this and be compliant. But to write a client that can make use of different services that do care about permissions, we need some agreed mechanism to convey the permissions to the client and for the client to set the permissions.

[pdowler]

I think there are roughly 3 kinds of solutions that are straightforward/viable to describe in OpenAPI:

1. augment the table description payload to include optional permissions information; there are two formats already, neither are only used here (so no native metadata structure): not practical
2. additional endpoint with a document style payload that expresses permissions; kind of like other systems where you use other tools to view/set permissions (chmod and get/setfacl in filesystem, grant in SQL, etc)
3. custom http headers could convey info the service wants to expose and request headers could be used to set permissions during create/update
4. another option?

[pdowler]

Draft proposal for doing this with HTTP headers: #10