Types of Services
1- vs. many-party, stateful vs. stateless, and trust.
Before designing a service, you should know what type of application you build and why. In understanding the kind of application you are making, you will readily be able to answer questions about how clients should connect to the service, how you can scale the service, and so on. We will use the below terminology throughout the following chapters, so understanding them now will be beneficial.
APIs or Scripts
The first and most simple question is whether your service is intended to launch, run a script and terminate, or whether it serves an API and should wait for requests to respond to. Once the script executes, the service itself will tear itself down. For APIs, persistency is the assumed desirable quality, and as such, the service manager will keep the server alive until the service is manually torn down.
1- vs. Multi-Party Applications
There are, of course, many scenarios in which you may wish to deploy an enclave to broker trust. The number of parties can be a distinguishing feature. In particular, common scenarios include:
1-Party Enclave Use
In the context of 1-party computation, the developer of the API is also the client. This may be the case if you possess very sensitive data and would like to control and monitor the exact software used to process that information. The enclave's attestation process is used to retrieve keys from a key management server while guaranteeing not only the role of a particular server but instead, the actual code base and environment variables used to create the server.
ACL-Based Multi-Party Enclave Use
Access control list (ACL) based multi-party enclave use is when multiple clients interact via a shared enclave. In such a setting, each party knows about the other parties interacting via the service and the source code of the application running in the service. The attestation process enables this collaboration as the interaction is transparent and can be validated individually. Access control lists are used to manage how each party can interact in the service, what API handles they can call on and how we authenticate and authorize clients.
Extremely Multi-Party Enclave Use
Extremely multi-party enclaves describe enclaves that interact with an undetermined number of users. This may be the case if, for example, an API is provided to a large user base. Users typically interact with the API with a consistent interface and a third-party service (e.g., an OAuth server) that authorizes clients. Clients usually do not know about one another, but they desire to interact with the API provider. This may be the scenario when a SaaS provider offers an API but wishes to be transparent about how client data is and is not used.
Stateful vs. Stateless Applications
The second distinguishing feature to describe an application is whether it needs to remember something between client API calls. If the service needs to store information, we refer to it as "stateful", as the state of the service (memory of the system) changes based on API calls or some external input. Stateless is the opposite of stateful and interact with client API calls in an atomic manner.
The trust model, explained in more detail in the security section, is an important aspect of service. Essentially the trust model describes how much responsibility is given mechanisms internal to the enclave. For example, in specific 1-party scenarios, the use of enclaves is merely to mitigate the risks of sensitive data accidentally winding up in log files or having guarantees that an engineer accidentally sees sensitive information when logging into a server for the sake of troubleshooting. This assumes parties are "honest-but-curious." which is highly different from a "malicious" scenario where parties are actively trying to find ways to extract information about one another without their consent.