[RFW0013] Data-Individual- DSR validation in the blockchain

[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
• Requirements
• Drawbacks
• Alternatives
• New Data
• Business Release Date

Housekeeping

Make sure to clearly understand Type-A and Type-B requests, and the relevant limitations. Failing to follow the guidelines pertaining to the two acceptable types of RFWs will automatically lead to disqualification 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

There is no way to demonstrate the company's response to a DSR request in the blockchain

User Story

As a user I want to verify that the brand has taken action against my DSR assertion so I can verify that they have actioned my request.

Business Severity - Medium
Business Priority - Medium

Request Type A/B

Type A

This is an extension of DSR Issuing and Management

Owner

Mitchell Goudie

Summary

As an extension of our Fund 5 proposal wherein metadata of a DSR is logged to the blockchain, this RFW increases the scope to also include the reaction of the company in the form of a smart contract or additional metadata entry. This is to prove not only the DSR was asserted, but to demonstrate the company's response.

Is This Really Necessary?

This is what is discussed in the proposal and so is necessary.

Motivation

Extending the functionality of the DSR assertion process as established in our Fund5 proposal is scoped in the successful proposal of our Fund8 proposal. Adding this additional functionality fulfils the proposal goals and grants individuals & brands an easy method of managing DSRs.

Named Concepts

Examples, Risks & Assumptions

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

• Once a brand responds to a DSR assertion on the Profila platform via the response panel, this response is noted in the blockchain either via smart contract or additional metadata entry
• Once a brand responds to a DSR assertion that is received via email, this response is noted in the blockchain either via smart contract or additional metadata entry
• If a brand doesn't respond, this action is also noted in the blockchain
• Once the individual validates the response of the brand, this action is also included within the ledger

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

Currently there is no implementation of a brand's response, nor the individual's verification of response, in the blockchain via smart contract nor additional metadata entry

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 see a verification of their response to the brands DSR action in the blockchain
• Profila brands will be able to see their response to the users DSR in the blockchain

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

All sample messaging in design

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

• The DSR assertion process is out of scope of this request
• The Privacy control panel for brands is out of scope of this request

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!)

N/A

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).

An error message should be displayed if the additional information cannot be written to the blockchain

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

Additional writing to the blockchain will incur additional costs.

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

N/A

Success Metrics

Both brands and users can see the updated DSR assertion in the blockchain, along with the brand response and individual's validation

Conceptual Design

The purpose of this RFW is to extend the functionality of our Fund 5 proposal which dealt with writing the metadata of a DSR assertion to the blockchain. The scope of this RFW:

Implementation of smart contract / additional metadata to reflect the following:

• A brand's response
• A brand's non-response
• The individual's validation of the response

This implementation must function regardless of whether the process occurs on the Profila platform (when the brand is registered and uses the platform) or via email (when the brand is not on the Profila platform)

Logic Flow

Brand Response

• 'Status: Responded' should be input into the metadata / smart contract
• Text of what the Brand input into the justification field should be added to the blockchain (reason they marked it as complete)

Brand Non-Response

• 'Status: No Response' should be input into the metadata / smart contract

Individual's Validation

• 'Status: Validated' should be input into the metadata / smart contract

Figma Designs

Flow Diagrams

Flow0039

Requirements

Drawbacks

N/A

Alternatives

N/A

New Data

Business release date