Intent to Prototype: Platform-issued trust tokens
David Van Cleve
Contact emails
dav...@chromium.org, privacy-s...@chromium.org
Explainer
https://github.com/WICG/trust-token-api (specifically, see the section on non-web tokens)
Design doc/Spec
(To be updated with a link to the design doc once the design doc is published.)
This new functionality is in scope for the existing Trust Tokens TAG review.
Summary
The Trust Token API (I2P, I2E) allows sites to encode coarse-grained notions of user trust (a couple bits’ worth) across site boundaries. This change will expand the API to allow 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.
Example: In the key commitment JSON hosted on https://trust-token-issuer.example/keys.json, if the issuer specifies
{ ...,
requestTokensLocallyOn = [“mac”]
}
Later, when a webpage calls fetch(‘https://trust-token-issuer.example’, {
trustToken: { type: ‘token-request’ }
});
on macOS, the browser will attempt to obtain tokens from the platform instead of via a request to the website.
Motivation
Many websites and services that depend on fraud and spam detection presently rely on privacy-invasive techniques such as fingerprinting to identify devices. This proposal introduces a mechanism for the platform to provide a signal via the browser that may be consumed by anti-abuse mechanisms, thus providing a reliable indicator and removing the need for privacy-invasive methods.
Risks
Interoperability and Compatibility
We’ll be evaluating the feature through a series of origin trials to avoid bake-in dependency on the functionality while it is in prototype stage.
Activation
Using Trust Tokens (writ large) is still a little challenging because of the need for server-side infrastructure speaking the protocol and current pace of breaking changes as we iterate during the feature’s origin trial. We’re actively considering ways to ease this integration effort as we’re aware that, the easier the feature is to use, the more, valuable, developer feedback we’ll obtain. As this functionality matures, we’ll also want to advocate for support on as many operating systems as is sensible (given the pertinent security models).
Debuggability
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 plan to integrate with DevTools in the medium term, once the functionality stabilizes and we get a better sense of what information it would be useful to expose through DevTools.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
The core of the logic added---for noticing that particular token operations should be passed to the OS---will be platform-independent. There’ll be some platform-specific code necessary at the actual operating system interface; Chrome is targeting Android for its initial integration.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5699436254593024
Danyao Wang
David Van Cleve
Danyao Wang
> A clarifying question: how does a platform decide when to generate a token? IIUC, the original trust tokens are issued when the user passes some kind of challenge on the token issuing website (e.g. solving a reCAPTCHA), but the semantic meaning of "trust" is depending on the issuer. If the platform was to generate the token, how does it know what "trust" means to this issuer? Since you mention fraud and anti-spam use cases in Motivation, my guess is that the platform issued tokens represent that "this is a human not a bot". Is this actually the case?Thanks for the question! Each token issuer corresponds to some kind of presence on the device (e.g. an installed app), or at least to some kind of device-level configuration that tells how to route the token request.
David Van Cleve
Danyao Wang
TBD! The initial Web Platform change just involves logic for issuers to specify "please ask for these tokens on the device instead of via the usual web request". On the Chrome side, we're starting off with one proof-of-concept Chrome integration on Android (with Play Services). We aren't yet implementing a generic device-level mechanism for the browser to know what kinds of on-device entities can provide tokens (we'll add such a mechanism later).
Erik Anderson
Microsoft is supportive of exploring this idea.
Do you have thoughts on how issuers would determine the actual trust status at redemption time? Is the idea that, for each platform that the issuer origin indicates it wants to use locally-requested tokens on, it has a relationship with the entity generating the underlying platform-based tokens in order to be able to decode the private metadata?
For platforms where the OS doesn’t have native support but where the browser might be able to collect context and mediate with its own issuer to produce something equivalent, would the value in `requestTokensLocallyOn` be a name that is specific to the browser vendor (or perhaps the token creator if multiple browsers share one)?
How would issuers handle the case where they want to combine context they have along with the platform-provided context? Would they need to use two separate issuer endpoints? Or should there be a flow where the issuer can still also issue its own set of tokens and, at redemption time, the two different types of tokens would be provided concurrently?
--
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+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMeJurerpAJQo1yY5RW3We7YxUPrHmxsuh5oHJ0-2znUT7vwSQ%40mail.gmail.com.
David Van Cleve
Thanks, Erik!
> Do you have thoughts on how issuers would determine the actual trust status at redemption time? Is the idea that, for each platform that the issuer origin indicates it wants to use locally-requested tokens on, it has a relationship with the entity generating the underlying platform-based tokens in order to be able to decode the private metadata?
Depending on the setting, these tokens' meanings could be completely public and easily interpretable while still being useful. (Providing attackers an oracle into the result of the issuance process isn't necessarily a dealbreaker.)
> For platforms where the OS doesn’t have native support but where the browser might be able to collect context and mediate with its own issuer to produce something equivalent, would the value in `requestTokensLocallyOn` be a name that is specific to the browser vendor (or perhaps the token creator if multiple browsers share one)?
Erik Anderson
I moved our questions and your responses into the Trust Token API repo issue: https://github.com/WICG/trust-token-api/issues/41. Let’s continue to discuss any spec-level things there. Thanks!
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMeJurenjX%2Bw2i_4EVb1k7Afdmk%2BnAbXCTM%3DOvsUYw81Y0JPNw%40mail.gmail.com.