Hi,
Can I get a sample request/response for the /discovery endpoint. Also I'd like to know about the signing of request for other gdpr requests. Are we expecting some HMAC type algo to do this? Is signing mandatory?

Is there a plan to fold in communication over deadlines for responses?
Or is this supposed to be handled purely through SLAs?

Is there a goal of this project to also address joint controller situations?

https://github.com/opengdpr/opengdpr/blob/d3ccb34e78f2605b53c647ab11cdfd8d6ca7abd7/OpenGDPR_specification.txt#L56

The definition of data subject seems to be too narrow. It is supposed to be an individual, identified or identifiable (etc). This could be for instance a resident outside of Europe whose data is processed by any entity upstream based in Europe (the controller or any data processor along the chain).

I want to gather a group of interested open source developers and MIT Media Lab researchers to do some rapid prototyping with OpenGDPR as part of our GDPR “Sunrise Eve” Hack Day on May 24, 2018. It would be really helpful if someone familiar with this project and codebase could demo or talk through how it works and the roadmap. We can bring you in via hangout or welcome you in person if you are nearby Boston.

Event info at: http://gdprhackday.org/

Let me know if someone can present or if you have any questions at: http://law.mit.edu/contact

Hi,
we are currently in pre-decision process and we might use the OpenGDPR specification.
I got one question: Are there reasons for not providing an GET endpoint on /opengdpr_requests/?
Besides the authentication issue. You somehow need to make sure that the request has the right to see the response.
If there no reasons against it, I would add it to the specification and create a PR for it.

It would be nice to add a (generic) processor_id field as a new Identity Type Key. Almost every mobile SDK I'm familiar with generates an UID when the SDK is first initialized / app installed. Sometimes the Controller stores this Identifier in its own database 1. to handle logged-out users 2. to avoid sending an internal logged-in user Identifier (controller_customer_id) to its vendor.

We at Batch.com have a generated Installation ID. It's an anonymous Identifier, not shared with other apps or devices but still, the Controller could attach user attributes / properties that contains PPI (eg: user's name) and we should be able to handle GDPR requests with that ID as the entry point.

I lookup OpenGDPR founding vendors API references and found similar Identifiers:

• mParticle's MPID
• Appsflyer's Device ID
• Braze/Appboy's Device ID
• Amplitude's AID/Device ID

Note : I had a similar thought about other Identifiers like the APNS push token or FCM/GCM registration ID but I don't know if it should be considered as an Identity key / entry point.

Are there any guide lines for fair use of the OpenGDPR logo?

Thank you!

Looks like this project may be obsolete. Is that true?

I'd like to pick up some of the work done in the OpenDSR specification at the very least - which doesnt seem to be a problem given its Apache - but I'm curious if anyone else is working in this space.

Interesting proposal. One thing that isn't clear (sorry if I missed it) is how the processor can communicate the host that serve the endpoints (/discovery, etc) it has provide. From the example, all Host HTTP request headers are for what appear to be the root domain of the processor, but that may not be the best place to expose subject request workflows.

Take a processor that has a public-facing website at example.com. They may have a separate domain for measurement collection, say example-analytics.com (Google Analytics does this). It would make sense for some processors to have a separate host, say subjectrequests.example-analytics.com, to expose the API.

The question then becomes is how to communicate this. I suggest using the /.well-known/ path on example-analytics.com (and possibly also example.com) to communicate this. See RFC5785 for the details, and the DNT spec for an example of how it can work.

First, a big initiative to start a community-maintained GDPR management project! Transparency by design.

Is there any plan to make a simple service - a Dockerfile (and image), a Postman collection - available to show how the OpenGDPR workflow proposition works, here at repository?

It is foreseeable that processors will encounter some scenarios where because of an administrative or technical reason it is unable to fulfill a request.

There are currently only four states a request can be in:

• pending
• in-progrress
• completed
• cancelled

Would it be reasonable to add unsatisfiable and failed to this list?

{
"subject_request_id":"a7551968-d5d6-44b2-9831-815ac9017798",
"subject_request_type":"erasure",
"submitted_time":"2018-10-02T15:00:00Z",
"subject_identities":[
{
"identity_type":"email",
"identity_value":"[email protected]",
"identity_format":"raw"
}
],
"api_version":"0.1",
"property_id":"123456",
"status_callback_urls":[
"https://example controller.com/opengdpr_callbacks"
]
}

The request id should be generated by the processor/controller and sent back in the response. The create request itself shouldn't have the request id.

At the moment the spec only says that data controllers mustn't log or store the encoded_request value. Presumably it must serve some purpose, otherwise it wouldn't be included in the API - but what purpose does it have?

Hey,

This is a great spec - I am wondering if there are any expansion plans? I would love to see this implemented by a lot of companies so that the data subject request process is as smooth as possible.

Andrew.

Hey all,
I noticed that the README.md says that it is possible to send a property named property_id on the request POST /opengdpr_requests, but when looking at OpenGDPR_specification.md it is not documented there.

Both files were changes 14 days ago. Which one contains the correct form ?

https://github.com/opengdpr/opengdpr/blob/d3ccb34e78f2605b53c647ab11cdfd8d6ca7abd7/OpenGDPR_specification.txt#L183

I do not know the industry well enough, so this is a question.

Is there a risk of violating data minimisation principles here?

How can the n-th actor in the chain know that they should pass some subset of identities and only those to the (n+1)-th actor? Should this involve a conversation with that next processor? Will this depend on the particular n-th -- (n+1)th pair?

The create request api accepts array of _ subject_identities[]_. Is there any limit specified for no. of records?

Hello,
How does this work, if the user makes an erasure request on the website of a publisher - who then needs to propagate that request to various partners, however the publisher does not have a mapping of the cookie value / identifier for this user of the partners.
Thanks,
Dennis

Hi,

The spec mentions 3 endpoints: discovery, status and requests (the endpoint to submit a new DSR) . Then there is the callback coming from the data processor to the data controller.

The requests and status endpoints both provide a header X-OpenDSR-Signature in the response. My question are:

• What is the purpose of that signature in the response of these 2 endpoints? Is it about accountability/auditing purposes?

  • I would assume that preventing a MITM attack would be done by other means (during the TLS handshake, checking that the certificate provided by the data processor is valid, signed by a trusted CA & that the domain matches). Is that correct?

• Should the controller validate those signatures (the same way it should validate the signature in the callback)? This is unclear in the spec as far as I am aware.

Thank you!

Hi --

I want to clarify the expected process for generating a response signature is and ensure I understand it correctly. To illustrate I've included some Go code from the library I am writing.

package main

import (
	"encoding/json"
	"fmt"
	"time"

	"github.com/greencase/go-gdpr"
)

func main() {
	// A new OpenGDPR request
	request := &gdpr.Request{
		ApiVersion:         gdpr.ApiVersion,
		SubjectRequestId:   "request-1234",
		SubjectRequestType: gdpr.SUBJECT_ERASURE,
		SubmittedTime:      time.Now(),
		SubjectIdentities: []gdpr.Identity{
			gdpr.Identity{
				Type:   gdpr.IDENTITY_EMAIL,
				Format: gdpr.FORMAT_RAW,
				Value:  "[email protected]",
			},
		},
		StatusCallbackUrls: []string{
			"http://controller.com/opengdpr_callbacks",
		},
	}
	// Create a new response based on the request
	response := &gdpr.Response{
		SubjectRequestId:       "request-1234",
		ControllerId:           "controller-1234",
		ReceivedTime:           time.Now(),
		ExpectedCompletionTime: time.Now().Add(5 * time.Minute),
		EncodedRequest:         request.Base64(), // <-- JSON encoded body of the request encoded as base64
	}
	// Encode the response as JSON bytes
	responseBody, _ := json.Marshal(response)
	// Generate a new Signer from a private key file.
	signer := gdpr.MustNewSigner(&gdpr.KeyOptions{KeyPath: "./key.pem"})
        // Generate a new signature based on the private key
	signature, _ := signer.Sign(responseBody)
	fmt.Println(signature)
	fmt.Println(string(responseBody))
	// Verify the JSON responseBody matches the signature
	verifier := gdpr.MustNewVerifier(&gdpr.KeyOptions{KeyPath: "./cert.pem"})
	err := verifier.Verify(responseBody, signature)
	fmt.Println(err == nil)
}

The program above will generate the following output:

go run main.go 
NahB+ejBv5gCKtoa27D2uWKTsBs00WHhCSVeDD0rGhP8IfKZCaLZJj0UaKB0zIRZ00JcKpTt5+4z6buKkgHAKNgCmKuaW6CSixraMKhKP3kFW9gKzzF7D6LM34UjvhR2NtUBdnU03SU2C1s2yc2sGfi/PNVJukvRb6i1pHrTKaw=
{
  "controller_id": "controller-1234",
  "expected_completion_time": "2018-05-30T18:18:59.67344807+01:00",
  "received_time": "2018-05-30T18:13:59.673447987+01:00",
  "encoded_request": "eyJzdWJqZWN0X3JlcXVlc3RfaWQiOiJyZXF1ZXN0LTEyMzQiLCJzdWJqZWN0X3JlcXVlc3RfdHlwZSI6ImVyYXN1cmUiLCJzdWJtaXR0ZWRfdGltZSI6IjIwMTgtMDUtMzBUMTg6MTM6NTkuNjczNDQ3NDQ0KzAxOjAwIiwiYXBpX3ZlcnNpb24iOiIwLjEiLCJzdGF0dXNfY2FsbGJhY2tfdXJscyI6WyJodHRwOi8vY29udHJvbGxlci5jb20vb3BlbmdkcHJfY2FsbGJhY2tzIl0sInN1YmplY3RfaWRlbnRpdGllcyI6W3siaWRlbnRpdHlfdHlwZSI6ImVtYWlsIiwiaWRlbnRpdHlfZm9ybWF0IjoicmF3IiwiaWRlbnRpdHlfdmFsdWUiOiJ1c2VyQGRvbWFpbi5jb20ifV0sImV4dGVuc2lvbnMiOm51bGx9",
  "subject_request_id": "request-1234"
}
true

My understanding is that the signature is expected (the first line of output) is intended to be placed in the X-OpenGDPR-Signature header on each response from the processor. The section on response properties mentions a processor_signature field but the example doesn't include it and only shows the header.

Types of Supported Certificates

The specification links to a DSS document which includes several types signature algos (DSA,RSA, & ECDSA), should implementations support ALL of these or is just one (RSA) sufficient? The spec seems fairly vague here.

Thank you!

Hi --

I wanted to share a server / framework implementation of the OpenGDPR specification in this repository I wrote in the in the Go programming language. Because this standard isn't finalized yet and there are a few issues I need to open related to the spec, it is not 100% compliant with your specifications.

Perhaps we could add a list of libraries / frameworks that implement the standard on the readme? So far I have not found any other existing implementations.

I hope that this library will be helpful to someone looking to build services that are compliant with GDPR.

https://github.com/greencase/go-gdpr

Thanks!

https://github.com/opengdpr/opengdpr/blob/d3ccb34e78f2605b53c647ab11cdfd8d6ca7abd7/OpenGDPR_specification.txt#L68