tfpauly / privacy-proxy

Specifications for Privacy Proxy Implementations
Other
29 stars 11 forks source link

Send policy from Issuer to Attester for enforcement #125

Closed chris-wood closed 2 years ago

chris-wood commented 2 years ago

Currently, the Attester sends per-client state to the Issuer for the purposes of determining whether or not a given token request is permitted (or not). I see a couple problems with this:

  1. The policy limit isn't necessarily secret from the Attester anyway, since it (a) knows the per-client counts and (b) can see when the Issuer refuses to produce a token response. It can then infer what the limit is. It could even act as a malicious client to learn the per-origin limit if it wanted.
  2. The Issuer currently reveals when it refuses to process a token. We could change that by having it just randomize the token response in the event of failure, but then the Attester could just act as a client and learn whatever real clients learn, so this doesn't make much sense to me.
  3. Bucketizing the counts from Attester to Issuer seems leaky at best, especially since the right size of the buckets seems to depend on client activity. I don't know of a reasonable strategy here that would allow us to state concrete properties about what the Issuer can and cannot learn per client. And it seems like we want something like k-anonymity?

I think we should instead have the Issuer send the Attester the per-origin policy limit, and then require the Attester to enforce the policy based on that limit. We already require origins to not have unique policies for privacy reasons, so this seems fine. Moreover, giving the Attester this policy information doesn't seem like revealing anything new. But it would mean that the origins now trust Attesters directly to enforce limits, rather than Issuers being the ones to do that. Since Attesters are already transitively trusted through Issuers, this doesn't seem like a stretch.

tfpauly commented 2 years ago

The concerns with switching the direction of the count limit are:

  1. The Issuer can no longer enforce nuanced policies that change the limit based on context and condition
  2. The Attester can be lazy and just allow clients to get tokens, without any way for the Issuer to detect this behavior. The Issuer loses it's ability to validate that policy is enforced.