Table permissions

[pdowler]

Possible solution using HTTP headers to convey minimal permission related information.
For issue #8 this is option 3.

As optional headers, any service can ignore request headers they do not support and only include response headers they do support.

This adds 3 optional headers that can be included in:
PUT /tables/{name} -- set permissions during create table op
POST /tables/{name} -- set permissions on an existing table
GET /tables/{name} -- headers will describe the current permissions

The 3 headers are: x-vosi-anon-read, x-vosi-group-read, x-vosi-group-write.

In addition, a 4th header specifies the owner of the table: x-vosi-owner and is only used in output from the service (GET requests).

Detail to be described in the standard document: a lack of x-vosi-owner header can be interpretted as "this is a normal table"... maybe we also specify that a missing x-anon-read header means the same thing as true: this is a normal table anyone can query?

pros:

• headers can be used by the client to change permissions and the server to output the current permissions independent of the document format; this is much simpler that modifying VOSI-table schema or making up an ad-hoc way to encode this info in VOTable
• it is easy for services that do not implement user-managed permissions to ignore incoming headers and never send any for GET requests

cons:

• as noted above in "details", we need to specify how a client can tell that a service does not accept/support user-managed permissions... need to prototype to see

[pdowler]

If headers prove to a good/acceptable way to get and set permissions, this may also be a suitable approach to manage other optional attributes.
eg. lifetime of tables that are longer-lived than TAP upload tables but not permanent
TBD

[brianmajor]

Our other (minimal) use of headers, though not part of any spec at the moment, is for communicating your authentication status. If I call a service with my credentials I see

x-vo-authenticated: bmajor

Should we strive for a convention where IVOA headers start with x-vo-?

[Zarquan]

Should we strive for a convention where IVOA headers start with x-vo-?

I think this is a good idea, but we should use x-ivoa rather than just x-vo
The term vo has many different meanings.

If someone outside our community notices these odd headers being sent to their service they might try to use a search engine to find out where they are coming from. Putting ivoa into a search gets better results than vo.