Data Requests

Consuming User Data

Data Requestors can obtain information from users by sending a direct Data Request to them. These requests specify the kind of information sought and provide the context, clarifying for the owner what specific data needs to be shared.

The Gateway Protocol is enhancing its framework to include a variety of request types, tailored to meet diverse privacy and data handling needs of Data Requestors. This includes:

1. Asking for Copies: Enables requestors to obtain unencrypted copies of specific data from Personal Data Accounts (PDAs) for asynchronous analysis, compliance, or profile building.
2. One Time Read: Allows for a single, real-time access to unencrypted user data in PDAs, ideal for immediate processing or validation, with no further access thereafter.
3. Conditional Verification: Facilitates the verification of certain criteria within PDAs, such as age verification, based on predefined conditions, with Zero-Knowledge (ZK) proof enhancements planned.
4. Blind Computation (In Development): Explores secure computation methods on encrypted data, preserving user privacy without decryption.

These advancements aim to balance user privacy with the practical needs of data utilization, signaling a forward-thinking approach to data consent and access.

Example:

Let’s bring Data Requests to life with a real-world example.

Imagine Spotify has contributed your listening history as a PDA on the network.

Now, Ticketmaster sees an opportunity: they want to offer you tailored concert recommendations, exclusive discounts, and even early ticket access. So, when you visit their site, Ticketmaster sends a Data Request for your Spotify PDAs to curate an experience as individual as your playlists.

A Data Request surfaced to you on the interface could look like:

Ticketmaster will clearly outline the specific data they wish to access and the type of request this is. This will also surface the reasons behind this request and what the data will be used for.

As the user, you are empowered to make an informed choice: either grant them a copy of your data or keep your data private.

If you accept, a Data Proof, a secure and verifiable snapshot of the requested information, is generated and sent.

---

Request Lifecycle

Data requests are exclusively exchanged between the Owner and the Requestor. The Request’s lifecycle depends on the Owner’s response or lack thereof.

The Requestor sends a Data Request

Once a Requestor delineates a Request type, the specific Request, and the ID the request is intended for, the validators verify the request structure. They post the request ID on the ledger and the request contents are forwarded to the target.

The request status is initially set to Pending, leaving it up to the owner to accept or decline the inquiry.

mutation {
	createDataRequest(input: {
		dataRequestTemplateId: "35188207-b5b9-4cd8-a44d-0e82d4ee359a",
		owner: "c9a8dfc8-a423-4a92-9b43-90c50f6ff15c"
	}) {
		arweaveUrl,
		id,
		status
	}
}

A mutation sample for the request

Acceptance: Owner Accepts the Request

The owner will encounter the request through the interface they’re currently using, whether it’s a widget, a wallet interface, or a dashboard.

This request will explicitly highlight what data the verifier is interested in and how they intend to use it.

If the owner feels comfortable sharing this information, they can approve the request, generating a Data Proof for the verifier.

Reject: Owner Rejects the Request

If the owner sees the request and is uncomfortable/uninterested, they can reject it.

The request status would be changed to “Rejected,” and the Request would not be closed.

No Data Proof would be generated, and the verifier would see this as a “Rejected” request on their dashboard.

Expired: Owner Does Not Take Action

If the owner does not explicitly choose to accept or reject, the Data Request will be marked as “Expired” after 3 days of no action. This Request is now closed.

---

Request structure

1. Data Request Template ID

Each Data Request is inherently linked to its originating Template ID, streamlining the process of filtering, indexing, and identifying the most frequently used templates.

2. ID

Each Data Request has an associated UUID that is unique between the owner requesting the information and the verifier asking.

No two Requests will ever share the same DR ID.

3. Requested Data

As a verifier, the data you request hinges on the Data Request Template you’ve selected. Make sure to choose a template ID that aligns precisely with your needs to ensure the information you receive is both relevant and useful.

4. Data Use

Verifiers are required to specify the intended use of the requested data.

This transparency is crucial, enabling the owner to fully grasp the implications and potential benefits of granting permission.

5. Status

Every Data Request carries a specific status that dictates the actions an owner can take, as previously outlined. For a quick refresher, consult the table below:

Managing Requests

Users and Organizations can see and control their requests from the Gateway Dashboard.