These requests specify the kind of information sought and provide the context, clarifying for the owner what specific data needs to be shared.

Example:

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

Imagine Spotify has granted you Private Data Assets (PDAs) containing your listening history.

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 explain the reasons behind this request.

As the user, you are empowered to make an informed choice: either grant them a copy of your Private Data Assets (PDAs) as Proof or keep your data private.

The Data Request will be available for permission on your dashboard even if you do not accept it at that moment.

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

➡️
More about that in the Data Proof section

Request Lifecycle

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

Understand every step of the process:

The Verifier sends a Data Request

Once a verifier selects an appropriate Data Request template (more details below), they can submit a request targeted at a specific owner.

A unique Data Request ID is generated as a secure link between the verifier and owner. It's essential that the owner has an initialized GatewayID; otherwise, the request won't be processed.

The Data Request is stored on Arweave unencrypted but does not surface the target owner of the request.

The request status is initially set to 'Pending, leaving the ball in the owner's court 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.

Visibility + Verifiability

Data Requests are stored unencrypted on Arweave, but each request carries the verifier's digital signature to establish intent clearly.

To further protect privacy, the identity of the data owner remains undisclosed on Arweave, preventing any linkage between an owner's Private Data Assets (PDAs) and their identity.

The Gateway Widget

If your user base isn't widely using digital wallets, or if you're aiming for a more user-friendly experience, we're partnering with select initial test partners to offer the Gateway Widget. This integration lets you present data requests directly to your users without disrupting their in-app experience.

❗️Currently, we are working with select partners to integrate the widget! If this is something you would be interested in, reach out to us [email protected] with the subject "Gateway Widget Test Partner".