Thanks Eric! A couple of issues Martin Thomson filed and I don't think were addressed are #232 <https://github.com/WICG/trust-token-api/issues/232> and #230 <https://github.com/WICG/trust-token-api/issues/230>. It'd be good to address them in some way. I also noticed that a bunch of issues were addressed, but not closed. It might make it easier to review if the settled discussions were marked as such :)
On Fri, Apr 21, 2023 at 4:31 PM eric trouton <[email protected]> wrote: > Hi all, > > > We wanted to provide an update after reviewing Mozilla’s feedback and a > few rounds of good discussion in the threads. We are making several small > but significant changes based on the suggestions, after which we’d like to > launch Private State Tokens in order to support some anti-fraud use cases > that are currently using 3rd party cookies, so developers don't turn to > fingerprinting as a replacement. This will also let us benefit from > additional feedback in the wild before making final decisions on some of > the other suggested changes. We believe we'll be able to migrate the > ecosystem to whichever option we settle on in the final standard (issue > #235 <https://github.com/WICG/trust-token-api/issues/235> explains our > rationale and approach for how we’re triaging the feedback and managing > potential migrations). > > We have several specification improvements in flight, which will hopefully > address all of the spec concerns raised, and we plan to make the following > code changes: > > - > > Removal Private Metadata Bit from web API (we still intend to keep the > Chromium implementation around to support non-web-visible features; but it > will no longer be available via the Private State Token API) until the > crypto can be standardized. > - > > Update to the current VOPRF version. > - > > Add permissions policy for token issuance to match the existing policy > for token redemption. > - > > Remove 'type' from the API. > > > We are targeting these changes to land in M114. > > Thanks, > > Eric & PST team > > > On Wed, Apr 12, 2023 at 2:53 PM Mike Taylor <[email protected]> > wrote: > >> Whoops, that happened in >> https://github.com/w3ctag/design-reviews/issues/780#issuecomment-1422995031 >> - please ignore. :) >> On 4/12/23 2:37 PM, Mike Taylor wrote: >> >> One other comment, in >> https://github.com/w3ctag/design-reviews/issues/414#issuecomment-975743619 >> - the TAG requested that y'all ping the thread when the spec was more >> concrete (or open a new issue). Probably a good time to do so now. >> On 4/6/23 11:18 AM, Mike Taylor wrote: >> >> Thanks for the response, appreciated. >> On 4/6/23 10:02 AM, Steven Valdez wrote: >> >> Re: Supporting multiple crypto versions, there's no real utility beyond >> compatibility because particular UAs will only select one of the versions >> (based on their preferences), rather than trying to negotiate the crypto >> version. >> >> There's some discussion on standardizing to a RFC version of privacypass, >> however for the actual API surface, the PAT API is primarily triggered via >> HTTP-Authentication and they haven't seen a strong need for a JS API to >> trigger issuance, while for PST we see the other direction where the JS API >> is the primary way of triggering it (since its harder for origins to make >> server-side changes to their header/challenge via HTTP auth compared to >> adding new JS API calls). >> >> On Wed, Apr 5, 2023 at 6:33 PM Mike Taylor <[email protected]> >> wrote: >> >>> Thanks for linking to >>> https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md - it's >>> a really useful doc that I missed on my first read of this Intent. >>> >>> The API OWNERs (Yoav, Alex, Daniel, Philip, myself) were discussing this >>> intent today and had some questions that are partially answered by the >>> PST_VS_PAT doc. Another question - have there been any discussions with >>> Apple on a possible convergence of these APIs? The doc hints at a future >>> unification to create a shared API surface for token issuance/redemption. >>> On 4/5/23 10:03 AM, 'Steven Valdez' via blink-dev wrote: >>> >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxBRmxhQ4e_LTK_fDG7e9VKyNCe1EUOmmkkUXmDc02Md_A%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/0c07740f-e250-772d-5c4b-a2726dc86e81%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0c07740f-e250-772d-5c4b-a2726dc86e81%40chromium.org?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/CAL5BFfXEtEOujuvyMNjZNc5xZpGhxTadtnt1asO_CQJ3629M%3DA%40mail.gmail.com.
