The topic for this call for feedback is Persona data.

Introduction

When a user connects their Radix Wallet to your dApp, they login with a Persona of their choice. That done, your dApp can make requests to the wallet to share various pieces of information - with the wallet saving the user’s sharing preferences against that Persona for your dApp. Of course you can request account addresses, needed to see a user’s assets and what accounts they want to use to transact, but you can also request Persona data – a new concept unique to Radix and the Radix Wallet.

Persona data is “off ledger” personal information about the user that your dApp might need – like the user’s name, email address, or phone number. The Radix Wallet makes it very easy for users to enter this information and give permissions to different dApps to access it. This means that dApps can get easy automatic access to the personal data they need for a useful, personalized experience, without having to fall back to storing all of that data in a database for use whenever the user connects. And for users, it minimizes tedious typing of data into web forms while giving them control over what they share and how they keep it up to date.

The Call for Feedback

On the Babylon betanet and RCnets, you’ve had the ability to play with a very stripped-down form of Persona data, using the Radix dApp Toolkit to request just a few items of Persona data (name, email, phone number) from the developer preview Radix Wallet.

For the Babylon mainnet launch of the Radix Wallet, Persona data functionality is expanding into a more useful form. In particular, the Radix Wallet will include a much longer list of items of Persona data that user can enter and which dApps can request. 

There will also be more flexibility for users in how they enter their own data into the Radix Wallet, allowing for things like multiple entries of some items to choose from (like email addresses), postal addresses formatted for individual countries, and choosing between western and eastern-style full names. The dApp will still just be requesting “email address” or “full name” or “postal address”, but the user will have more choice in what their answer to those queries is.

The latest updates to the developer preview Radix Wallet and RDT for RCnet2 include the new format for requesting Persona data. For example, you’ll notice that rather than request separate “first name” and “last name”, you will request “full name” and you will receive back “given name(s)”, “family name”, “nickname” and whether the user prefers western or eastern name order. This wallet still only supports the very short list of “example” data types (full name, email, phone number), but for mainnet release this will change…

The RDX Works development team needs feedback from you about what specific items of Persona data the Radix Wallet should support – to be the most useful and enabling for your dApp.

To understand why the selection of data items matters, here’s some additional context on the goals of the feature.

First of all, why have specific Personal data items rather than allow dApps to define their own data fields? The reason is that it is important to have well-defined common items of Persona data so that data entered by the user is easily matchable with dApp needs. For example, if a dApp requires an email address, we shouldn’t fail to match that request because the user entered an “E-Mail Address” or “business email address” that happened to be requested by some other dApp.

So the Radix Wallet pre-defines a fixed list of known, supported data items that are common enough that it makes sense for a user to enter them once and use them many places, and for a dApp to request what it needs without frustrating the user.

Note: Separate from this common, pre-defined Persona data, there is some early planning for a separate repository of data held in the user’s Persona that would allow a dApp to define and store its own more specific items - similar to cookies but Web3 style. This would be data that the user has no need to edit themselves, and would not be shared across dApps. This kind of data, however, is outside the scope of this part of the system and this call for feedback.

With these goals in mind, not all data makes sense to be included as items of Persona data – sometimes a web form is still appropriate. Here’s a guide for what sorts of data items should be included and not included:

Reasons why Persona data makes sense to include:

• Commonly needed by dApps during a signup process

• eg: email address, occupation

• Commonly needed at every login to set the context for using the dApp

• eg: name, date of birth

• Commonly needed during dApp usage

• eg: postal address, credit card

‍

Reasons why some Persona data hasn’t been included:

• Sensitive data that is not commonly required, is unlikely to change, and could be easily entered manually into a website if really required

• eg: social security number, drivers license, mother’s maiden name, past aliases, gender

• Highly application-specific data

• eg: name of physician, vehicle VIN

• dApp preferences that can safely be stored server-side

• eg: dark mode preference, my favorites

‍

Respond to the Call

This request for feedback is now closed.

Summary of Results

Many thanks to those who responded to the first Feedback Wanted survey! While persona data is a very new and unfamiliar concept for you dApp developers, the feedback provided was helpful to guide where it might go. 66% of responders said that this feature would be useful to their dApp, which is very encouraging!

An expanded form of persona data will be added to the Radix Wallet and Radix dApp Toolkit after the initial releases for Babylon upgrade. The form it takes is expected to hew quite closely to the form presented in the feedback survey – with a couple of tweaks based on your feedback.

Some other notes from the responses:

The concept of Persona avatars came up as particularly interesting for a number of developers. No disagreement here; it greatly desired and should make the Persona login experience more personal, as well as provide a strong sense of value and ownership of avatars when using their NFT form.

Using persona data for AML/KYC and the idea of "verified" data also came up from more than one developer. This is a difficult, but very valuable, problem to solve. Doing so requires not just providing claims of personal data, but verification of those claims by a third party that is qualified to do so (and is accepted by the dApp in question). The persona data system described here is focused primarily on eliminating the need to reenter common information frequently (and for websites to have to store this information) – so it doesn't inherently provide a solution for verified KYC/AML. However, there is absolutely much thinking already about extending the persona data system to include the powerful concepts of "verifiable credentials" and "DIDs". These should be natural matches to Radix capabilities, and there will likely be another call for feedback on this topic in the coming months.

One person wondered if SWIFT and IBAN information might be included. The reason bank information has been left out is that it doesn't match one of the uses that persona data is designed for: information that is commonly needed during signup, commonly needed at every signup, or commonly needed during dApp usage. Bank information tends to be entered only very selectively – and given to entities that are must save this information for it to be useful. Therefore it may be better to use a traditional web form for the few websites that need bank information. That said, this could be easily added in the future if there is demand.

Thanks again, and stay tuned for the next call for feedback!

‍