Skip to content

Commit b8ddb4b

Browse files
author
Ben
committed
Cleanup of the readme towards OpenDSR
1 parent 3f30dca commit b8ddb4b

2 files changed

Lines changed: 22 additions & 19 deletions

File tree

README.md

Lines changed: 21 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -1,27 +1,23 @@
11
# OpenDSR Summary
22

33
# Overview
4-
This is an introductory document intended to provide a summary of OpenDSR. For full reference details, please see the complete specification at https://www.OpenDSR.org and https://github.com/OpenDSR/OpenDSR. This project was formerly known as OpenGDPR and existed at https://www.OpenGDPR.org and https://github.com/OpeGDPR/OpenGDPR.
4+
This is an introductory document intended to provide a summary of the OpenDSR framework. For full reference details, please see the complete specification at https://github.com/OpenGDPR/OpenDSR. This project was formerly known as OpenGDPR and existed at https://www.OpenGDPR.org and https://github.com/OpeGDPR/OpenGDPR.
55

66
# Goals and Scope
7-
The OpenDSR specification defines a common approach for data Controllers and Processors to build interoperable systems for tracking and fulfilling Data Subject requests as defined under the General Data Protection Regulation (GDPR).
7+
The OpenDSR specification defines a common approach for data Controllers and Processors to build interoperable systems for tracking and fulfilling Data Subject requests as defined under the General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA). To reduce confusion, this document uses the language and terminology of the GDPR.
88

9-
For more information on the Data Subject Rights, see chapter 3 of the GDPR.
10-
11-
This spec is intended to:
9+
This framework is intended to:
1210
1. Provide a well defined JSON specification that allows Controllers and Processors to communicate and
13-
manage Data Subject access, portability and erasure requests in a uniform and scalable
14-
manner.
11+
manage Data Subject Requests (DSRs) in a uniform and scalable manner.
1512
2. Provide strong cryptographic verification of request receipts to provide chain of
1613
processing assurance and demonstrate accountability to regulatory authorities (Article
1714
5.2).
18-
3. Provide for a callback mechanism to enable Controllers to track the status of
19-
all Data Subject requests.
15+
3. Provide for a callback mechanism to enable Controllers to track the status of all DSRs.
2016

2117
This specification does not cover:
2218
1. Defining the technical measures to describe the fulfill of Data Subject requests.
2319
It is the responsibility of each Data Controller and Data Processor to interpret and
24-
apply the GDPR to honor Data Subject requests (GPDR Chapter 3).
20+
apply relevant regulatory analysis and expertise to honor DSRs (the text of the GDPR and CCPA).
2521
2. The protocol for communications between Controllers and Data Subjects.
2622
3. The protocol for communications between Controllers, Processors and Supervisory
2723
Authorities.
@@ -31,33 +27,39 @@ Authorities.
3127

3228
## Roles
3329
**Data Subject**
34-
A European Union resident whose personal data is being processed.
30+
The person whose data is being collected and/or processed.
31+
32+
The CCPA refers to data subjects as 'consumers'.
3533

3634
**Data Controller**
37-
The Data Controller receives Data Subject requests from the Data Subjects and validates them. The Controller submits requests to the Data Processors.
35+
The Data Controller receives DSRs from the Data Subjects and validates them. The Controller submits requests to the Data Processors.
36+
37+
The CCPA refers to controllers as businesses.
3838

3939
**Data Processor**
40-
The Data processor fulfills the request for the Controllers scope.
40+
The Data processor acts on behalf of the controller and fulfills requests within the Controllers scope.
41+
42+
The CCPA refers to processors as service providers.
4143

4244
## Request Sequence
43-
This diagram outlines the flow of GDPR data subject requests all the way from the data subject to the fulfillment by each Processor. This flow includes optional callbacks that allow the Controller to receive status changes.
45+
This diagram outlines the flow of DSRs all the way from the data subject to the fulfillment by each Processor. This flow includes optional callbacks that allow the Controller to receive status changes.
4446

4547
![protocol flow](images/figure_protocol_flow.png)
4648

47-
1. New Data Subject Request: The data subject files a request to the data controller containing appropriate information. Request may be of any type provisioned in the GDPR text, commonly: access, portability, erasure, rectification.
49+
1. New Data Subject Request: The data subject files a request to the data controller containing appropriate information. Request may be of any type defined herein.
4850
2. Request Distribution: The controller verifies the request and if it will be honored, it is submitted to Processors.
4951
3. Request Fulfillment: The Processor fulfills their obligation within the scope of this request. For example, this may include deleting user data in the case of a deletion request.
5052
4. Request Status via Callback: The processor will submit status updates to the controller if callbacks are included in the request.
5153
5. Communication to the Data Subject: The Controller communicates the results to the data subject.
5254

5355
## Request Types
54-
The spec supports request types of “erasure”, "access" and “portability”. For all types, the details of how a processor fulfills the request is defined by the GDPR and is out of scope for this specification. For access and portability requests, secure transmission of the resulting personal data is left up to the controller and processor.
56+
The spec supports request types of “erasure”, "access" and “portability”. For all types, the details of how a processor fulfills the request is defined by the regulations and is out of scope for this specification. For access and portability requests, secure transmission of the resulting personal data is left up to the controller and processor.
5557

5658
# API Summary
5759
## Endpoints
5860
This is an overview of available HTTP methods for communicating between Controllers and Processors. The following endpoints should be provided by the Processor (to receive requests from the Controller).
5961

60-
Restful API endpoints for the resource “opendsr_requests”:
62+
Restful API endpoints for the resource "request":
6163

6264
| HTTP Method | Path | Description | Supported? |
6365
| --- | --- | --- | --- |
@@ -79,6 +81,7 @@ Refer to the full specification for definitions of objects and fields.
7981
```
8082
{
8183
"subject_request_id":"a7551968-d5d6-44b2-9831-815ac9017798",
84+
"regulation": "gdpr",
8285
"subject_request_type":"erasure",
8386
"submitted_time":"2018-10-02T15:00:00Z",
8487
"subject_identities":[
@@ -90,7 +93,7 @@ Refer to the full specification for definitions of objects and fields.
9093
],
9194
"api_version":"1.0",
9295
"status_callback_urls":[
93-
"https://example-controller.com/opendsr_callbacks"
96+
"https://example-controller.com/opendsr/callbacks"
9497
]
9598
}
9699
```

specification.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22

33
An open specification for data subject request management, formerly called OpenGDPR.
44

5-
### Version 1.0
5+
### Version 2.0
66

77
### Abstract
88

0 commit comments

Comments
 (0)