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

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.

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