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

> On Dec 8, 2022, at 9:21 AM, Zucker-Scharff, Aram <Aram.Zucker-Scharff@washpost.com> wrote:
> 
> This all makes sense to me and I’m generally in approval of the antifraud group adopting a workflow to further a unified private state tokens/trust tokens/private tokens/privacypass specification. This work seems particularly vital to support anti fraud work that is needed to maintain commercial systems in a world where the web is becoming more private. Other groups that have discussed this specification have, I think, tended to focus on other features, but the anti-fraud feature is the specific feature this is most needed for and therefore it makes sense to me for this work to become part of the work of the antifraud group.
>  
> That said, I do think that there is interest in seeing some iteration of PST/PT/TT/PP be adopted. I would count my organization among those interested. We’ve seen experimentation and interest from a number of participants. Perhaps we believe that this CG is not the right place to formalize a spec? Or we believe that the spec is not yet mature enough for adoption? I think this CG is the right place to formalize such a spec, but if the spec is not mature enough for adoption that makes sense as objections to adopting the specific proposal. 

I agree that using signed, private/blinded tokens is an important building block of several approaches to anti-fraud. What I want to urge, and what I think Chris’ points are getting at, is that 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, which uses the “PrivateToken” HTTP auth scheme, and establishes a registry of token variants that can be built upon, is intended to provide the basis for W3C work on adopting tokens for use cases, which can include anti-fraud.

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. We should adopt a document once it is aligned in direction, and I hope we can avoid too many more names and terms for the same concepts.

Thanks,
Tommy

>  
> If that is the position that I’m seeing from Chris (I don’t want to put words in their mouth) then I think that is a meaningful objection. However, if the reason is that the proposal is not effectively brought into sync with other proposals that we should synthesize together into a single proposal I do think that could specifically be within the workflow of a CG, preferably this one. It does not have to be on the main workflow, but it should be somewhere and experts and interest seem to be within this group. 
>  
> At the end of the day, my concern is that I’ve thus far been disappointed that there has been more significant progress on some version of this functionality and I would like to see it move forward.
>  
>  
> -- Aram Zucker-Scharff
> The Washington Post
> +1-703-829-0532
>  
>  
> From: Chris Wood <chriswood@cloudflare.com <mailto:chriswood@cloudflare.com>>
> Date: Wednesday, December 7, 2022 at 8:41 PM
> To: Steven Valdez <svaldez@google.com <mailto:svaldez@google.com>>
> Cc: Brian May <bmay@dstillery.com <mailto:bmay@dstillery.com>>, Chris Wilson <cwilso@google.com <mailto:cwilso@google.com>>, Sofía Celi <cherenkov@riseup.net <mailto:cherenkov@riseup.net>>, public-antifraud@w3.org <mailto:public-antifraud@w3.org> <public-antifraud@w3.org <mailto:public-antifraud@w3.org>>
> Subject: Re: Call for Adoption: Private State Tokens/Private Tokens Work Stream
> 
> CAUTION: EXTERNAL SENDER
> 
> On Wed, Dec 7, 2022 at 11:25 AM Steven Valdez <svaldez@google.com <mailto: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 <mailto: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 <mailto:chriswood@cloudflare.com>> wrote:
> Hey Chris,
>  
> Please see inline below.
>  
> On Tue, Dec 6, 2022 at 6:03 PM Chris Wilson <cwilso@google.com <mailto: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 [antifraudcg.github.io] <https://urldefense.com/v3/__https:/antifraudcg.github.io/charter.html*:*:text=To*20be*20adopted*20as*20a*20work*20item__;I34lJSUlJSU!!M9LbjjnYNg9jBDflsQ!EJv2iBtlJfj3eUID742NJEMz0eyjEttcz8epd2xLKgCcbmO-Mlgmv251gKhVw0NphaIc4eOnDfiEAYZVC0A2l7PHa5KzenRkng$> for work items in its charter [antifraudcg.github.io] <https://urldefense.com/v3/__https:/antifraudcg.github.io/charter.html__;!!M9LbjjnYNg9jBDflsQ!EJv2iBtlJfj3eUID742NJEMz0eyjEttcz8epd2xLKgCcbmO-Mlgmv251gKhVw0NphaIc4eOnDfiEAYZVC0A2l7PHa5Jj2xvucA$>:
> "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 [wicg.io] <https://urldefense.com/v3/__https:/wicg.io/__;!!M9LbjjnYNg9jBDflsQ!EJv2iBtlJfj3eUID742NJEMz0eyjEttcz8epd2xLKgCcbmO-Mlgmv251gKhVw0NphaIc4eOnDfiEAYZVC0A2l7PHa5Io8Xt-tw$> 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 <mailto:chriswood@cloudflare.com>> wrote:
> On Tue, Nov 22, 2022 at 12:10 PM Sofía Celi <cherenkov@riseup.net <mailto: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 <tel:(848)%20272-1164>
> 
>  
> -- 
>  
>  Steven Valdez |
>  Chrome Privacy Sandbox |
>  svaldez@google.com <mailto:svaldez@google.com> |
>  Cambridge, MA