How Data Sharing Works

Raytio allows users to share encrypted data without compromising security. This page explains how the sharing system works — from how data is encrypted for a specific recipient, to how multiple team members can access shared submissions.

For an overview of how encryption itself works, see Encryption.

Access Applications and encryption

An Access Application (AA) is a form that a data receiver creates to collect information from data providers. Each Access Application has its own encryption key pair, separate from any user's personal keys:

• The AA's public key is stored on the server and is available to anyone submitting data to that application
• The AA's private key is encrypted with the AA owner's personal public key and stored on the server

When a data provider submits data to an Access Application, the encrypted fields are encrypted using the AA's public key. The data is sent to the server already encrypted — Raytio never sees the unencrypted values.

To read submissions, the AA owner retrieves the AA's encrypted private key, decrypts it using their own personal private key, and then uses the AA's private key to decrypt the submission data. This chain of keys means that only someone who holds both the AA's private key and the personal private key to unlock it can read the submissions.

Data Provider's device
    ↓  encrypts fields with AA's public key
Raytio server (stores encrypted data)
    ↓  AA owner requests submissions
AA owner's device
    ↓  decrypts AA private key using personal private key
    ↓  decrypts submission data using AA private key
Readable data

Sharing Access Application access with team members

The AA owner can grant other users in their organisation access to an Access Application. When this happens, the AA's private key is securely shared with the new user. This entire process happens on the AA owner's device — Raytio's servers never see the AA's private key in unencrypted form:

1. The AA owner's browser retrieves the AA's encrypted private key from the server and decrypts it locally using the owner's personal private key
2. The browser retrieves the new user's personal public key from their account
3. The AA's private key is re-encrypted ("wrapped") using the new user's personal public key — still on the owner's device
4. Only the new encrypted copy is sent to the server and stored, owned by the new user

The result is that each authorised user has their own encrypted copy of the same AA private key. Each copy is encrypted with a different user's personal public key, so each user can only decrypt their own copy.

AA Private Key
    ├── encrypted with Owner's public key    → only Owner can decrypt
    ├── encrypted with User A's public key   → only User A can decrypt
    └── encrypted with User B's public key   → only User B can decrypt

This design means:

• The AA's private key is never transmitted unencrypted — it is always wrapped in a user's public key
• Revoking a user's access removes their encrypted copy of the private key, but does not affect other users
• Adding a new user does not require re-encrypting any submission data — only the AA's private key needs to be wrapped for the new user
• The server never has access to the unencrypted AA private key at any point in this process

Permission levels

When granting access, the AA owner chooses a permission level that controls what the user can do:

Permission	Can view submissions	Can edit the Access Application	Can manage permissions
Views	Yes	No	No
Edits	Yes	Yes	No
Admins	Yes	Yes	Yes

All permission levels grant the ability to decrypt and view submissions. The differences are in what administrative actions the user can perform on the Access Application itself.

For step-by-step instructions on granting access, see Manage Access Application Permissions.

Sharing data between Access Applications (WADEK)

When encrypted data needs to be shared from one Access Application to another — for example, when a data receiver forwards a submission to a third party — the encryption keys must be re-wrapped. This is done using a system called WADEK (Wrapped Application Data Encryption Key).

Each encrypted field in a submission has its own Data Encryption Key (DEK). When sharing between AAs, these DEKs are re-wrapped for the destination AA:

1. The source AA's private key decrypts the original DEK for each encrypted field
2. Each DEK is re-encrypted ("wrapped") using the destination AA's public key, producing a WADEK
3. The WADEKs and the encrypted data are stored for the destination AA
4. The destination AA owner uses their personal private key to unlock the destination AA's private key, then unwraps the WADEKs to obtain the DEKs
5. The DEKs are used to decrypt the shared data

Source AA                          Destination AA
    │                                    │
    ├── DEK (encrypted with              ├── WADEK (DEK re-encrypted
    │   source AA's public key)          │   with destination AA's
    │                                    │   public key)
    │                                    │
    └── submission data                  └── same submission data
        (encrypted with DEK)                 (encrypted with same DEK)

This process ensures:

• The submission data itself is never decrypted on the server — only the DEKs are unwrapped and re-wrapped on the client
• The source and destination AAs maintain independent encryption boundaries
• The original data provider's encryption keys are never revealed to the destination

Why this design matters

Raytio's sharing model is built around a principle: the server should never be able to read shared data. Every sharing operation — whether granting a team member access to an AA or forwarding data to another organisation — is performed client-side using public-key cryptography.

This means that even if Raytio's servers were compromised, an attacker would only find encrypted private keys and encrypted submission data. Without the personal private keys held by individual users, neither the AA private keys nor the submission data can be decrypted.