ayk...@google.com, sva...@chromium.org, kaust...@chromium.org
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.
https://wicg.github.io/trust-token-api
https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit
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. 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.
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.
https://github.com/w3ctag/design-reviews/issues/414 https://github.com/w3ctag/design-reviews/issues/780
No concerns, aside from lack of clear interest from other browsers
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
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 for more information about the differences in the technologies).
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:
N/A
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.
N/A
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.
This API is debuggable via the DevTools Application Data panel and the operations are exposed in the Network panel.
Yes
Yes*, 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.
TrustTokens (in the process of being renamed to PrivateStateTokens)
False
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.
Chrome for desktop: 113
Chrome for Android: 113
Android Webview: 113
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.
https://chromestatus.com/feature/5078049450098688
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
--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/633d35ef-2bd9-43c3-9799-8243ff24d764n%40chromium.org.
Steven Valdez | | Chrome Privacy Sandbox | | sva...@google.com | | Cambridge, MA |
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxAdWEhA1BkPd7xVRStDqPNRXpsQKdVbtz3CHMiMGToQnw%40mail.gmail.com.
Hi Steven,
Is the issuer registration process documented somewhere (I don't see anything in the explainer or spec)?
Also, just to make sure I understand - when the upgrade to the
latest privacy pass draft happens, will that add a new value to
the TokenVersion
enum in the PrivateToken
dict? So existing sites w/ fetch calls to issuers/redeemers can
continue to use the older version "1", as long as it's supported
by the issuers/redeemers?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxAkvAi07owonKvrtUYLqfNYC2-WUaOoUKa0HjjoOe6wAA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxB9WoK8nJ4J_R8L7cyb6JtidzJopoN5xxSdS4--4kbEuQ%40mail.gmail.com.
Thanks - so it seems the value of
Sec-Private-State-Token-Crypto-Version will change, after the
update to the latest privacypass spec happens.
Forgive another naive question - is there any utility for an
issuer/redeemer to support multiple
Sec-Private-State-Token-Crypto-Version versions, besides compat?
Hey Martin,
On 3/31/23 3:38 AM, Martin Thomson wrote:
I will note that the current state of the specification does not seem to match IETF Privacy Pass documents. I think that shipping is premature on that basis.
Mozilla deferred our position on this because the specifications were not in a particularly healthy state at the time. That situation doesn't seem to have changed much.
More concerning is the lack of a widely acceptable key consistency and correctness mechanism. A more rigorous analysis of the information transfer properties of the proposed system will be needed before we can be confident that this is OK to ship.
It would be great if you could file issues with these concerns: https://github.com/WICG/trust-token-api/issues/new
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLxc%3DXb_rRjf0PcjbvQH7i2ctwx1P-etgGsP4NfxJPbd42QtQ%40mail.gmail.com.
Thanks for filing issues!
--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxCC8T5D9WSrvo0yq7Tu7hdAj-YXLwuOyu2DqqkTRoHQRg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUOedJX%2BHs1kHDRGByLPaTV23nDHUCxzbRqDz81hbO0Jw%40mail.gmail.com.
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.
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.
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).
Thanks for the response, appreciated.
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.
Whoops, that happened in
https://github.com/w3ctag/design-reviews/issues/780#issuecomment-1422995031
- please ignore. :)
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 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
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.
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.
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.
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?