---
# System prepended metadata

title: Autonomy Pilot

---

# 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
