rrix
commented
2 years ago I'll add another DENIED request status for now, I think it's a pretty reasonable expectation for consumers to make requests which are out of step. I don't know what to call that state though (DENIED/too-many-requests, but I'm sure there's a clearer way of describing that)
I'm reticent to try to encode some specific reasons or flows for this right now because of how different this can be implemented in each legal jurisdiction and how it might intersect with thinking on other open issues like #22 and #26
Towards your use cases specifically, there are some interesting things raised.
It is 1 year later, I do another request
I think this would simply be a new DRR; a user could perhaps reference their prior request but really there is no reason the CB should keep track of these completed requests, let alone being able to attest that identity tokens match the old verified request or whatever, and in fact the protocol spells this out that after 7-30 days a CB and PIP should stop retaining these tokens and may even forget about the DRR themselves if they way.
I forgot that I created this request yesterday, so I create another
In the simplest case, the CB can just reject this with the new request status.
I used app 1 to create a request, but decided I don't like the app after all, and I start using app 2 before the original request was fulfilled
This is probably the most complex/difficult case, and I'm not sure we can concisely solve this. We could enrich this denial state with some sort of identifier or URL for the agent which did submit the request which could be translated out to ("You've got an open request with BAgent, please complete or cancel your data rights request in that app") maybe with some URL that can affirmatively cancel the DRR if BAgent is unavailable for some reason.
the CB refuses the repeat request on the grounds that too many requests were made to frequently (I think some laws "rate-limit" requests to something like once a year)
This sort of request would also be denied outright, with a DENIED/ETOOMANY type of response, but it's definitely a legitmate end-state for a request. perhaps worth its own reason...
Use cases:
This may impact the state machine in 3.02, and perhaps the identifiers being used to refer to requests. Perhaps there needs to be a "get me the list of (open, closed, ...) requests I made, or were made in my behalf".