Private Access Tokens is roughly based on the Rate Limited privacy pass specification ( https://github.com/ietf-wg-privacypass/draft-ietf-privacypass-rate-limit-tokens/ ).
It is primarily triggered via HTTP-Authentication headers and doesn't have a way of exposing that via a JS API. Developers are expected to have endpoints that provide HTTP-Authentication challenges that trigger the OS to issue/redeem tokens. There's a bit of a discussion of the similarities/differences between the APIs at https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md. There's some overlap between the use cases, but for the CAPTCHA use case, while the platform-level signal is useful, anti-fraud providers tend to want to use additional signals to feed into their decision whether to present something like a CAPTCHA, and being able to store the result of their distillation of the decision in tokens they issue can be useful. On Wed, Apr 5, 2023 at 3:53 AM Yoav Weiss <[email protected]> wrote: > > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUOedJX%2BHs1kHDRGByLPaTV23nDHUCxzbRqDz81hbO0Jw%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/CANduzxBRmxhQ4e_LTK_fDG7e9VKyNCe1EUOmmkkUXmDc02Md_A%40mail.gmail.com.
