## 3 Cloud-Agnostic Models
### Cloud Interoperability  
Establishing a proper authentication mechanism is usually the very first step towards achieving interoperability with cloud providers. In Figure 2, we represent the entities and respective attributes that model the authentication mechanism based on the OAuth 2.0 protocol.  
This protocol is commonly used by different types of applications to authenticate users in various platforms, so developers can easily find documentation on how to adapt this model to their provider of choice. The trust relationship between the tool and the provider's identity platform is established once the developer registers it as an application in the respective cloud provider. This trust is unidirectional, the application trusts the provider identity platform, and not the other way around.  
After registration, a client ID and a client secret are randomly generated (_clientId_ and _clientSecret_ attributes from _CLOUDAUTH_ entity). Trying to obfuscate client secrets in installed applications is one of the main challenges in adopting this protocol, since they can be always recovered using the abundance of reverse engineering and debugging tools [39].  
With OAuth 2.0, an application can request one or more scopes (_SCOPE_ entity), and this information is also presented in the consent screen during the user authentication  
Figure 2: Authentication mechanism ERM.  
process. Once the user is successfully authenticated, an access token is requested and issued to the application (_accessToken_ attribute from _SESSION_ entity) using a specific token URL (_tokenUrl_ attribute from _CLOULOULITH_ entity). The extent of the application's access is limited by the scopes granted. Access tokens normally last for about an hour in both GCP and MsAzure [40; 41].  
Facilitating cloud service deployments to multiple providers helps in managing multi-cloud complexity, thus contributing to cloud interoperability. Considering that this work focuses on characterizing interoperability to FaaS platforms, Figure 3 only illustrates cloud entities that participate in the deployment of a FaaS application.  
Usually, a function needs to be linked to a storage resource. We adopted the same naming terminology from AWS and GCP by calling it a bucket (_BUCKET_ entity). These buckets can have various purposes: storing every version of the function's source code, storing execution logs, etc. The user must have at least one bucket created before being able to deploy the FaaS resource to a certain location (_location_ attribute from _FUNCTION_ entity). A location is wherever the resource resides, preferably as close as possible to the end user. As for the _entryPoint_ attribute, from the _FUNCTION_ entity, it specifies the entry point to the FaaS resource in the source code. This is the code that will be executed when the function runs. A project (_PROJECT_ entity) is simply a holder for various types of resources from different cloud services.  
When adopting this model, developers have to consider the differences in naming terminologies for services and resources. For instance, in MsAzure, a _PROJECT_ corresponds to a _resource group_, a _FUNCTION_ to a _function app_, and a _BUCKET_ to a _container_ associated with a _storage account_.