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

On Wed, Dec 7, 2022 at 11:25 AM Steven Valdez <svaldez@google.com> wrote:

> Part of the problem with that approach is that the requirements and how
> the API is used is tied into how the protocol functions and what the
> cryptographic primitives necessary are. Things like what sort of
> public/private metadata requirements are necessary/would be useful for
> various uses of these sorts of tokens, what sort of key commitment
> ecosystems are sustainable on the web, how to integrate the protocol
> messages with the anti-fraud/CAPTCHA flows that would be using them. It
> would be nice if those details could be figured out in some active CG
> before trying to get privacypass to support those features.
>

> Your proposed flow is that the PST spec updates to the latest version of
> privacy pass where it can (probably primarily updating the VOPRF bits) and
> then asks privacypass for extensions to support the current version of PST
> (private metadata, doing issuance/redemption "in-line", proxy server-based
> commitments)? That seems okay, but I would've expected that the privacypass
> chairs would prefer asks resulting from consensus/discussions in an active
> CG vs the less-discussed decisions we made for the API in the WICG).
>

This sounds like we're trying to extract requirements from a solution,
which seems backwards to me. Instead, I think the requirements should help
define the solution. In particular, to help share my mental model, here's
the flow I think will be maximally successful:

1. Scope the problem we're trying to solve and identify requirements that
constrain solutions to that problem. This takes place in the CG and is
driven by contributors of the CG.
2. From the requirements, determine what sort of properties we need from
the Privacy Pass protocol to support the requirements. Work on those
properties, including the new cryptography that's required and protocol
changes that would be needed, takes place outside of the CG and is driven
by those who want to see that work happen.
3. Private State Tokens is updated to align with this version of Privacy
Pass. This doesn't need to be perfect, of course, as it's part of the
group's job to refine things. This happens outside of the CG and is driven
by those that want the work to happen.
4. Adopt and incubate Private State Tokens until it's ready to move to a WG
for standardization. This happens in the CG and is driven by contributors
of the CG.

I think our focus should remain on (1) to unblock the rest of the work and
avoid deadlock. A work stream that's focused on requirements for
privacy-preserving tokens and their applications seems like exactly what we
need to accomplish that goal.

I hope that clarifies my thinking here.

Best,
Chris


> There also seems to be a deeper discussion about whether the AFCG should
> be iterating on and developing APIs and web features. As currently
> chartered, the Community Group is intended "to incubate and develop web
> features and APIs to address {anti-fraud}". Maybe worth having a separate
> discussion if folks think we should recharter to remove that
> goal/responsibility from the CG.
>
> On Wed, Dec 7, 2022 at 10:40 AM Brian May <bmay@dstillery.com> wrote:
>
>> I think I misunderstood Steven's earlier response to which I responded
>> that I was in favor of adoption -- I am generally aligned with Chris Wood's
>> perspective which I think better expressed what I was trying to get at in
>> my original response against adoption.
>>
>> I am in favor of this group developing requirements for anti-fraud uses
>> of tokens and for providing reviews and feedback to API developers so what
>> they produce supports anti-fraud use-cases. I am not in favor of taking on
>> full responsibility for developing APIs, which I think is work better
>> undertaken by groups created for that specific purpose. I think the
>> Anti-fraud CG can best serve the web community by identifying where and how
>> fraud happens and developing models and methods which leverage APIs like
>> Private State Tokens to combat it and that working at the level required to
>> develop APIs would detract from what I consider to be this group's primary
>> interest and value.
>>
>>
>>
>> On Tue, Dec 6, 2022 at 6:25 PM Chris Wood <chriswood@cloudflare.com>
>> wrote:
>>
>>> Hey Chris,
>>>
>>> Please see inline below.
>>>
>>> On Tue, Dec 6, 2022 at 6:03 PM Chris Wilson <cwilso@google.com> wrote:
>>>
>>>> Hey Chris-
>>>>
>>>> It's probably important to note that Community Groups at the W3C are
>>>> for incubation, not final standardization: no matter what a CG calls
>>>> something they're considering - e.g. an "official CG work stream" - it does
>>>> not really have any standing as a "standard" - the W3C has a "standards
>>>> track", that requires a Working Group.  (CG incubations may take their
>>>> products and hand them off to WGs, of course, but the WG has to choose to
>>>> accept them.  Nothing a CG produces can be considered anything beyond an
>>>> informative incubation of an idea.)
>>>>
>>>
>>>> CGs can, of course, choose what they want to work on - the Antifraud CG
>>>> defines its own bar
>>>> <https://antifraudcg.github.io/charter.html#:~:text=To%20be%20adopted%20as%20a%20work%20item>
>>>> for work items in its charter
>>>> <https://antifraudcg.github.io/charter.html>:
>>>>
>>>> "To be adopted as a work item, a proposal should be sent out to the CG
>>>> mailing list, and there must be at least two supporters of the proposal.
>>>> For work items intended to become a web-exposed API, at least one supporter
>>>> should be a browser vendor (as an indication of interest in
>>>> implementation). "
>>>>
>>>>
>>>> This is pretty similar - at least, the first sentence - to the WICG
>>>> <https://wicg.io/> bar for adoption; more than one party must express
>>>> interest in the proposal (WICG doesn't require any party to be a browser
>>>> vendor).  The best reason IMO to move incubations from WICG to another CG
>>>> like AFCG is the community - as I think you implied, this is probably the
>>>> best place to have thoughtful exploration of the solution space and
>>>> requirements.  At any rate, this is not something that should gate at this
>>>> point on whether there are multiple implementers lined up to ship code -
>>>> that bar is absolutely appropriate in W3C standards-track development, but
>>>> it comes much, much later, typically in the Candidate Recommendation stage
>>>> where interoperability is assessed.  Of course, it is best if that support
>>>> is built along the way.
>>>>
>>>
>>> This is all totally reasonable, and I can't really object to something
>>> that's in the charter =) That said, I think my points (2) and (3) still
>>> stand. To try and reiterate, my primary concern here is in losing focus on
>>> what the group can meaningfully accomplish. The hard problems we have to
>>> solve are not how to specify the bits and bobs of an API. Instead they seem
>>> to be (a) figuring out what that API should do, with an emphasis on
>>> requirements, and (b) how it should do it, with an emphasis on reusing
>>> standard technologies defined elsewhere, such as the IETF, with properly
>>> reviewed protocols and cryptography. To give an example, I think it would
>>> be a mistake if this group started trying to specify yet another version of
>>> something like Privacy Pass with different cryptography under the hood.
>>> That work is best done elsewhere.
>>>
>>> I strongly support extending Privacy Pass with the necessary pieces to
>>> support Private State Tokens, and would be supportive of a document that
>>> outsources the hard parts to the proper venue. But what we have now is not
>>> that, and spending the group's time trying to work through that issue does
>>> not seem productive. I would prefer this work be done before adoption.
>>>
>>> Best,
>>> Chris
>>>
>>>
>>>> "The document needs more work" is precisely the kind of reason to adopt
>>>> an incubation like this, to get it in front of the appropriate community of
>>>> interested and informed people to shape and improve it.  If it were baked
>>>> enough to be clearly the right answer, frankly it should not be adopted by
>>>> a CG - it's time to charter and create a WG to take it to Recommendation.
>>>>
>>>> On Tue, Dec 6, 2022 at 1:59 PM Chris Wood <chriswood@cloudflare.com>
>>>> wrote:
>>>>
>>>>> On Tue, Nov 22, 2022 at 12:10 PM Sofía Celi <cherenkov@riseup.net>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> The chairs are starting an adoption process for the Private State
>>>>>> Tokens
>>>>>> proposal:
>>>>>>
>>>>>> https://github.com/WICG/trust-token-api/
>>>>>> https://github.com/antifraudcg/proposals/issues/7
>>>>>>
>>>>>> Given the need for other types of privacy-preserving tokens for the
>>>>>> various capabilities being discussed in the CG, the authors are
>>>>>> asking
>>>>>> to adopt this item as part of a more generic Private Tokens work
>>>>>> stream,
>>>>>> discussing and developing documents for various types of
>>>>>> privacy-preserving tokens (based on privacypass and similar
>>>>>> technology)
>>>>>> that are useful in the anti-fraud space.
>>>>>>
>>>>>> Please respond with any further feedback or support for the document
>>>>>> and
>>>>>> work stream in the next two weeks (try to get your feedback in by
>>>>>> December 7th in time for the next CG meeting), and the chairs will
>>>>>> determine whether there is sufficient support for the document to
>>>>>> adopt
>>>>>> it as an official CG work stream.
>>>>>
>>>>>
>>>>> I support establishing a work stream that's focused on requirements
>>>>> for privacy-preserving tokens and their applications to anti-fraud use
>>>>> cases, though I don't think we should adopt the Private State Tokens
>>>>> document at this time, for three primary reasons:
>>>>>
>>>>> 1. As I understand the situation, Private State Tokens do not yet have
>>>>> wide implementer interest, so it's not clear to me what is the purpose of
>>>>> this group in adopting them. Do other User Agents intend to actually
>>>>> implement them? If so, I'd be more inclined to support alignment here.
>>>>> 2. As Tommy pointed out, Private State Tokens diverge from related
>>>>> standards being developed elsewhere, especially with respect to the
>>>>> underlying protocols and cryptography. The underlying protocols and
>>>>> cryptography need to be specified elsewhere such that it can receive proper
>>>>> review, and I don't think this group is the right place to do it. In my
>>>>> mind, this group -- and the W3C in general -- should focus on use of
>>>>> technologies in a web context.
>>>>> 3. Taking a step back, I see this community group's primary value
>>>>> being in the thoughtful exploration of the solution space and requirements
>>>>> for real world applications. I don't think spending our time discussing
>>>>> mechanical things like APIs helps advance that goal. That is, I think it
>>>>> would just be a distraction and impede our overall progress.
>>>>>
>>>>> I think Private State Tokens is a valuable contribution that helped
>>>>> shape the community's approach and thinking around anti-fraud use cases,
>>>>> but ultimately I think the document needs more work and overall support
>>>>> before it's ready to be adopted by this group.
>>>>>
>>>>> Best,
>>>>> Chris
>>>>>
>>>>
>>
>> --
>>
>>
>> Brian May
>> Principal Engineer
>> P: (848) 272-1164
>>
>
>
> --
>
>  Steven Valdez |  Chrome Privacy Sandbox |  svaldez@google.com |  Cambridge,
> MA
>