Intent to Prototype: Platform-issued trust tokens

466 views
Skip to first unread message

David Van Cleve

unread,
Sep 25, 2020, 12:19:42 PM9/25/20
to blink-dev

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


Requesting approval to ship? No. (We're planning on an origin trial in Chrome 89 and 90.)

Danyao Wang

unread,
Sep 25, 2020, 5:27:16 PM9/25/20
to blink-dev, David Van Cleve
Excited to see more use cases for trust tokens!

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?

David Van Cleve

unread,
Sep 25, 2020, 6:17:14 PM9/25/20
to Danyao Wang, blink-dev
> 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. A couple uses could be communicating a notion of device integrity (e.g. "is this device an emulator?", if there is some device-local service that can make this kind of judgment) or something like "the requesting app was not malware".

Danyao Wang

unread,
Sep 25, 2020, 6:35:09 PM9/25/20
to David Van Cleve, blink-dev
On Fri, Sep 25, 2020 at 6:17 PM David Van Cleve <dav...@chromium.org> wrote:
> 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.

How does a developer specify the device-level configuration?

David Van Cleve

unread,
Sep 25, 2020, 6:48:10 PM9/25/20
to Danyao Wang, blink-dev
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). 

Danyao Wang

unread,
Sep 25, 2020, 6:58:30 PM9/25/20
to David Van Cleve, blink-dev
On Fri, Sep 25, 2020 at 6:48 PM David Van Cleve <dav...@chromium.org> wrote:
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). 

Makes sense. Thanks for explaining! I'd love to see a design doc when one becomes available. :-)

The general pattern of web platform API with multiple backends that may be installed apps is very similar to what we've implemented in Payment Request API (not meant to be a plug :P). I'd be interested to see if there's a good reason to generalize that architecture, since WebID might go down this path as well. But this is definitely not time sensitive and can wait. Good luck with your prototyping! Looking forward to learning more.

Erik Anderson

unread,
Sep 25, 2020, 7:02:17 PM9/25/20
to David Van Cleve, Danyao Wang, blink-dev

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

unread,
Sep 25, 2020, 7:35:24 PM9/25/20
to Erik Anderson, Danyao Wang, blink-dev

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)?


If it seems like this could be a useful feature, we could conceivably change that field down the line to be something that the network and content layers don't need to interpret. The embedder could then make a decision whether to fulfill a given issuance based on the (issuer, requestTokensLocallyOn) combination.

> 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?

I think this really boils down to the specifics of the mechanism for executing an issuance operation on device. Conceivably, this could happen in an environment where the issuer has some issuer-specific state available. If this isn't the case, then it seems like using two kinds of token could make sense: one with the issuer's state and one with the on-device state.


David


Erik Anderson

unread,
Oct 1, 2020, 6:06:21 PM10/1/20
to David Van Cleve, Danyao Wang, blink-dev

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!

David Van Cleve

unread,
Nov 24, 2020, 3:48:51 PM11/24/20
to blink-dev, Erik Anderson, Danyao Wang, blink-dev, David Van Cleve
> 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). 

We received a question (thanks!) asking for a clarification of the mechanics of this initial Android integration. The initial local token issuance logic will be backed by a server-side issuance service.
Reply all
Reply to author
Forward
0 new messages