dvorak42
commented
3 years ago Part of the motivation is that with delegated verification, the publisher has to make a request to the issuer for every action that it requires tokens for, which on high traffic sites is a substantial increase to network traffic and can increase the latency for the website as it waits to verify the token before responding to the client.
Another part of it is that there are many use cases (CAPTCHA/fraud) where the publisher has to be considered in the threat model, and the publisher might just take the token, keep it to themselves and try to use it at another time in a different context. Having this sort of async verification lets the issuer bind some context to the redemption record so it can't be replayed in other circumstances (and also enables things like the signed outgoing request binding to the client).
In most cases, the worst case privacy guarantees of async mode is also pretty close to delegated verification mode, as the issuer will be hit for a redemption at the same time the action that is being protected happens, and the publisher has access to the same information the issuer would have in async mode (time of the request, action the request is for, etc) and we can't assume it won't just provide that information as part of the token redemption. For the CAPTCHA style cases, we'd also expect that information about the request time/source/site would be passed to the issuer either as part of the redemption or if the client is requested to pass a CAPTCHA challenge if they have no tokens or have expired tokens.
The Trust Token API has chosen what the IETF draft PrivacyPass spec calls async verification (browser sends redemption token to issuer, sends attestation to publisher) over delegated verification (browser sends redemption token to publisher, publisher redeems with issuer). The motivation for this isn't really explained. Privacy-wise, this is a nontrivial trade-off.
Specifically, consider the captcha use case: it is fairly common that a succesful authenticity check will result in some publicly observable outcome with a timestamp (e.g. a forum post). In the delegated verification version of the protocol, this means and adversarial issuer might be able to determine, by correlating the time of redemption with the public artifact, whether that artifact was created by someone whom the issuer gave tokens in the past, but nothing more than that. There are conveivable scenarios where that can be a problem, but for an issuer which gives out lots of tokens, it's not much information.
In async verification mode, though, the issuer will have a redemption timestamp and also the IP address of the browser. Often the issuer will be able to guess some narrow IP range for the public artifact, and that and the timestamp together might be enough to establish a correlation. Less abstractly, imagine a post is made on a local forum of some town. The police subpoenas the issuer data, filters it to the IP range used by local ISPs and to the timestamp of the forum post, and has a pretty good chance of finding out the IP address. While this is still strictly better than a similar scenario where the web forum uses an embedded captcha, it seems significantly worse than what can be achieved with delegated verification.
There's a similar issue when the issuer is not compromised but the adversary that can listen into network traffic: as long as the issuer is a domain that's not used much for other things (ie. a request to that domain is likely to do with a trust check), the pattern of the same IP/device sending a request to the issuer shortly before sending a request to the publisher will give away that that IP did something that necessitated an identity check. By filtering monitored traffic for that pattern happening nearly simultaneously with the publishing of the post the adversary is interested in, again the IP of the poster can be revealed.