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 <yoavwe...@chromium.org> wrote:
On Fri, Mar 17, 2023 at 5:35 PM Steven Valdez
<sval...@chromium.org> wrote:
Contact emails
ayk...@google.com, sval...@chromium.org, kaustub...@chromium.org
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 blink-dev+unsubscr...@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
<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 blink-dev+unsubscr...@chromium.org.
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 | sval...@google.com |
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 blink-dev+unsubscr...@chromium.org.
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>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b6ba9323-f008-7039-6147-5e2820639efc%40chromium.org.
