# Autonomy System Architecture (Health)

###### tags: `Autonomy` `Autonomy Health`

## List of components

* Personal Data Store (PDS)
* Community Data Store (CDS)
* UCB Agent
* Autonomy API Server
* Client

### PDS

* stores individual data items
* can be implemented either locally or on clouds
- local: stores data on individual's phones
- cloud: the cloud service can host stores for multiple users, and the access to each PDS is controlled by macaroons (see [Access Control](https://hackmd.io/KpY0YzP0Sb2817XMMKN54A?both#Access-Control))

### CDS

* only have aggregations i.e., data updates simply add/average the daily samples
* can sit on cloud or UCB's site

### UCB Agent

* managed by UCB faculty who has the access to symptom data
* aggregates collected symptom data and sends the results to the Autonomy API server

### Client

* locally stores Bitmark account and secrets
* locally stores bearer tokens for operating data stores

## Access Control

PDS and CDS handle access control by [macaroons](https://research.google/pubs/pub41892/). Macaroons are bearer credentials, but can also embed caveats that attenuate and contextually confine when, where, by who, and for what purpose a target service should authorize requests.

The client will get "root" macaroons after the registration process, i.e., no caveats embedded, and should add appropriate caveats before sending it to another service to protect the "root" macaroon. For example, the caveat `time < _ISO8601_` will specify when the token will be expired.

For anyone who wants to use data stores, they have to get the attenuated credential delegated by participants or finish the registration process to get the root macaroon tokens.

## Sequence Diagram


## Notes

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.