On Fri, Mar 17, 2023 at 5:35 PM Steven Valdez <[email protected]> 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). > Not on you, but do Private-Access-Tokens have something resembling a specification or an explainer, other than marketing material? Do I understand correctly that they are strictly based on protocol-level negotiation, without a JS API? How are developers supposed to interact with them? Is there overlap between the use-cases? (e.g. I would naively think that CAPTCHA avoidance can rely on either/both OS-level and anti-fraud provider attestation) > > 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/CANduzxCC8T5D9WSrvo0yq7Tu7hdAj-YXLwuOyu2DqqkTRoHQRg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxCC8T5D9WSrvo0yq7Tu7hdAj-YXLwuOyu2DqqkTRoHQRg%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/CAL5BFfUOedJX%2BHs1kHDRGByLPaTV23nDHUCxzbRqDz81hbO0Jw%40mail.gmail.com.
