Re: Call for Adoption: Private State Tokens/Private Tokens Work Stream

Dear, list,

Based on the feedback we've heard so far and the varied interests, the 
concrete plan is as follows:

- We'll setup a *private tokens* workstream and github repository where 
discussions about how to use private tokens and various potential web 
APIs can be developed.
- The priority for normal AFCG meetings surrounding the private tokens 
workstream will be on how to use proposed APIs and 
requirements/attestations that would be useful for the Anti-Fraud space. 
Discussions about API specifics and design will primarily be done online 
or in side meetings (or in time slots where the normal AFCG meeting is 
cancelled).
- We invite discussion and work on any private/anonymous token scheme 
*for the web* useful for anti-fraud in the private tokens workstream 
with the previous caveat, as a place to foster discussion prior to being 
moved to a WG for standardization.
-- Near-term, the Private State Token explainer will get updated to be 
more in-line with privacypass (and specifically call out and mention 
where the differences from privacypass are) and then get moved to the 
new workstream.
-- Private Access Token authors are invited to use the workstream to get 
feedback and develop things like permissions policy requirements/etc.

Hence, we are adopting it as a work stream of this CG group. Please 
note, however, that this in an incubation item as we are a CG group ;)

Thank you so much for the discussion and look forward to the work on 
this stream!



On 08/12/2022 23:10, Zucker-Scharff, Aram wrote:
> I fully agree with:
> 
> //
> 
> /What I’d like to ensure is that we adopt work that is specifically 
> trying to converge on unified and interoperable solutions. Adopting 
> variants that are not compatible or interoperable but are otherwise 
> extremely similar seems like something that isn’t valuable to spend CG 
> time on, in my opinion./
> 
> My understanding of the idea of formally setting up a workstream was 
> that the proposals could reach that state and we would be attempting to 
> bring them to that state. I’m aware of the work going on, but lacking in 
> detailed knowledge of the technical details of it. Is the issue here 
> that multiple people believe the proposals outlined are not compatible 
> with or possible to become interoperable with the maturing IETF Privacy 
> Pass work?
> 
> -- Aram Zucker-Scharff
> 
> The Washington Post
> 
> *From: *Jeffrey Yasskin <jyasskin@google.com>
> *Date: *Thursday, December 8, 2022 at 2:10 PM
> *To: *Tommy Pauly <tpauly@apple.com>
> *Cc: *Zucker-Scharff, Aram <Aram.Zucker-Scharff@washpost.com>, 
> public-antifraud@w3.org <public-antifraud@w3.org>, Brian May 
> <bmay@dstillery.com>, Chris Wilson <cwilso@google.com>, Sofía Celi 
> <cherenkov@riseup.net>, Chris Wood <chriswood@cloudflare.com>, Steven 
> Valdez <svaldez@google.com>
> *Subject: *Re: Call for Adoption: Private State Tokens/Private Tokens 
> Work Stream
> 
> 
>   *CAUTION: EXTERNAL SENDER*
> 
> Thanks. We should just be careful to refer to WGLC documents accurately, 
> just like we're careful not to characterize CG documents as if they'd 
> been adopted by a chartered WG.
> 
> On Thu, Dec 8, 2022 at 11:04 AM Tommy Pauly <tpauly@apple.com 
> <mailto:tpauly@apple.com>> wrote:
> 
>     Hi Jeffrey,
> 
>     They’re not RFCs yet, but as I mentioned, they’re “quite mature”, as
>     in they’re already through most of the working group last call
>     process. There likely won’t be any inter op-breaking changes at this
>     point, and even if there are, they’ll be through the IETF process
>     pretty soon, so that the W3C conversations can build on them.
> 
>     The architecture document has completed working group last call:
> 
>     https://datatracker.ietf.org/doc/draft-ietf-privacypass-architecture/ [datatracker.ietf.org] <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-privacypass-architecture/__;!!M9LbjjnYNg9jBDflsQ!CCsJz_KaZnRZP3GSYxV8Da9be-ZyLaOtLtHsQ6ltzRF8PtHwlYTU7pJhkuYgjIsAlu38qY0ap0giIo4w3WC-Px9h4GHH$>
> 
>     And the auth scheme and protocol documents are in / completing
>     working group last call:
> 
>     https://datatracker.ietf.org/doc/draft-ietf-privacypass-auth-scheme/
>     [datatracker.ietf.org]
>     <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-privacypass-auth-scheme/__;!!M9LbjjnYNg9jBDflsQ!CCsJz_KaZnRZP3GSYxV8Da9be-ZyLaOtLtHsQ6ltzRF8PtHwlYTU7pJhkuYgjIsAlu38qY0ap0giIo4w3WC-P6WDMPvW$>
> 
>     https://datatracker.ietf.org/doc/draft-ietf-privacypass-protocol/
>     [datatracker.ietf.org]
>     <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-privacypass-protocol/__;!!M9LbjjnYNg9jBDflsQ!CCsJz_KaZnRZP3GSYxV8Da9be-ZyLaOtLtHsQ6ltzRF8PtHwlYTU7pJhkuYgjIsAlu38qY0ap0giIo4w3WC-P6oYtFUv$>
> 
>     Thanks,
> 
>     Tommy
> 
> 
> 
>         On Dec 8, 2022, at 11:00 AM, Jeffrey Yasskin
>         <jyasskin@google.com <mailto:jyasskin@google.com>> wrote:
> 
>         On Thu, Dec 8, 2022 at 9:51 AM Tommy Pauly <tpauly@apple.com
>         <mailto:tpauly@apple.com>> wrote:
> 
>             ... we do have a solid basis and architecture for algorithms
>             and an extensible architecture for token types that’s quite
>             mature in the IETF PrivacyPass WG. That standardized version
>             of privacy pass ...
> 
>         Tommy, where is the standardized version of privacy pass? The
>         latest I see is
>         https://datatracker.ietf.org/doc/draft-ietf-privacypass-protocol/07/ [datatracker.ietf.org] <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-privacypass-protocol/07/__;!!M9LbjjnYNg9jBDflsQ!CCsJz_KaZnRZP3GSYxV8Da9be-ZyLaOtLtHsQ6ltzRF8PtHwlYTU7pJhkuYgjIsAlu38qY0ap0giIo4w3WC-P4BnnBNA$>, which is not standardized.
> 
>         Thanks,
> 
>         Jeffrey
> 

-- 
Sofía Celi
@claucece
Cryptographic research and implementation at many places, specially Brave.
Chair of hprc at IRTF and anti-fraud at W3C.
Reach me out at: cherenkov@riseup.net
Website: https://sofiaceli.com/
3D0B D6E9 4D51 FBC2 CEF7  F004 C835 5EB9 42BF A1D6

Received on Wednesday, 1 February 2023 00:01:52 UTC