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
<https://wicg.github.io/trust-token-api/#enumdef-tokenversion> enum in
the PrivateToken
<https://wicg.github.io/trust-token-api/#dictdef-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?
On 3/29/23 7:59 PM, 'Steven Valdez' via blink-dev wrote:
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>.
--
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/e5c00e0e-7b6d-acfb-c2bf-cebd4a990c55%40chromium.org.
