# Autonomy Pilot

# Some ideas for system structure
​
This is a very simple implementation to provide a level of access
control.
​
## List of components and basic connection
​
* Personal Data Store (PDS)
* Group Data Store (GDS)
* Agent
* API
* Client
​
​
~~~
.-----------------------------------.
| |
| .---------------. |
_.-----._ | | | |
.- -. | | | |
|-_ _-| ____ | |
| ~-----~ |----->|====|AGENT | |
| REDCap | | | | |
`._ _.' | | v v
"-----" |____| ____ ____
|====| PDS |====| GDS
| | | |
| | | |
|____| |____|
^ ^
'-----. .---------'
| |
| |
____
____ |====| API
| |--------------------------->| |
|____| | |
/::::/ |____|
​
CLIENT
~~~
​
​
## Data Stores
​
* stores individual data items
* supports multiple users
* access controlled by macaroons (e.g., read, write, update,
add-new-item)
* *group stores* only have aggregations i.e., data updates simply
add/average the daily samples
​
### Outline of Registration Process
​
1. Client sends Bitmark Account as part of registration request
2. PDS replies with timestamp/NONCE
3. Client signs with Bitmark Private Key and sends signature
4. PDS replies "root" macaroons to correctly signed request
a. Read macaroon (to pass to API for access)
b. Write macaroon (used for updating records)
c. Add new data items (used for Agent access)
​
### Notes
​
1. "root" macaroon only has location + ID + access rights, i.e., no caveats.
2. client will add appropriate caveats before sending to service to protect "root" macaroon.
3. at least a "time < _ISO8601_" caveat will be implemented in each
service (the client will use Now()+Minutes(5) or similar to create
the caveat, for each new API usage)
4. registration process can work for re-registration and data server
needs only create and files/databases if that Bitmark Account was
not seen before.
​
### Problems
​
1. The above process does not prevent creating multiple accounts since
any registration access token must be present in the web app and
could easily be extracted.
2. Encryption of the data in the services is not addressed here.
​
## Agent
​
* this is a proxy for the distributed App (since we only have web app)
* also this will likely be the only authorised system that can connect
to data collector
* it forms a proxy for the clients that can do polling of the data
from the DB and transmission to the data stores
​
### How Agent would use macaroons
​
1. The client would register with Bitmark Account and The ID in the
REDCap system
2. I the registration is successful provide PDS and GDS access
macaroons. Possibly with caveats
* a time limit for the duration of the access e.g., 6 months (to
have some expiration) (**required**)
* an IP restriction to the current Agents public IPs (so macaroon
cannot be used by other servers)
* rate limits would also be possible e.g., if the PDS/GDS implemented
per min/hour/day type of limits
* total access could also be implemented in PDS/GDS
3. When using a macaroon the Agent would add a "time < Now+5min" for each access
​
### Macaroon types
​
Initially PDS/GDS would both be write for ease of implementation, but
could later be changed to more specific like "add new record" or
"aggregate data" to provide finer access restrictions.
​
## Client
​
* locally stores Bitmark Account/Secret
* locally stores registration ("root" macaroons)
* All API access attached with time limited macaroon of the correct
access level
* client must register directly to PDS and GDS and prove that it
holds Secret in order to obtain "root" macaroon, i.e., *not* via API
or API could capture "root" macaroons and obtain unlimited access
* client must give extended time access macaroons to Agent for it to
fetch data
* all API accesses that require access to data store must be supplied
with a more restrictive macaroon that the API can use to get real
access
* not considering encrypted data at this time