There shouldn't be a request id in create request payload.
forever-programmer opened this issue · 8 comments
{
"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":"johndoe@example.com",
"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.
@forever-programmer we discussed this decision at length prior to publishing, but open to changing it. The reason why we have request id in the request payload, which means it is generator by the controller and not the processor, because it makes it significantly easier for a controller to assign a single request id to the actual subject request and then use that same request id across all of their processors. The only requirement the spec has is that all request ids must be proper v4 GUIDs to avoid collission.
Additionally, the OpenGDPR spec permits platforms and processors to forward requests on behalf of a controller, and yet the callback will go directly to the Controller. In this case, if the Controller is not permitted to specify the Request ID, when they receive the callback from a downstream processor, they won't know what request to tie it back to.
There is precident in requestors specifying request ids in specs such as OpenRTB (see id in section 3.2.1 of https://www.iab.com/wp-content/uploads/2015/05/OpenRTB_API_Specification_Version_2_3_1.pdf)
I'd say, the controller should use "X-Request-ID" http header.
This way even controllers are free to choose any id generation algorithm. (In some cases, system already have their proprietary logic for this and such controller systems might want to use it).
If the x-request-id is not already present in processor's database as well, it can very well return the same id in the response.
I'm not really aware about OpenRTB specs, but what I could read from the shared document is that RequestId is generated by Exchange for its bidder in order to maintain global uniqueness. So, if the model is as such that there's one Exchange forwarding requests to multiple bidders, I guess, it'd make sense for the Exchange to generate the requestId.
The use case I explained where a processor is responsible for distributing the request to downstream publishers and the callback makes it back to the controller would still be broken in your proposal. In addition, the signed response has increased fidelity by including the request id and is easier for the controller to validate because the the processor is signing the request, not a modified request.
In more detail:
- Controller makes request to processor (P1) that includes a callback url.
- Processor returns request id 1.
- Processor distributed that request to another processor (P2).
- P2 returns request id 2.
- P2 completes request and MUST make callback to controller because it was included in request.
- P2 calls endpoint with request id of 2
- Controller does not have request id 2 as one it issued and is unable to accurately track it to an original request.
We believe that requiring proper v4 GUIDs mitigates collision, and significantly simplifies the asymmetrical data flow.
My only concern is that with so many processors and controllers out there, we can't really gaurantee everyone to be using v4 GUID. Few systems might want to continue with their internal 'unique id' generation logic for consistency. Anyways, their gdpr request should be unique for their system, not across all the gdpr requests across all the controllers/producers. I feel that its good as a best practice or suggestion, but enforcing this would cause some resistance in participating entities.
And in scenarios when a controller (C) calls processor (P1) that in turn calls processor (P2), P1 shouldn't really be forwarding the callback url from C to P2. Or else C would end up getting multiple callbacks from P1, P2 and so on. I think its best if the recipient (P1) of the request ensures the call to callback url, rather than relying on any downstream system (P2). It can set its own callback url for downstream system.
The spec defines that P2 will call the controller directly. P1 must pass any callbacks present in the request to P2 and may optionally add their own.
In that case, requestId should indeed come from the controller. Can you please share the link for specs again.
I've just one question though. What if, a processor has to deal with non opengdpr compliant downstream processor?
@akatz0813 In the api specs, the '' is still missing in the url. Will it be added?
@forever-programmer following up here. The spec is here in this repo: https://github.com/opengdpr/opengdpr/blob/master/OpenGDPR_specification.md
Which line where you referring in your last comment?