>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. -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/CANduzxADs4r-902vHUp_y7ZebwnXEJqW1agZLrzt5YW31EoyQw%40mail.gmail.com.
