A proposal for secure GET requests

[rrix]

(expanded from brainstorming conversation with @kevinr yesterday)

POSTing signed requests for /exercise as defined in #56, and even signing /revoke is reasonable and proportionate and allows us to submit data rights requests without sharing symmetric secrets out of band. Signing GET requests, however, is not something web frameworks or HTTP clients have the capability to do in a standard fashion.

We have considered making the /status a POST or PUT request which accepts a simple object containing only the request_id, iss, aud, iat and exp claims, but have also another option we would like to consider. Rather than asking protocol implementers something non-standard we propose a simple mechanism for issuing long-lived API tokens using the signed request model outlined above.

We propose adding a new endpoint to the Data Rights Protocol: POST /generate-token?kid={aa-id} will accept a signed object with the same fundamental security requirements as a Data Rights Request. The Privacy Infrastructure Provider will consult the Authorized Agent directory to pull the public key associated with {aa-id} in the request, validate the signature and issue a high-entropy API token which can be used for GET /status and any future authenticated read endpoints. This will allow AAs and PIPs to exchange API tokens without needing to directly communicate and without needing to share symmetric tokens out of band. This can be done without introducing new secure-storage requirements outside of those which exist for the private key management already being proposed in section 3.07.

There are still some things which need to be evaluated with this idea, for instance how the AA will know whether the key should be per-PIP or per-CB and how the AA can "test" a key for validity without hitting the /status endpoint

[rrix]

There is another aspect at play here: there is the status_callback channel which is a PIP->AA push channel provided at exercise-time by the AA in the signed request. This request does not need a signature or even an API token really. Right now the GET /status endpoint can return information which could be considered sensitive, for example the results_url which could lead to an under-secured data access request, or the processing_details field which is used to signal more fine-grained status updates than the state/reason tuple can express (for example, exactly why a data request's timeline is being extended). I can envision a world in which this higher-sensitivity data is only sent to the URL provided in the signed status_callback field and the GET /status endpoint could only return the state tuple and timestamps.

[kevinr]

I think in traditional REST orthodoxy the GET /status endpoint would actually be something like GET /exercise/{request-id} and the revoke request could even be DELETE /exercise/{request-id}. We could imagine some kind of /status endpoint which returns information about the status of the overall system when queried with an appropriate key which could be used for system liveness checking and token validation.

In my mind the /generate-token request is almost like an /agent/register or /agent/signup request, and we could further imagine some family of /agent/{aa-id} endpoints which would return authenticated or unauthenticated information.