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

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
>>
>