Re: [Privacy-pass] New drafts for IETF107

Hi Steven,

> On 6 Feb 2020, at 15:22, Steven Valdez <svaldez=40google.com@dmarc.ietf.org> wrote:
> 
> Yeah, it makes sense not to wait for the BoF to start iterating on initial docs. Are you planning on putting the split document in a git repo somewhere? Might make sense to set up a repo with all the base drafts in one place as separate files (ala the QUIC WG) so that people can file issues/PRs.

This is a good idea. I’ve repurposed the repo where I was hosting the draft charter previously to also include a space for working on the drafts here: https://github.com/alxdavids/privacy-pass-ietf/ <https://github.com/alxdavids/privacy-pass-ietf/>. I’ve placed the original draft-privacy-pass document in the drafts/ folder there, and we can use this space as a single location for contributing to these base drafts. Once a WG is formed, we can move this repo into a specific WG repo.

> 
> I can take a stab at making a draft with a generic version of the integrations from the Trust Token API as a starting point for the third draft. I think fully specifying it will be dependent on the first two drafts, but having a starting point to feedback into laying out the earlier protocol/architecture descriptions would likely be useful for further iterating on those drafts.

This would be helpful, thanks.

Alex

> 
> -Steven
> 
> On Thu, Feb 6, 2020 at 7:31 AM Alex Davidson <adavidson=40cloudflare.com@dmarc.ietf.org <mailto:40cloudflare..com@dmarc.ietf.org>> wrote:
> Since there has been no more feedback on the charter that was proposed, I think that it may be useful to start work on drafting the three main documents that make up the protocol specification. Having some initial write-ups before the BoF @ IETF107 will also help to determine the agenda for the meeting if there any initial issues that arise from the writing process.
> 
> These three documents should cover the following:
> 
> - The generic description of the protocol, based on VOPRFs (or similar), including specification of security considerations, protocol messages and a framework for introducing extensions.
> - The wider architecture for running the protocol: public interfaces, key rotation, privacy goals, applications, analysis of tracking potential/incentives for not following protocol.
> - The API: specify how privacy pass data is integrated with HTTP requests/responses, and where key material is stored/how it is accessed.
> 
> Currently there is a single draft document (https://datatracker.ietf.org/doc/draft-privacy-pass/ <https://datatracker.ietf.org/doc/draft-privacy-pass/>) that includes considerations mostly spanning from the first two documents (although it is also includes some key management specifics). I can start to split this document into two parts that could be used to initiate the process of writing the initial drafts covering the first two points.
> 
> The third point is not well specified as of yet, but there are some applications such as the Trust Token API that integrate with HTTP already: https://github.com/WICG/trust-token-api <https://github.com/WICG/trust-token-api>. Perhaps the third document necessarily needs to succeed the first two? But if anyone would be willing to start working on this document also, then that would be useful.
> 
> Alex
> -- 
> Privacy-pass mailing list
> Privacy-pass@ietf.org <mailto:Privacy-pass@ietf.org>
> https://www.ietf.org/mailman/listinfo/privacy-pass <https://www.ietf.org/mailman/listinfo/privacy-pass>
> 
> 
> -- 
> 
> Steven Valdez |	 Chrome Privacy Sandbox |	 svaldez@google.com <mailto:svaldez@google.com> |	 210-692-4742