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 Dataswyft to set up the correct contracts and connections for its app’s users to accept. Following this acceptance, the connections between the app and PDAs will be automatically enabled by Dataswyft.

Please speak to your Dataswyft account manager who can help you work through the required Transaction Request Form.

Transactions set-up

Transactions set-up is an important function of Dataswyft’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.

Types of Transaction Contracts

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.

Process Steps

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.

Information needed for review

Declarations: For Dataswyft 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 Dataswyft.

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.

How are the transactions governed?

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. Dataswyft logs its details, manages and maintains the HMI Contracts, their versioning, and updates on behalf of the application owners and their users. Dataswyft 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 Dataswyft’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 Dataswyft 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.

Legal implications

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 Dataswyft directly between the app and its users. Without the individual agreeing to these contracts, the app’s access to the PDAs would be illegal. Dataswyft, 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. Dataswyft has an obligation to ensure that apps and even Dataswyft 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 Dataswyft’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. Dataswyft, 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 Dataswyft 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.