Issuance API vs HTTP headers

[chris-wood]

Why use HTTP headers to convey issuance requests and responses, as opposed to doing what Privacy Pass does and just convey these requests and responses in HTTP message content? Is there a deployment or application model where running this protocol in parallel to other requests is desired? Maybe because of performance? 🤷

[dvorak42]

I believe this is a dupe of #229. From the Origin Trial, adding whole extra requests that then need to be tied together in the back end added implementation complexity (and latency for the folks who weren't using H/2 so had to serialize the connections).

As said in #229 for vStandard, we'd probably add the non-header version of the API and see if we can get dependence/usage of the header version low enough to deprecate it.

[colinbendell]

adding whole extra requests that then need to be tied together in the back end added implementation complexity

Out of curiosity, what do you mean by this? How does moving the sec-private-state-token header to the request body manifest in extra requests?

[dvorak42]

Generally during the OT we saw that IVT/CAPTCHA vendors usually have some payload/data they want to send to the servers (to determine what type of challenge to present/was completed or what level of traffic verification to do). With the PST issuance in a header, they're able to combine the request that contains their data with the PST issuance request and can make the decision to issue tokens based on that. If the issuance request is in the body, then they'd have to make a separate request containing any payload/data from the client and either have cookies/session ids in both requests or long-lived connections to match the issuance request and the payload request.

[chris-wood]

Why could the information they want to send not go in a header? The primary intent of the request here seems to be "get me a token," not "here is some data, oh and by the way can I please have a token?" To me, putting the token request in the body and then whatever additional context is needed for issuance in a header seems like the most ergonomic way to construct this. In effect, the request would say "I'd like a token please (in the body), and here is some optional context that you can use to issue that token (in a header)."

[dvorak42]

Yeah, with a bit of work I think they could rearchitect the client-side to grab the POST body, encode it, and potentially shard it across a bunch of different headers, but that's a lot of additional of work (and then the server will need to have two paths between clients that don't have PST and do have PST making this request).

To focus on the CAPTCHA use (though this applies to IVT). Currently there is usually a stage where the client has solved something, and the client is making a request to the server to verify the CAPTCHA and getting a pass/fail result which is used for the current action the client is trying to perform. The natural extension of this to use PST is to in addition to the pass/fail result, also issuing some PSTs that can be used at a later time as a signal for a future challenge to give a simpler challenge or bypass the CAPTCHA challenge entirely. You could do this through two separate requests (one that has the pass/fail result/challenge verification and another that does the issuance), but that adds extra latency (sometimes on the critical path since a CAPTCHA solution usually happens when the client is moving from one page to another (submitting a form/viewing content/etc).

Maybe one thing to get clarity on is how privacypass expects attestation information to be included with the issuance request in the normal non-rate-limited case? The architecture doc seems to say "attestation" happens then a "TokenChallenge" is sent as two separate requests, but nothing ties them together?