The primary features are generally the same, with some internal
format/wire format changes. Only the clients implementing the API
and the issuers will need to make code changes to update to the
new version, websites calling the fetch/JS APIs will not need to
make any changes. We also believe that the upgrade/deprecation
story should be easier as issuers will need to register to be
issuers in Chrome and we'll have direct paths to communicate with
the smaller set of issuers that will need to make changes.
On Thu, Mar 30, 2023 at 1:27 AM Yoav Weiss
<[email protected]> wrote:
So, you're sticking to the current version (which is an older
version of privacypass) and will switch to the latest version
once it stabilizes?
What's the forward compat story for this as well as future
changes to the privacypass protocol?
On Mon, Mar 20, 2023 at 3:54 PM 'Steven Valdez' via blink-dev
<[email protected]> wrote:
The larger differences between privacypass and PST
include some of the token versions that we are currently
using and that privacypass supports. Even once the core
drafts get standardized (which may still be months out)
we'll need to update drafts for the token types we're
using in PST and get those standardized. We're hoping to
get a list of the differences between the current draft
of privacypass and PST out in the explainer repository,
though that has been delayed a bit getting the spec
document and other I2S requirements sorted out.
On Mon, Mar 20, 2023 at 4:30 AM Mike West
<[email protected]> wrote:
Thanks.
https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md#privacypass-version
suggests that the privacypass versioning concern that
Apple raised in
https://github.com/WebKit/standards-positions/issues/72#issuecomment-1279177030
will be mitigated through the protocol solidifying
nowish, followed by y'all updating the private state
tokens to match. Given
https://datatracker.ietf.org/wg/privacypass/documents/,
it looks like things are generally stable and
proceeding to WG last call. Have y'all considered
adopting the final version of the protocol prior to
shipping? That would avoid the necessity of a future
migration, and remove one avenue of objection others
might have.
Regarding Mozilla, they deferred judgement on both
this API and privacypass
(https://github.com/mozilla/standards-positions/issues/261)
in 2020. Pinging those threads might be helpful in
soliciting an opinion that takes the last 2+ years
into account. :)
-mike
On Fri, Mar 17, 2023 at 8:29 PM Steven Valdez
<[email protected]> wrote:
Folks from Mozilla have done some recent analysis
on the privacypass protocol and some supportive
of the general protocol, however we haven't
gotten any newer signals on whether the PST
system where some sites are issuers and other
sites redeem tokens is of interest to them. Apple
has been pursuing Private Access Tokens, which is
a version of privacypass with the device vendor
acting as the issuing party.
On Fri, Mar 17, 2023 at 12:46 PM 'Mike West' via
blink-dev <[email protected]> wrote:
I'm quite excited to see this ready to ship,
thanks for the work you've put into it over
the years.
Both Mozilla and Apple's positions seem
dependent upon analysis of the underlying
Privacy Pass protocol. Have you had
additional communication with them about how
things are going, since it's been a while
since the initial request in both cases?
-mike
On Friday, March 17, 2023 at 5:35:06 PM UTC+1
Steven Valdez 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).
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/633d35ef-2bd9-43c3-9799-8243ff24d764n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/633d35ef-2bd9-43c3-9799-8243ff24d764n%40chromium.org?utm_medium=email&utm_source=footer>.
--
Steven Valdez | Chrome Privacy Sandbox |
[email protected] | Cambridge, MA
--
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/CANduzxAdWEhA1BkPd7xVRStDqPNRXpsQKdVbtz3CHMiMGToQnw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxAdWEhA1BkPd7xVRStDqPNRXpsQKdVbtz3CHMiMGToQnw%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/CANduzxAkvAi07owonKvrtUYLqfNYC2-WUaOoUKa0HjjoOe6wAA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxAkvAi07owonKvrtUYLqfNYC2-WUaOoUKa0HjjoOe6wAA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
