The Verida protocol offers a lot of flexibility and controls around data access and encryption.
This guide provides a deeper insight on how these tools can be helpful to build powerful and secure decentralized applications on the Verida network.
Sending private data to a user (Incoming data)
Scenario: Your application has personal data about an individual that you want to securely share with them as a once off.
Example: You may generate a contact (name, phone) for a user in a centralized system and wish to securely send the contact to an individual so they can message them in the future.
Assumptions: The personal data being shared is a single record and could be stored anywhere (either in a Verida storage node or a centralized database)
Requesting private data from a user (Data request)
Scenario: A user has personal data about themselves that your applications wants consent to obtain a copy of._
Example: You may request a copy of a drivers license credential from a user._
Assumptions: The personal data is a single record and is stored in a Verida storage node on the Verida network._
- Request a copy of a credential (ie: proof of address, KYC)
- Request a user’s profile / preference record (dietary preferences, contact details, health preferences etc.)
Creating an application data silo (Context data)
Scenario: An application wants to create a secure collection of databases where the data is owned and controlled by the end user
Example: A developer creates a decentralized game and wants to create a custom database of game metadata to store for the user. The game metadata can only be unlocked by the user via a consent sign in message in the Verida Wallet
Assumptions: The data is proprietary to the application and a user is unlikely to want that data to be shared / used by other applications.
Access to this data is typically “unlocked” in real time by sending a Connection Request to the user's Vault request to the user’s Vault, but the data isn’t visible by default in the Verida Wallet.
Sharing access to lots of private data (Data synchronization)
Scenario: A user has a lot of personal data stored in their Verida Wallet that your application wants consent to securely read and write.
Example: You may operate a medical practice that stores a patient's medical records and you wish to regularly read and write the patient’s medical data.
Documentation examples will be coming shortly.
- A medical practitioner can synchronize a patient’s last 6 months of health records
- A decentralized advertising network can request read only access to a live stream of a user’s social media posts and personal preferences
- A user can update their phone number and it will be automatically updated with all third party applications that have synchronized access to the user’s private profile
An example of this is coming soon in the Verida Tutorial.
Data synchronization options
There is a lot of flexibility in how this data synchronization is configured. An application can request access to:
- A read and / or write stream of all data of a particular type
- Once off data synchronization
- Permanent sync (until the user disables)
- A filtered stream of data based on a query