[RFW0000] User Registration on Web - UI Flow

[ProfilaMitchell]

Table of Contents

• Housekeeping
• The Problem
• User Story
• Request Type A/B
• Owner
• Summary
• Is This Really Necessary?
• Motivation
• Named concepts
• Examples, Risks & Assumptions
• Success Metrics
• Conceptual Design
• Drawbacks
• Alternatives
• New Data
• Business Release Date

Housekeeping

Make sure to clearly understand Type-A and Type-B requests, and the relavant limitations. Failling to follow the guidelines pertaining to the two acceptable types of RFWs will automatically lead to disfqualification of the RFW.

Take time to complete each section below with as much detail as is required to establish a comprehensive understanding about the underlying product specification.

ALL BELOW FIELDS ARE REQUIRED

The Problem

We do not currently have a way for consumers to register on the Profila platform via web

User Story

As a consumer I want to register on Profila so that I can use the platform

This RFW is essential for registering users on web. High Priority user story as such.

Request Type A/B

Type-B

Owner

Mitchell Goudie

Summary

The UI and flow of the user registration process is being developed for web.

Is This Really Necessary?

It is necessary to have a registration process in order to have users. The UI has been designed to reduce user friction during the process. Delivering a registration process that delivers this goal is the "best way" to onboard users.

Motivation

We need to implement a registration process in order to have users on the platform. The registration process will allow users to join using a MagicLink from a brand and subsequently support out B2B2C model. The MagicLink identifies which brand has sent the invitation and supports the model.

The UI implementation of user registration as per this RFW also facilitates user registration via DID, as noted in the complementary RFW here.

Named Concepts

Data Subscription - Is when a brand subscribes to a certain set of user data based on their needs, and compensates the user for access to the data. The access is revoked at the end of the contract.

Examples, Risks & Assumptions

1. Explain concretely what will manifest as a result of this RFW.

• Consumers will be able to register on Profila (via web) as users by clicking on a MagicLink received from a brand
• Profila will be able to verify that the MagicLink used correlates to a specific brand, granting the user access to the platform
• Profila will be able to facilitate data subscription offers between brands and consumers to which they have sent a MagicLink
• A DID will be created simultaneously using ATALA Prism, as noted in in the complementary RFW here.

2. Explain how is it different from what is already manifesting i.e. what we already have?

There is currently no way for consumers to register as Profila users on web

3. Explain what Profila users/brands will experience as a result of this RFW. How will they feel as a result of it? How will they benefit as a result of it?

Profila users will be able to register for the platform on web as a result of this RFW. They will feel freedom in their ability to register for the platform on web and not be restricted to a mobile application.

4. If applicable, provide sample messages for any new messages the system will display as a result of this RFW.

All sample messages are provided in the Conceptual Design section of this RFW.

5. Define what is out of scope in this request.

• Registration for brands is out of scope of this request as it only pertains to consumers
• User Log in (existing account) and forgotten password is out of scope in this request as it is filed in a separate RFW.
• The integration of Atala Prism in the registration process is out of scope in this request as it is filed in a separate RFW.

6. What are the data protection, privacy and security assumptions made for this request (example, should this be GDPR, HIPPA (healthcare), NIST compliant etc. - Speak to Michiel or Ipek!)

NIST identity control

7. Explain how this user story will be supported (i.e customer support - if the user story fails technically, how will the user be supported).

If the user cannot register successfully, the user will be supported by contacting admins in telegram, discord, or other social channels.

8. Explain how this user story impacts revenue or billing (if applicable).

• Creating a DID incurs a cost - we need to analyse who incurs the cost (Profila or the user)

9. State any additional risks identified as a result of this user story.

• Risk that the process is too long for customers to complete effectively

Success Metrics

Having 100% of people who start the registration process finish it

Conceptual Design

• The conceptual design of the registration process, including all fields necessary and elements of text for the user, are included in the 'Registration' section of the Figma board below.

• The design includes the use of 'MagicLink' upon initial registration. This requires the user to input their phone or email and click on a link subsequently sent to them.

• The design also accommodates for registration directly from a brand invitation wherein the MagicLink would be sent by the brand, thusly skipping the initial email input screen for this flow.

• The design is responsive and so should also be usable, as conceptually designed, on a mobile web browser.

https://www.figma.com/file/Dd5uhOzEbxJ7euR7Hn6Jzf/Profila-Website-(Individuals)?node-id=0%3A1
Pass: Profila2022

Drawbacks

• The need for a code from a brand to access the platform may act as an initial barrier to masses of people who want to try the platform.

Alternatives

New Data

• User sign in details - Associated phone number and/or email
• User data - Nickname, date of birth, gender, country of residence

Business release date

The Profila registration and process is requested by the start of Q4/October 2022.