Integrating Pluto’s Web Proofs SDK

This short guide will walk you through an overview of the integration process for the Web Proofs SDK.

The SDK gives applications developers a simple way to work with verified web data without compromising user privacy.

Any internet data — like data that comes from Uber, Amazon, financial institutions, attested sensors, e-mails, Spotify, or any other internet server — can be integrated into any application using the Web Proofs SDK.

Easiest Way To Get Started

ℹ️ The default option for generating Web Proofs is to use the Pluto-hosted notary. Developers do not need to set up the prover or host it themselves, unless they explicitly want to self-host this infrastructure or build custom infrastructure. For more information, see the detailed documentation using the JavaScript SDK.

The fastest way to get started is with our examples repository. You can get started by running:

git clone https://github.com/pluto/web-proofs-examples.git
cd web-proofs-examples
npm install
npm run vanilla

These commands will serve a web page with a QR code. Scanning the QR code on this web page will generate a proof on your mobile device of your Reddit Karma. There are two primary methods for generating Web Proofs using Pluto (mobile app or Chrome extension).

• To generate attestations with a mobile device, you will need the Pluto Attest mobile app.
• To generate attestations in the browser, you will need to download the Pluto Attest Chrome extension (Coming soon).

Building Great User Experiences with Web Proofs

In your application flow, you’ll prompt a user to create a Web Proof.

The user will be taking a piece of their Web2 data — either authenticated data, like their personal bank balance, or public data, like their Reddit karma history — and making attestations against the data.

Your application can verify those attestations — either onchain using Pluto’s smart contract verifier, or server-side if you choose — and then conditionally update the state (either onchain or elsewhere) of your application, based on those verified attestations.

Today, Web Proofs require that a user install an application to generate a proof. This comes as either a mobile (iOS) or Chrome extension.

In the immediate future, we will offer slimmer versions via App Clips and iFrames in the browser. These updates will mean that no user installation will be needed at all (think Plaid or Stripe). These updates will be available before mainnet launch.

Performance Characteristics

We believe that the most important component of the Web Proofs user experience is latency, which is why we have a Trusted Execution Environments (TEE) Mode that delivers Web Proofs in less than 3 seconds. We also believe in optionality for developers and for their users.

The different Web Proofs modes have different trust assumptions, so we expose all 3 modes for developers to choose from.

• TEE mode, which is fastest and relies on TEEs, will generate a Web Proof in less than 3 seconds.
• Proxy mode, which utilizes folded ZKPs, will generate a Web Proof on mobile in less than 20 seconds; however, in the browser environment, this local proving can be prohibitively slow. We recommend the mobile flow.
• MPC mode, which utilizes a TLSNotary implementation, which will be the slowest of the modes on mobile and in browser.

Clearly, all 3 modes come with different performance characteristics, which we will continue to improve on.

In the meantime, if you want blazing fast Web Proofs, TEE mode is your best choice.

Application Flow Examples

Social Application:

A common pattern seen in onchain social is ‘token-gating’, where only holders of a specific token are allowed to enter a group chat or other shared digital space. With Web Proofs, this pattern could be expanded wider, creating groups of people that share a much broader range of attributes than ‘hold the same token’.

By integrating the Pluto SDK, onchain social could create attribute-gated areas for ‘people who have over 100 Reddit Karma’, ‘people who have contributed to one of the Ethereum client Github repositories’, or ‘people who have over a 4.9 Uber rating’.

The application flow would be:

• User opens up the social web app or mobile app
• User chooses community to enter (‘Ethereum client developers’ or ‘top Uber ratings’)
• Application prompts the User to begin the Web Proof flow to gain access to that community
• User authenticates into Github, Uber, or any other target server, as needed; a Web Proof is created
• Application verifies Web Proof’s authenticity and unlocks access for the User

Rebates For Defi Power Users:

A DEX might want to offer discounts to users who can demonstrate that they are high-volume users on another exchange, like Coinbase or Binance.

With Web Proofs, the DEX could provide a discount on fees for these users. By simply proving their trading volume in recent months, the DEX could acquire customers that would otherwise be using a different trading venue, and users could unlock lower fees on those trades.

The application flow would be:

• User enters the DEX web app or mobile app, and sees a call-out on the frontend for ‘Lower fees for high-volume traders’
• User clicks to claim the discount
• Application prompts User to begin Web Proof flow to verify their trading volume on Coinbase
• User authenticates into their Coinbase account, and a Web Proof is created showing their trading volume in the last month
• Application verifies Web Proof and automatically applies trading fee discount to the User’s account on the DEX for the next month

Necessary Technical Details

Below, we describe many of the important technical details relevant to integrating Web Proofs into your application.

Verification of Web Proofs

Each of the different modes will output a proof that can then be verified externally.

In the case of the proxy, the client-side generated proof will be returned back to the proxy for verification and the proxy will sign the relevant data if the proof was valid. This signed data can be verified onchain. In this case, it is worth pointing out that the proxy is already a semi-trusted entity in this process and this adds no new trust assumption. It merely makes the onchain verification far cheaper.

TEEs have their own built-in signing keys, which can be used to sign a valid proof that they compute internally. Similar to the proxy flow, a TEE will sign valid data and this signature can be verified later onchain.

In the case of MPC mode, the proof that is output from the notarization process can be verified directly onchain.

We are building towards richer verification in the immediate future. For instance, if a Web Proof is created, we want to assure that that proof can only be made once. That is, a user cannot re-use (or re-verify) the same proof to be used for the same application more than once. This will require a stateful verification contract that keeps track of the current proofs that exist so that they can effectively be nullified.

Web Proof Generation Modes

We’ve diagrammed the various methods in which a Web Proof can be generated below.

Applicable TLS Versions

With this current launch, we support websites running TLS 1.3 for the proxy and TEE mode, and only support TLS 1.2 in TLSN mode.

You can check via the following commands to see which TLS version is supported for a given API. For example, using Venmo as the example API, the second command establishes a connection, demonstrating that Venmo is using TLS1.2 for their API, while the first command hangs.

openssl s_client -connect api.venmo.com:443 -tls1_3 -brief
openssl s_client -connect api.venmo.com:443 -tls1_2 -brief

Support for TLS 1.2 for TEE mode will be completed quickly (by end of Q1). If some unavailable TLS version support is a priority for you, please let us know.

Manifest Files

Our current proof setup is designed to ensure the validity of HTTP requests and responses as well as extract values from structured data. Fields of HTTP are matched exactly or not at all. As for structured data, we only support JSON at this time. In particular, only a single value can be extracted from the JSON and the value is extracted completely.

Moving forward, we plan to support other grammars such as HTML and retrieval of multiple values at once. Also, we will provide the ability to apply predicates (e.g., less or greater than for numerical values or RegEx).

Likewise, in the HTTP requests and responses, we aim to allow for dynamic values to be ensured (e.g., a specific, but variable, username appears in a header).

If you find you have an example request and response where you need these capabilities, please contact us!

What are next steps?

If you want to integrate Web Proofs, continue on to the React/JavaScript SDK guides.

If you want to meet with the Pluto team, you can book a time using our team Calendly.