We’re putting the final touches on a draft spec for the Trust Token API writ large, and adding the functionality covered in this intent would involve a small delta relative to that draft.
In M89, we’ll be releasing an update to the Chrome functionality covered by the Trust Tokens origin trial, providing two distinct additional components:
The “Platform-Provided Trust Tokens” expansion to the Trust Token API’s configuration surface, allowing issuing websites to request that browsers attempt to execute corresponding Trust Tokens operations against the platform environment the browser is operating in: for instance, via some kind of system API or IPC to a system service.
A concrete Chrome implementation routing platform-provided trust token issuance requests with domain https://attestation.android.com to a prototype Android subsystem issuing tokens.
This single-purpose Chrome implementation is in lieu of a generic mechanism for discovering arbitrary device-local providers capable of satisfying platform-provided trust token issuance requests, which is future work.
Link to “Intent to Prototype” blink-dev discussion: https://groups.google.com/a/chromium.org/g/blink-dev/c/SlLdc64lvpM
Goals for experimentation
Just like for standard “web-issued” trust tokens, we’d like to understand the value that tokens incorporating on-device state provide to anti-spam and -abuse systems. (More in the design doc’s metrics plan.) We’ll also evaluate the feature’s performance characteristics relative to web-issued trust tokens.
Experimental timeline: This change will be available in M89 and shares the Trust Tokens origin trial’s end date (ending in M91).
Any risks when the experiment finishes?
We don’t expect developers to develop a production reliance on tokens’ embedded information during this origin trial, because trust tokens are harder to use and contain far less information than third-party cookies, a currently available web feature (the benefit being that trust tokens are much better for privacy). Further, since Trust Tokens is independently gated by a base::Feature, origin trial participants still see the API unavailable for a substantial majority of their users.
Manually activating the feature: Chromium >= 89 gains a new dropdown option under the Trust Token API chrome://flags flag. Choose the "Enabled with platform-provided trust token issuance" option to activate the new functionality covered by this intent.
Client-side view of operations’ results: For Trust Tokens in general, we’re providing debuggability during its origin trial by exposing a rich event history through Chromium’s NetLog system. We’ve updated this NetLog support with specific event outcomes related to locally-delegated issuance operations. We’re also working on adding DevTools support for Trust Tokens; as of writing, the Application panel provides visibility into the results of Trust Tokens issuance operations.
Interpreting tokens: We’ll shortly be releasing a guide describing how to map obtained https://attestation.android.com tokens’ contents (more specifically, the corresponding redemption records’ body.metadata.public fields’ values) to their meanings; we’ll update this thread when we do.
Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?
The core of the logic added---for noticing that particular token operations should be passed to the OS---is platform-independent, but it’s necessary to have platform-specific branching at the actual operating system interface; the (trial) Chrome integration with https://attestation.android.com tokens is Android-specific. We’re also working on generalizing the feature support from just Chrome to Chrome and Android WebView; this won’t make M89, but it might be available for the second and third releases of the origin trial, M90 and M91.