# PrivacyPass at IETF 113

Note taker: Jonathan Hammell

# Adopted drafts

## Architecture (draft-ietf-privacypass-architecture)

Presenter: Chris Wood

Architecture is split into two protocols: issuance and redemption. Reminder that the goal is to ensure no single entity can link per-Client and per-Server information. 

Ben Schwartz: Slides say context separation over "time or space", but suggest "time and space". In any sufficiently small time window, there is only a single client, so there is no privacy in the Joint Model, so it requires time separation.

Chris W: If there are interactive tokens there might be no time separation. 

## Auth Scheme (draft-ietf-privacypass-auth-scheme)

Presenter: Tommy Pauly

Ted Hardie: For the opaque origin name (optional), you could leave this out and the resumption context would handle it. But could you allow more than one origin name in the struct for cases like youtube.com and google.com where the two are not the same but the redemption mechanics might be?

Tommy P: There are other ways to discover whether it is safe to do cross origin redemption.

Ted: There may be examples where cross-origin may not be allowed, but the mechanics may be the same. There are trade-offs, but it may be simpler to just allow multiple origin names. 

Steven Valdez: It may be clearer to allow `origin` to be entirely opaque, so it could be a domain name, or multiple names, or something else, and leave the interpretation out of scope for this doc.


# Seeking adoption

## Rate-Limited Issuance (draft-privacypass-rate-limit-tokens)

Presenters: Tommy Pauly & Chris Wood

Uses "signature schemes with key blinding" which will be presented in CFRG. 

Ben Schwartz: Why can't we do this with original PrivacyPass construction. For example, in the paywall example, an issuer affiliated with a single service could issue free accounts with only a limited number of tokens per month.

Tommy Pauly: If the client is willing to create an account with the origin, this would work. But this targets the case where the client does not wish to create an account. And in the rate-limiting case, we wish to prevent bot farms from creating a bunch of accounts. 

Ben S: Not creating an account in the origin, but an account in a separate origin that is not linkable. 

Tommy P: That is essentially what this proposal is. In order to rate-limit, the origin needs to know what those tokens are for. In many cases, it might be easy to know. 

Chris W: In the free account case, you would learn the browsing history.

Ben S: I would like to take that state and shard it out into an entity funded by the validator rather than having the attester maintain a large state. Would like to be more confident that this is the simplest solution for the architectural context.

Jana Iyengar: Agree with Ben, if there is something simpler we should do that.

Chris W: Key challenge was to build in a mechanism to keep in the state without violating the privacy. This was not the first solution the authors designed. If there is a simpler solution, that would be great.