0000: Forget Me

• Authors: Sam Curren
• Status: PROPOSED
• Since: 2021-06-04
• Status Note: Initial version
• Start Date: 2021-06-04
• Tags: feature, protocol

Summary

A protocol to arrange for another party to forget you and your data, in compliance with an established legal basis such as GDPR.

Motivation

Legislation requires businesses and organizations to forget personal details of an individual upon their request.

There are limits to what must be deleted - discussion of such is outside the scope of this protocol.

Scope

There a wide variety of compliant 'forget me' flows. This one is intended to be simple. A request to forget is a requeste to forget all data completely, rather than a nuanced approach. It is the expectation that after executing this protocol, all data will be deleted (see details below) and the relationship fully terminated.

More nuanced needs should produce a new version of this protocol or a new protocol.

Tutorial

Roles

Data Holder - The agent that has data related to the subject.
Subject - The agent who is picking up messages.

Flow

Subject sends a removal_request message to the Data Holder. The Data Holder then responds with a removal_receipt message and and associated details

Reference

Removal Request

Sent by the subject to the data_holder to request a status message.

{
    "@id": "123456781",
    "@type": "https://didcomm.org/forgetme/1.0/removal_request",
    "legal_basis": "GDPR"
}

legal_basis: String. Must be one of [GDPR, CCPA]
(others may be added by updating this protocol)

Removal Receipt

Sent by data_holder to confirm the forget me request.

{
    "@id": "123456781",
    "@type": "https://didcomm.org/forgetme/1.0/removal_receipt",
    "legal_basis":"GDPR",
    "removed": [
        ""
    ],
    "remaining": [
        {
            "item":"",
            "removal_strategy": "",
            "removal_date": "YYYYMMDD",
            "removal_condition": ""
        }
    ]
    
}

removed: List of strings, each the name of an item removed
remaining: List of items not yet removed, with details about future removal.
removal_strategy: String, one of ["at_date","at_condition"].
removal_date: Datestring, in UTC format YYYYMMDD. Required when removal_strategy is at_date.
removal_conditon: Human readable description of the removal condition. Required when removal_strategy is at_condition.

The removal_date and removal_conditon should only be included when required, and should be ignored by the message recipient if inappropriately included.

Prior art

None

Unresolved questions

• Should we include a way for the data_holder to specify the legal reason for not yet removing the data?

Implementations

The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the "Name" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.