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
<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
<https://wicg.github.io/trust-token-api>
Design docs
https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit
<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/414>https://github.com/w3ctag/design-reviews/issues/780
<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
<https://github.com/WebKit/standards-positions/issues/72>),
already shipping similar technology
https://developer.apple.com/news/?id=huqjyh7k
<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
<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
<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 Combatibilitysection up above).
Most potentially web-observable changes in our open
issues (https://github.com/WICG/trust-token-api/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
<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
<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
<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>.
