Re: [Privacy-pass] The PRIVACYPASS WG has placed draft-group-privacypass-consistency-mirror in state "Candidate for WG Adoption"

I am also in support of adoption and agree that the goal is clear and beneficial. One thing that is not clear to me is how config rotation works. I’ve provided one such example case on Github [1]. This seems solvable and something that could be addressed by the working group.

Thanks,
Eric Rosenberg

[1] https://github.com/chris-wood/draft-group-privacypass-consistency-mirror/issues/31

> On Jan 8, 2024, at 07:33, Thibault Meunier <ot-ietf@thibault.uk> wrote:
> 
> Hi Privacy Pass WG,
> 
> This is a late email given the adoption window closed about 3 weeks ago, and the document is set to expire on Thursday. I would support adoption of this document by the group, as its goal is clear and beneficial.
> I've added some edits on GitHub [1], covering typos, and a clarification to avoid max-age to be accounted for twice, once by the mirror, and then again by the client.
> 
> For deployments of Privacy Pass, this document is useful to better define how clients can check the consistency of a remote issuer.
> 
> For Privacy Pass specifically, I think it is worth defining an OPTIONAL endpoint /.well-known/mirror-resource that would allow clients to retrieve all issuer keys before discovering it when prompted by an Origin. A similar endpoint is provided in Cloudflare attester implementation [2] for instance. This endpoint could be as simple as a list:
> GET /.well-known/mirror-resources
> https://issuer1.example/.well-known/private-token-issuer-directory
> https://issuer2.example/.well-known/private-token-issuer-directory
> 
> It would be interesting to mention how this setup interact with CORS in the Web environment. An issuer could restrict their responses to attester.example/* for instance. The use of wrapped response would not benefit from this sanitasation.
> 
> Regarding the use of BHTTP, I would agree with the GitHub issue [3]. Copying content instead of using BHTTP makes implementation straightforward, as can be seen in this non caching mirror used to avoid CORS locally [4].
> 
> Best,
> Thibault Meunier
> 
> [1] https://github.com/chris-wood/draft-group-privacypass-consistency-mirror/pull/30
> [2] https://github.com/cloudflare/pp-attester#get-v1private-token-attester-directory
> [3] https://github.com/chris-wood/draft-group-privacypass-consistency-mirror/issues/25
> [4] https://github.com/thibmeu/pepe-debug/blob/main/src/server/index.ts#L115
> On Thursday, November 30th, 2023 at 10:39 PM, Ben Schwartz <bemasc=40meta.com@dmarc.ietf.org> wrote:
> 
>> We are opening a two-week Call for Adoption (ending Friday, December 15th) for "Checking Resource Consistency with HTTP Mirrors".
>> 
>> Please comment in this thread with your view as to whether this document should be adopted by the PRIVACYPASS working group.
>> 
>> --Ben Schwartz, for the chairs.
>> From: Privacy-pass <privacy-pass-bounces@ietf.org> on behalf of IETF Secretariat <ietf-secretariat-reply@ietf.org>
>> Sent: Thursday, November 30, 2023 4:07 PM
>> To: draft-group-privacypass-consistency-mirror@ietf.org <draft-group-privacypass-consistency-mirror@ietf.org>; privacy-pass@ietf.org <privacy-pass@ietf.org>; privacypass-chairs@ietf.org <privacypass-chairs@ietf.org>
>> Subject: [Privacy-pass] The PRIVACYPASS WG has placed draft-group-privacypass-consistency-mirror in state "Candidate for WG Adoption"
>>  
>> !-------------------------------------------------------------------|
>>   This Message Is From an External Sender
>> 
>> |-------------------------------------------------------------------!
>> 
>> 
>> The PRIVACYPASS WG has placed draft-group-privacypass-consistency-mirror in
>> state Candidate for WG Adoption (entered by Benjamin Schwartz)
>> 
>> The document is available at
>> https://datatracker.ietf.org/doc/draft-group-privacypass-consistency-mirror/ 
>> 
>> 
>> -- 
>> Privacy-pass mailing list
>> Privacy-pass@ietf.org
>> https://www.ietf.org/mailman/listinfo/privacy-pass
> 