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>.
