search

HumanDynamics / openPDS-RegistryServer

openpds.media.mit.edu
MIT License
11 stars 15 forks source link

First commit on the Cogito branch with a few modifications including a g... #1

Closed newgrounds closed 11 years ago

newgrounds commented 11 years ago

...eneric connector.

newgrounds commented 11 years ago

I recommend creating a Cogito branch of your own.

brian717 commented 11 years ago

I'm not sure a generic connector is where we want to move at this moment... We currently envision permissions based on scopes assigned to different types of resources, with one set of scopes assigned to each resource. For example, the funf connector might have "funf_get" and "funf_write" assigned to GET and POST methods. In this manner, the resources are descriptive of the type of data contained within them, and a scope describes the type of access allowed on that data. A generic connector as it is implemented here sort of goes against that - a place where a generic type of data could be posted may provide access that is too broad in the "single scope per resource+method" model. However, if we dynamically assign scopes for resources and take the "key" for the data into account, this can definitely be done, but that would require quite a bit of reworking before we include it in the main branch.

newgrounds commented 11 years ago

I can merge changes from this repo into mine instead of the other way around if that works better for you.

I don't think having a scope per type of file, or resource, is specific enough in the long run. We just wanted a temporary solution, which I don't believe is necessary any more.

Different applications will need to read or write data to a PDS with different scopes.

Imagine a scenario where two different applications are both posting db files to a single user's PDS. Both applications shouldn't have access to all db files if given a "db_get" scope.

I guess what I'm saying is we envision defining scopes based on who's using the data and not on the data itself.

brian717 commented 11 years ago

I see what you're getting at. However, our current vision is just that - for access to resources based on the type of data, so any client having access to a particular type of data (say, funf, for instance) will have access to all of that data. Restrictions at this level (for example, by the time or location of data samples), would more than likely be done at the trust wrapper level than at the scope level. Additionally, we also envision no access to raw data after it is posted - the fact that the funf resource handles get requests is just for debugging purposes. We built the system with the concept of answers to questions about your data in mind, rather than just a means of retrieving the raw data. In this manner, the answer and answerlist resources are a bit more flexible - they should be taking the key for the data into account for the scope. Answers stored in these lists are currently calculated and stored via trusted (pre-approved) code running on the PDS itself, so they don't go through the standard OAuth flow. In the future, when it's not possible to pre-approve all code, this may need to be rethought a bit, but for the purposes of a single entity writing all of the code, this is currently the best way to do it.