...
- what requirements have/have not been met by a User (e.g. whether a EULA has been signed)
Things the client SHOULD 'know'
- how to determine, from an entity's schema and from the repository authorization services, that a permission is needed to - whether it can access a certain field of a certain entity. (The alternatives are (1) to add a service to do this or (2) to do it automatically and return the information with the response (e.g. in the response header). We particularly want to avoid (2) because of the computational burden that might not be necessary.)
Things the client SHOULD 'know'
- how to fulfill a requirement (e.g. if a EULA needs to be signed, knows how to retrieve and display the EULA, get it signed, and submit the appropriate request to the repo service)
Design Approach
Field access service
- Given an entity, find out what access on what fields the user has
The permission service
- Add a new 'permission' service which (1) grants permissions if requirements are met or (2) otherwise reports what requirements need to be met. E.g. POST /layer/101/permission/Download, where '101' is an entity ID, would either (1) grant the requested permission (Download) if the user meets the requirements or (2) return a (401) response with a body of the form
...