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

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