The primary features are generally the same, with some internal format/wire format changes. Only the clients implementing the API and the issuers will need to make code changes to update to the new version, websites calling the fetch/JS APIs will not need to make any changes. We also believe that the upgrade/deprecation story should be easier as issuers will need to register to be issuers in Chrome and we'll have direct paths to communicate with the smaller set of issuers that will need to make changes.
On Thu, Mar 30, 2023 at 1:27 AM Yoav Weiss <[email protected]> wrote: > So, you're sticking to the current version (which is an older version of > privacypass) and will switch to the latest version once it stabilizes? > What's the forward compat story for this as well as future changes to the > privacypass protocol? > > On Mon, Mar 20, 2023 at 3:54 PM 'Steven Valdez' via blink-dev < > [email protected]> wrote: > >> The larger differences between privacypass and PST include some of the >> token versions that we are currently using and that privacypass supports. >> Even once the core drafts get standardized (which may still be months out) >> we'll need to update drafts for the token types we're using in PST and get >> those standardized. We're hoping to get a list of the differences between >> the current draft of privacypass and PST out in the explainer repository, >> though that has been delayed a bit getting the spec document and other I2S >> requirements sorted out. >> >> >> >> On Mon, Mar 20, 2023 at 4:30 AM Mike West <[email protected]> wrote: >> >>> Thanks. >>> >>> >>> https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md#privacypass-version >>> suggests that the privacypass versioning concern that Apple raised in >>> https://github.com/WebKit/standards-positions/issues/72#issuecomment-1279177030 >>> will be mitigated through the protocol solidifying nowish, followed by >>> y'all updating the private state tokens to match. Given >>> https://datatracker.ietf.org/wg/privacypass/documents/, it looks like >>> things are generally stable and proceeding to WG last call. Have y'all >>> considered adopting the final version of the protocol prior to shipping? >>> That would avoid the necessity of a future migration, and remove one avenue >>> of objection others might have. >>> >>> Regarding Mozilla, they deferred judgement on both this API and >>> privacypass (https://github.com/mozilla/standards-positions/issues/261) >>> in 2020. Pinging those threads might be helpful in soliciting an opinion >>> that takes the last 2+ years into account. :) >>> >>> -mike >>> >>> >>> On Fri, Mar 17, 2023 at 8:29 PM Steven Valdez <[email protected]> >>> wrote: >>> >>>> Folks from Mozilla have done some recent analysis on the privacypass >>>> protocol and some supportive of the general protocol, however we haven't >>>> gotten any newer signals on whether the PST system where some sites are >>>> issuers and other sites redeem tokens is of interest to them. Apple has >>>> been pursuing Private Access Tokens, which is a version of privacypass with >>>> the device vendor acting as the issuing party. >>>> >>>> On Fri, Mar 17, 2023 at 12:46 PM 'Mike West' via blink-dev < >>>> [email protected]> wrote: >>>> >>>>> I'm quite excited to see this ready to ship, thanks for the work >>>>> you've put into it over the years. >>>>> >>>>> Both Mozilla and Apple's positions seem dependent upon analysis of the >>>>> underlying Privacy Pass protocol. Have you had additional communication >>>>> with them about how things are going, since it's been a while since the >>>>> initial request in both cases? >>>>> >>>>> -mike >>>>> >>>>> On Friday, March 17, 2023 at 5:35:06 PM UTC+1 Steven Valdez wrote: >>>>> >>>>>> Contact emails >>>>>> >>>>>> [email protected], [email protected], [email protected] >>>>>> >>>>>> Explainer >>>>>> >>>>>> https://github.com/WICG/trust-token-api >>>>>> >>>>>> NB: We'll rename the repository to private-state-token-api when it's >>>>>> adopted by the antifraud CG. >>>>>> >>>>>> Specification >>>>>> >>>>>> https://wicg.github.io/trust-token-api >>>>>> >>>>>> Design docs >>>>>> >>>>>> >>>>>> https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit >>>>>> >>>>>> Summary >>>>>> >>>>>> The Private State Token API is a new API for propagating user signals >>>>>> across sites, without using cross-site persistent identifiers like third >>>>>> party cookies for anti-fraud purposes. Anti-fraud methods that rely on >>>>>> third party cookies will not work once third party cookies are >>>>>> deprecated. >>>>>> The motivation of this API is to provide a means to fight fraud in a >>>>>> world >>>>>> with no third party cookies. The API prevents cross-site identification >>>>>> by >>>>>> limiting the amount of information stored in a token. Blind signatures >>>>>> prevent the issuer from linking a token redemption to the identity of the >>>>>> user in the issuance context. >>>>>> >>>>>> Private State Token API does not generate or define anti-fraud >>>>>> signals. This is up to the corresponding first party and the token >>>>>> issuers. >>>>>> The API enforces limits on the information transferred in these signals >>>>>> for >>>>>> privacy concerns. Private State Token API is based on the Privacy >>>>>> Pass protocol from the IETF working group >>>>>> <https://datatracker.ietf.org/wg/privacypass/about/>. It can be >>>>>> considered as a web-exposed form of the Privacy Pass protocols. >>>>>> >>>>>> The Private State Token API was formerly known as the Trust Token >>>>>> API. It is renamed to more accurately reflect its functionality. >>>>>> >>>>>> Blink component >>>>>> >>>>>> Internals>Network>TrustTokens >>>>>> >>>>>> NB: As a part of the process of renaming the Trust Token API to the >>>>>> Private State Token API, the blink component will also be renamed. >>>>>> >>>>>> >>>>>> TAG review >>>>>> >>>>>> https://github.com/w3ctag/design-reviews/issues/414 >>>>>> https://github.com/w3ctag/design-reviews/issues/780 >>>>>> >>>>>> TAG review status >>>>>> >>>>>> No concerns, aside from lack of clear interest from other browsers >>>>>> >>>>>> Risks >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> We intend to update the underlying cryptographic and token issuance >>>>>> protocols to align with the eventual Privacy Pass standard. This will >>>>>> affect compatibility with the small number of token issuers. Private >>>>>> State >>>>>> Token API fetch requests include a token type and version field that >>>>>> enables backward compatibility while allowing possible extensions for >>>>>> future token types and versions. While we will have a standard >>>>>> deprecation path of supporting multiple versions, we expect this to be >>>>>> easier with this API as each issuer using this API will need to register >>>>>> to >>>>>> become an issuer and will provide contact information as part of that >>>>>> process. >>>>>> >>>>>> >>>>>> Gecko: Defer >>>>>> <https://mozilla.github.io/standards-positions/#trust-token> >>>>>> >>>>>> WebKit: Pending ( >>>>>> https://github.com/WebKit/standards-positions/issues/72), already >>>>>> shipping similar technology >>>>>> https://developer.apple.com/news/?id=huqjyh7k (see PST vs. PAT >>>>>> <https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md> >>>>>> for more information about the differences in the technologies). >>>>>> >>>>>> Web developers: Positive >>>>>> >>>>>> A limited set of developers provided feedback on Private State >>>>>> Tokens, indicating that the tool was valuable for anti-fraud capabilities >>>>>> while also acknowledging some utility challenges (1). Other developers >>>>>> also >>>>>> found that Private State Tokens provided ability for authentication >>>>>> purposes (as illustrated by its use in the Privacy Sandbox k-Anonymity >>>>>> Server) (2). >>>>>> >>>>>> 1: >>>>>> https://github.com/antifraudcg/meetings/blob/main/2022/yahoo-trust-token.pdf >>>>>> >>>>>> 2: >>>>>> https://github.com/WICG/turtledove/blob/main/FLEDGE_k_anonymity_server.md#abuse-and-invalid-traffic >>>>>> >>>>>> >>>>>> Other signals: >>>>>> >>>>>> Ergonomics >>>>>> >>>>>> N/A >>>>>> >>>>>> >>>>>> Activation >>>>>> >>>>>> Using this feature requires spinning up a (or partner with an >>>>>> existing) Private State Token issuer that can issue and verify trust >>>>>> tokens, which is non-trivial. Verifying properties of the Signed >>>>>> Redemption >>>>>> Record or the client signature requires additional cryptographic >>>>>> operations. It would be beneficial to have server-side libraries that >>>>>> developers can use to help make using this API easier. Sample code can be >>>>>> found at https://github.com/google/libtrusttoken. >>>>>> >>>>>> >>>>>> >>>>>> Security >>>>>> >>>>>> N/A >>>>>> >>>>>> >>>>>> WebView application risks >>>>>> >>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>> that it has potentially high risk for Android WebView-based applications? >>>>>> >>>>>> As this feature does not deprecate or change behavior of existing >>>>>> APIs, we don't anticipate any risk to WebView-based applications. >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> This API is debuggable via the DevTools Application Data panel and >>>>>> the operations are exposed in the Network panel. >>>>>> >>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>> >>>>>> Yes >>>>>> >>>>>> Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ? >>>>>> >>>>>> Yes >>>>>> <https://wpt.fyi/results/trust-tokens?label=experimental&label=master&aligned>*, >>>>>> some of the tests are currently failing as renaming/API changes in >>>>>> preparation for shipping these feature haven't propagated to those tests >>>>>> yet. Additionally, due to the requirements of having a server-side issuer >>>>>> (with bespoke crypto) to fully test the API, a majority of the testing is >>>>>> done in wpt_internal with a bespoke python implementation of a PST >>>>>> issuer. >>>>>> >>>>>> Flag name >>>>>> >>>>>> TrustTokens (in the process of being renamed to PrivateStateTokens) >>>>>> >>>>>> Requires code in //chrome? >>>>>> >>>>>> False >>>>>> >>>>>> Non-OSS dependencies >>>>>> >>>>>> Does the feature depend on any code or APIs outside the Chromium open >>>>>> source repository and its open-source dependencies to function? >>>>>> >>>>>> Yes. Token operations are dependent on having the key commitment >>>>>> information configured. Chrome (and Chromium implementations that consume >>>>>> components from component updater) supports this via a component, other >>>>>> clients will need to consume the component or come up with their own >>>>>> method >>>>>> of shipping the key commitment information to the client. >>>>>> >>>>>> Estimated milestones >>>>>> >>>>>> Chrome for desktop: 113 >>>>>> >>>>>> Chrome for Android: 113 >>>>>> >>>>>> Android Webview: 113 >>>>>> >>>>>> Anticipated spec changes >>>>>> >>>>>> Open questions about a feature may be a source of future web compat >>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>> issues in the project for the feature specification) whose resolution may >>>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>>> of >>>>>> the API in a non-backward-compatible way). >>>>>> >>>>>> The major feature changes we expect are likely to be around the >>>>>> versions of tokens we support, as other use cases may need differing >>>>>> properties from those provided with the initial API and other format/API >>>>>> changes to align better with standardization and interop (see the >>>>>> Interoperability >>>>>> and Combatibility section up above). Most potentially web-observable >>>>>> changes in our open issues ( >>>>>> https://github.com/WICG/trust-token-api/issues) are around >>>>>> ergonomics of using the APIs and ways to use the API in more >>>>>> locations/manners which should pose minimal compatibility risk to >>>>>> existing >>>>>> users of the API. >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> >>>>>> https://chromestatus.com/feature/5078049450098688 >>>>>> >>>>>> Links to previous Intent discussions >>>>>> >>>>>> Intent to prototype: >>>>>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X9sF2uLe9rA >>>>>> >>>>>> Intent to experiment: >>>>>> >>>>>> >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/UIvia1WwIhk/m/stu7iXTWBwAJ >>>>>> >>>>>> Intent to extend origin trial: >>>>>> >>>>>> >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/fpfbKgJF8Vc/m/aC8HJfGdDwAJ >>>>>> >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.com/>. >>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/633d35ef-2bd9-43c3-9799-8243ff24d764n%40chromium.org >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/633d35ef-2bd9-43c3-9799-8243ff24d764n%40chromium.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> >>>> Steven Valdez | Chrome Privacy Sandbox | [email protected] | >>>> Cambridge, >>>> MA >>>> >>> >> >> -- >> >> Steven Valdez | Chrome Privacy Sandbox | [email protected] | Cambridge, >> MA >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxAdWEhA1BkPd7xVRStDqPNRXpsQKdVbtz3CHMiMGToQnw%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxAdWEhA1BkPd7xVRStDqPNRXpsQKdVbtz3CHMiMGToQnw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- Steven Valdez | Chrome Privacy Sandbox | [email protected] | Cambridge, MA -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxAkvAi07owonKvrtUYLqfNYC2-WUaOoUKa0HjjoOe6wAA%40mail.gmail.com.
