Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

added supported_extensions list to discovery #25

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 18 additions & 10 deletions OpenGDPR_specification.md
Original file line number Diff line number Diff line change
Expand Up @@ -62,18 +62,18 @@ Enacting compliance related activities to honor an OpenGDPR request.
### 3.1. Roles and Responsibilities

#### Data Subject

A European Union resident whose personal data is being processed.

#### Data Controller

An entity which makes the decision about what personal data will be processed and the types of processing that will be done with respect to that personal data. The Data Controller receives Data Subject requests from the Data Subjects and validates them. The Data Controller **SHOULD** provide a callback endpoint. The Data Controller **SHOULD** verify response signatures. Referenced as "Controller."

#### Data Processor

The organization that processes data pursuant to the instructions of the Controller on behalf of the Controller. The Data Processor receives data subject requests via RESTful endpoints and is responsible for fulfilling requests. The Data Processor **MUST** provide a signed response to requests. The Data Processor **MUST** honor callbacks. Data Processors **MUST** honor callbacks included in requests.
The organization that processes data pursuant to the instructions of the Controller on behalf of the Controller. The Data Processor receives data subject requests via RESTful endpoints and is responsible for fulfilling requests. The Data Processor **MUST** provide a signed response to requests. The Data Processor **MUST** honor callbacks. Data Processors **MUST** honor callbacks included in requests.

Processors **MUST** provide the following endpoints:
Processors **MUST** provide the following endpoints:

- `/discovery`
- `/status`
Expand Down Expand Up @@ -193,13 +193,17 @@ erasure

**REQUIRED** version string representing the supported version of the OpenGDPR API.

`supported_identities`
`supported_identities`

**REQUIRED** array of "identity_type" and "identity_format" pairs.

`supported_subject_request_types`

**REQUIRED** array of "subject_request_type" strings as defined in 6.2.
**REQUIRED** array of "subject_request_type" strings as defined in 6.2.

`supported_extensions`

**REQUIRED** array of extension keys as defined in 7.1.2.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • why is it required? If a processor does not support any extension - must they return an empty-list vs. null?
  • is it worth noting that this is with the intention that requests could be federated?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • It keeps it in line with the others: all required. Someone could conceivably have 0 supported public identities (passing an empty array) and one or more supported extensions. What do you think?
  • I don't think it needs to be called out since it could work by aggregating the discovery info.


`processor_certificate`

Expand All @@ -222,6 +226,10 @@ Content Type: application/json
"identity_format":"sha256"
}
],
"supported_extensions":[
"example-processor.com",
"example-other-processor.com"
],
"supported_subject_request_types":[
"erasure"
],
Expand Down Expand Up @@ -265,11 +273,11 @@ OpenGDPR service implementations **MUST** provide an endpoint that creates OpenG

#### 7.1.2 Extensions

OpenGDPR requests may contain an `extensions` object, composed of a series of child-objects, keyed by a processor domain.
OpenGDPR requests may contain an `extensions` object, composed of a series of child-objects, keyed by a processor domain.

- The domain of each extension **MUST** match the processor's OpenGDPR domain, matching the `X-OpenGDPR-Processor-Domain` header in OpenGDPR responses.
- Extensions **MUST** not be used for or contain authentication information.
- Processors **MUST** only implement an extension for items that do not already fit into the generic spec.
- Extensions **MUST** not be used for or contain authentication information.
- Processors **MUST** only implement an extension for items that do not already fit into the generic spec.

[Currently known extensions can be found here](OpenGDPR_extensions.md).

Expand Down Expand Up @@ -695,4 +703,4 @@ safeguard each request and it’s encapsulated identities.

## 12. References

[The EU General Data Protection Regulation](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN)
[The EU General Data Protection Regulation](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN)