Permission Review
Transaction Request Form
Transactions relate to your application’s access to read from and write data into PDAs.
When an organisation submits an application for review, it is asking for Dataswift to set up the correct contracts for its app’s users to accept. Following this acceptance, access and usage to PDAs will be automatically enabled by Dataswift.
Please speak to your Dataswift account manager who can help you work through the required Transaction Request Form.
Transactions set-up is an important function of Dataswift’s stewardship of the server owner’s data. Apps can only read and write data for which they have obtained permissions through contract, and only when permissions are confirmed will the APIs for a server owner's PDA be enabled to store and receive data.
There are four types of transaction contracts:
Contract 1 - App Namespace Permissions: Every app that’s integrating with decentralized data servers (DDS) is a “tenant” within the server owner’s database. The app owner would require permission to CRUD (Create/Read/Update/Delete) access into its own namespace (we often call this namespace data account). When filling out the Contract 1 Transaction Request Form, application owners need to provide the data attributes their app will be collecting and storing into their namespace, along with its purpose.
Type of permission: The right for CRUD access into the app’s namespace
Contract 2 - Other Namespace Permissions: This contract provides permissions for an app to READ data in a namespace other than its own (e.g. Facebook). When filling out the Contract 2 Permissions Request Form, application owners need to provide the data attributes their app will be requesting from other namespaces, along with its purpose and duration. This permission is often tied to a Data Pass.
Type of permission: The right to read data from other namespaces on the PDA. Note: reading data from other namespaces requires a technical process called a data debit.
Contract 3 - Tool Processing Permissions:
This contract provides permissions for an app to have CRUD access and PROCESS data through a PDA Function (aka SHE function) that processes data within a PDA and outputs new data into the SHE Function namespace within the server database. In filling out the Contract 3 Permissions Request Form, application owners need to provide information about the data that is used by their function.
Type of permission: The right for a tool or function to have CRUD access and PROCESS data within a PDA and output/write new data into the SHE Function namespace within the PDA
Contract 4- Data Plug permissions:
This contract provides permissions for a data plug to WRITE data into a namespace. Data plugs are special data connectors that bring data in from open APIs.
Type of permission: The right for the data plug to WRITE data into a permitted legal entity namespace (eg Facebook namespace for Facebook data) in the PDA.
STEP 1: Fill in and sign the Transaction Request Form (this is available within the Developer Portal).
STEP 2: Go through App Review
To prepare for this review process, application owners will need to run through the checklist for putting their app through review.
Declarations: For Dataswift to set up the data contracts for the permissions between the application owner and app users, the app owner needs to make several declarations, as listed in this section of the Transaction Request Form. Should these declarations change once the app is live, the app owner would need to update and submit. This may or may not trigger another app review depending on the risk scoring conducted by Dataswift.
Standard information: Application owners need to provide information about their applications and tools so that this can be clearly displayed to the PDA users on their PDA dashboard.
Application for transaction contracts: Providing the necessary information to apply for any one of the different types of contracts (see above).
Data conduct for personal data collection, storage, processing and sharing: Application owners will need to make a declaration of how their app handles personal data; ie the flow of data, where and how it's collected, where it is stored, when/where/how and what is processed and what/when/how it is shared and with whom.
When an app is live, contracts (internally called HMI Contracts) will be logged on the platform when users register or login to the application and accept the contract. Dataswift logs its details, manages and maintains the HMI Contracts, their versioning, and updates on behalf of the application owners and their users. Dataswift monitors the applications’ compliance with their obligations under the Agreement, including necessary audits, under the oversight of the HAT Community Foundation (HCF).
Contracts are checked by Dataswift’s Performance and Monitoring committee to ensure apps behave in accordance with regulatory rules (e.g. imposed by HCF) or other rules that may be introduced by the HCF or Dataswift when data regulations change. Apps have the right to appeal to the HCF if they feel they have been unfairly treated.
Data flows between the app and PDA will be automatically enabled once the permissions are given by users in the live environment.
Unlike “consent” where individuals consent to data being moved from one place to another, PDAs are part of a server database that's legally owned by individuals. Transactions are therefore a result of legal contracts set up by Dataswift directly between the app and its users. Without the individual agreeing to these contracts, the app’s access to the PDAs would be illegal. Dataswift, as the steward of the infrastructure, has to ensure that any access must have the correct permissions and the individual must not have revoked the permissions.
The legal aspect of the platform is about a contractual relationship with server owners and their intellectual property rights, and their obligations as data controllers and data processors. Dataswift has an obligation to ensure that apps and even Dataswift ourselves do not encroach on the individuals’ rights under the law.
The governance aspect of the platform is about stewardship and ensuring that everyone plays by the same set of rules. The rating of all applications sits within governance, as does the risk assessment of applications that wish to go live. Governance also has to manage the HCF’s oversight of Dataswift’s decision on whether or not to allow certain contracts/permissions to be set up.
Here's a simple example to help you understand governance and legal: if an application wishes to set up a contract to ask for ALL the data within the server (across all PDAs), this is legally permissible. Dataswift, as a pure commercial entity, can set up the contract for both parties (ie. the app and the server owner) to agree and for the server owner to transfer all its data to the application. However, this would exceed risk thresholds and therefore trigger a red flag under the risk assessment for contract set-up. Application owners should know that Dataswift has no discretion with contract set-up, and would deal with it objectively under the strict oversight of the HCF. Application owners can appeal to the HCF if a transaction request is denied.
Last modified 1mo ago