Thanks Steven, sorry I missed that. +1 to getting it on GitHub and links updated.
Rick On Wed, Apr 26, 2023 at 3:09 PM Mike Taylor <[email protected]> wrote: > On 4/26/23 12:07 PM, Steven Valdez wrote: > > From higher in the thread: > > The WIP registration document is at > https://docs.google.com/document/d/1oB_YdRMvQWWAsqXsvxMr4FJCngcSBj2rLJzW15l8a_A/edit?usp=sharing > . > > We're planning on hosting it on a Github repo and using that as the source > of truth for issuer registrations. > > We have a slightly chicken and egg problem where setting up the Github > repo is reliant on the launch process for this feature. > > Even if the feature isn't shipping yet, having the docs/process on GitHub > (even with a disclaimer as the first line that can be deleted as soon as > you get approvals) seems like a better immediate outcome than having the > info in a google doc which doesn't seem to be linked from > https://github.com/WICG/trust-token-api, > https://wicg.github.io/trust-token-api/, or > https://developer.chrome.com/en/docs/privacy-sandbox/trust-tokens/. > > Would that be possible? > > -Steven > > On Wed, Apr 26, 2023 at 11:57 AM Rick Byers <[email protected]> wrote: > >> Hey folks, >> Thanks for driving these improvements and taking Mozilla's feedback >> seriously. This seems almost ready to ship a V1 to me, modulo >> Yoav's last comment. >> >> Are there current docs somewhere for issuer registration? The >> chromestatus entry points to this google doc >> <https://docs.google.com/document/d/1cvUdAmcstH6khLL7OrLde4TnaPaMF1qPp3i-2XR46kU/edit#heading=h.4jz5ms3xrpq1> >> that >> says it's obsolete and will be updated. I went through the developer docs >> <https://developer.chrome.com/en/docs/privacy-sandbox/trust-tokens/>, >> but couldn't find anything explaining how someone might act as an issuer. >> >> Thanks, >> Rick >> >> On Tue, Apr 25, 2023 at 8:31 AM Yoav Weiss <[email protected]> >> wrote: >> >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXEtEOujuvyMNjZNc5xZpGhxTadtnt1asO_CQJ3629M%3DA%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/CAFUtAY9o4XOVFDcY846xqe9RoV656aERUyKNpH%3Dh2%2Bet_gCRaA%40mail.gmail.com.
