Meaning of labels “vStandard”, “future”; and an update on our approach to GA launch

[etrouton]

We wanted to provide an update on our launch plan with the recent feedback we have received (thank you for all the detailed feedback!). There are several issues we will address and/or implement before launch to GA that involve small but significant code changes, such as the removal of PMB, and many spec related issues where we will clarify and improve the documentation. In general, we are open to considering larger changes to the API, but we feel the best way forward is to proceed with launch to general availability and get hands-on feedback from developers. We hope to continue this discussion and pursue browser standardization, at which point we would carefully transition (if necessary) to adopting the new standard.

We are responding to each issue and are marking with labels that both help communicate our next steps. A few definitions of our labels:

• vStandard: things we think would be potentially in scope as we pursue developing a web standard

• Future: not necessarily tied to a version, but something we want to hear feedback from the ecosystem and are open to extending PSTs to include

We are committed to evolving the API responsibly and are also committed to giving early adopters paths for retaining functionality as we pursue standardization.

[etrouton]

In the event a Standard emerges to replace or augment Private State Tokens, we have discussed at a minimum some steps we can take to reduce developer pain and effort to migrate:

• Being clear on features that are likely to be impacted (e.g. tagging issues as “backwards-incompatible”)
• Having API versioning, though not all new features may be supported with versioning, e.g. decoupling with fetch
• Generally committing to transitioning responsibly, by working with early adopters to retain key functionality and minimize impacts

[chris-wood]

I appreciate the desire to ship now to get something in the hands of people to test, but the shape of this proposal and its APIs are quite different from already shipping software that accomplishes more or less the same goal (Privacy Pass). It seems like very minimal changes could be made to give developers a unified experience across both PST and Privacy Pass now rather than have them develop and possibly maintain two very different branches in the near and long term.

To be maximally clear: is there a technical reason that PST cannot use the standard HTTP authentication mechanism to give origins/redeemers of these things a consistent interface when experimenting with PST and other Privacy Pass technologies?

[dvorak42]

Re: Authentication mechanism, as an additive way of using PST there's no technical reason not to support it (more of a question of implementation), however we still need the ability for sites to trigger redemptions through the current flow of being able to make a fetch with a payload of information along with the token and then be able to resolve the response, be it a successful token redemption or the fallback when a token wasn't available.

[chris-wood]

however we still need the ability for sites to trigger redemptions through the current flow of being able to make a fetch with a payload of information along with the token and then be able to resolve the response, be it a successful token redemption or the fallback when a token wasn't available.

This is possible with the HTTP authentication mechanism. In particular, one can force the server-side challenge, use it to produce a Privacy Pass token, and then turn that token in for something to pass to fetch(). Is there a reason that would not work?