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

What I am hearing Chris, Tommy and Aram advocating for is a workstream
focused on employing tokens to develop anti-fraud capabilities which
leverages and builds upon the existing PrivacyPass work; if I'm hearing
that correctly, I'm in favor of the group taking up that effort.

Responding to Steven in the Dec 7 11:25am email: "There also seems to be a
deeper discussion about whether the AFCG should be iterating on and
developing APIs and web features."

I think this AFCG is uniquely suited to identifying and defining fraud on
the web and to developing strategies and capabilities for addressing it.
There is unique value in our mix of perspectives and specific, in depth
understanding of what forms fraud online takes and how it can meaningfully
be addressed. I think we take best advantage of that value by prioritizing
focus on developing enhancements and extensions to existing APIs and web
features to support anti-fraud use-cases rather than taking on full
ownership of APIs and web features.


On Thu, Dec 8, 2022 at 6:10 PM Zucker-Scharff, Aram <
Aram.Zucker-Scharff@washpost.com> 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> 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> wrote:
>
>
>
> On Thu, Dec 8, 2022 at 9:51 AM Tommy Pauly <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
>
>
>
>

-- 


Brian May
Principal Engineer
P: (848) 272-1164