I will note that the current state of the specification does not seem to match IETF Privacy Pass documents. I think that shipping is premature on that basis.
Mozilla deferred our position on this because the specifications were not in a particularly healthy state at the time. That situation doesn't seem to have changed much. More concerning is the lack of a widely acceptable key consistency and correctness mechanism. A more rigorous analysis of the information transfer properties of the proposed system will be needed before we can be confident that this is OK to ship. (I'm sorry Steven that I didn't notice this before I had a chance to discuss this in person this week, but I've been overwhelmed and blink-dev isn't something I watch closely.) On Sat, Mar 18, 2023 at 4:29 AM 'Steven Valdez' via blink-dev < [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 > > -- > 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/CANduzxB9WoK8nJ4J_R8L7cyb6JtidzJopoN5xxSdS4--4kbEuQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxB9WoK8nJ4J_R8L7cyb6JtidzJopoN5xxSdS4--4kbEuQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAPLxc%3DXb_rRjf0PcjbvQH7i2ctwx1P-etgGsP4NfxJPbd42QtQ%40mail.gmail.com.
