Trust Token API

[csharrison]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: Trust Token API
• Specification URL: N/A
• Explainer (containing user needs and example code)¹: https://github.com/WICG/trust-token-api
• GitHub issues (if you prefer feedback filed there): https://github.com/dvorak42/trust-token-api/issues
• Tests: N/A
• Primary contacts (and their relationship to the specification): @dvorak42, @csharrison

Further details:

• Relevant time constraints or deadlines: We’d like to discuss this at TPAC (Sept 16, 2019). Other than that no hard time constraints.
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is: No group yet

We recommend the explainer to be in Markdown. On top of the usual information expected in the explainer, it is strongly recommended to add:

• Links to major pieces of multi-stakeholder review or discussion of this specification:
• Links to major unresolved issues or opposition with this specification:
  • See the Future Extensions section in the explainer for a few open problems that would be good to resolve.

You should also know that...

We’re still very early stage here, just looking to get TAG review earlier rather than later.

We'd prefer the TAG provide feedback as (please select one):

• open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

---

Please preview the issue and check that the links work before submitting. In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document.

¹ For background, see our explanation of how to write a good explainer.

[hadleybeeman]

Hello! @hober and I discussed this at our face to face in Cupertino.

Two main points from us:

1. What happens if the issuer is a bad actor?

This design only works in the way you've intended if the issuer is properly anonymising and randomising the tokens. What happens if the issuer isn't a trustworthy organisation?

And since the user has no role in selecting the issuer, the user then gets no say in who that might be. If we end up with an ecosystem of dodgy issuers, can the user protect themselves?

It seems like this could be mitigated by an approach like the one in Web Payments, where the browser keeps a set of payment methods that the user is happy with. The shopping site has a list of payment methods it supports. At purchase time the site supplies its options; the browser picks from those. This is a nice quality: the user agent has a role in choosing. This is the role of the user agent.

We recognise that users can't express their preferences on advertisers at all. Could a similar approach work here?

2. We're concerned about the potential for trust tokens to be used as categories to identify or describe the users.

You've written in the explainer:

The issuer can store a limited amount of metadata in the signature of a nonce by choosing one of a set of keys to use to sign the nonce and providing a zero-knowledge proof that it signed the nonce using a particular key or set of keys.

You say it's a limited amount of metadata: how many bits? Even a small number of bits could be risky with certain bad issuers.

We'll open issues in your github repo; these notes are here so that we have them.

[dvorak42]

(Continuing thread on the trust-token-api issues).

1. The crypto in this scheme is resilient against a bad actor on either side (preventing token forgery from the client and preventing loss of anonymisation from the issuer). The issuer would only be able to subdivide the users of that issuer based on the presence or absence of the token (and in the private metadata case, the value of that bit of information).

There are some issues that can occur if you are running a large number of issuers attempting to be malicious, where each issuer uses the bit of information they have to divide their userbase via different non-trust related metrics. Having a allow/block list that the UA supports would help mitigate this issue.

2. Depending on the use case, different numbers of bits may be reasonable. For the web anti-fraud use case, there are compelling arguments for having one bit (to avoid the presence of a token from telling a malicious actor they've successfully passed the fraud system/captcha/etc), beyond that each UA would need to consider the privacy/usecase tradeoffs carefully. This may interact with ideas such as a privacy budget

[hadleybeeman]

Also, it looks like your use case might be similar to the Verifiable Credentials work. It would be useful to talk to them and determine if you think this is a competing proposal, or where the overlaps/differences are.
@burnburn @stonematt are the chairs.

[dvorak42]

There's a bit of overlap, but for Trust Tokens, we are only looking to propagate a tiny amount of trust information (1 or 2 bits) and the protocol needs to be resilient against bad actors where the issuer tries injecting more information into the token/claim or do other forms of watermarking/fingerprinting of the token issuance/redemption. Given the breadth of scope of information that a verifiable credentials claim contains and the trust in the credential/claim issuer there, these probably are reasonable to remain as separate proposals with different threat models.

Its possible that the redemption attestation portion of Trust Tokens might be adaptable to look like the Verifiable Credentials, though a simple public key signature scheme works fine for that.

[torgo]

@dvorak42 @csharrison we're just trying to make some progress on this issue. While we're doing that, can you let us know if there have been developments recently on the spec, and especially if there is any information on implementations and use of this? Also it looks to us like there is currently no requirement for asking for user permissions. If this is the case, can you expand on the rationale here? It looks to us like this is a very powerful API that cuts across origins, and that potentially violates the same origin principle. We are concerned that users would not be expecting information from one domain to be available to another domain.

[dvorak42]

There has been some work on the spec side for the underlying protocol (Privacy Pass) which is going through the IETF standardization process, and as that updates we'll be updating the Trust Token API design. Initial work has begun on implementing this API in Chromium and we hope to run small-scale experiments with it soon to verify the feasibility of this API and whether it is sufficient for use cases that might need it. We currently don't require user permissions, as the capabilities of this API are currently substantially less than for ordinary 3P content within a page which don't require permissions, we'll likely need a new model if we try to move a lot of these 3P-esque capabilities behind permissions as prompting on every new page visit (even just the CAPTCHA case where you'd need to accept a user permission before using the CAPTCHA or be forced through a longer flow) that uses these capabilities would cause user fatigue.

[hober]

See also mozilla's position on privacy pass

[hober]

the capabilities of this API are currently substantially less than for ordinary 3P content within a page which don't require permissions, we'll likely need a new model if we try to move a lot of these 3P-esque capabilities behind permissions

@atanassov and I took another look at this during our Wellington F2F. We had a bit of trouble parsing your comment; could you try to clarify this bit for us? Specifically, when you say "ordinary 3P content within a page which don't require permissions," could you give us a concrete example? You say that "we'll likely need a new model if we try to move a lot of these 3P-esque capabilities behind permissions". If you look at the current browser landscape, do you think it's reasonable to expect "a lot of these 3P-esque capabilities [to move] behind permissions"? That is, maybe the time to look into finding a new model is now?

[hober]

Hi @dvorak42!

@plinss and I took another look at this in this week's TAG F2F, and we're hoping you could answer some of the questions I asked in my last comment.

[dvorak42]

Sorry, missed the original response.

3P cookies/storage being the current type of content that isn't primarily behind active user permissions. I agree that as the browser landscape moves towards limiting 3P content we need some sort of model, but I'm not sure that using permissions as currently exists is the right approach here. Requiring the user top click through permissions on every page that wants to mitigate fraud/DoS/etc would end up with user fatigue. There's also the question of whether having a new model for these sorts of 3P-esque capabilities should be done on an API by API basis or if there should be a more holistic approach to sorting out how to handle these types of capabilities.

[davidvancleve]

Guten TAG,

Motivated by a likely paucity of tokens available on mobile, we're thinking through ways to expand trust token coverage by supporting on-device token issuance; we'd appreciate expanding the scope of this TAG review to include any more concrete subsequent design for on-device token issuance, too. (Updates to follow in the linked bug, and in edits to docs in the Trust Tokens repository.)

Thanks!

[torgo]

Hi @davidvancleve @csharrison - We're just coming back to this in our virtual f2f. @plinss will potentially open up an issue with you about the tracking potential we see. In the mean time, could you give us a brief update on where things are at with your experimentation using this technology?

[dvorak42]

As a quick update, we've landed the ecosystem/deployment at https://github.com/WICG/trust-token-api/blob/main/DEPLOYMENTS.md. We expect to have the framework doc published in the next few weeks (taking a bit longer to get everything worked out), and will ping this thread once that's landed.

[hober]

Hi,

As we wait for the updated framework doc, I wanted to make sure we mentioned in this thread that (assuming all of the underlying issues can be worked through) we're interested in declarative integration of trust tokens into HTML forms, see #558 for more.

[dvorak42]

We've finally landed the privacy framework document (https://github.com/WICG/trust-token-api/blob/main/PRIVACY_FRAMEWORK.md). There are a number of parameters that UAs will need to set based on their privacy model/principles, at some future point they could be tied into a site's privacy budget to allow for more issuances/redemptions to happen on a site if its not using many other privacy budget impacting features.

I've opened up a couple issues for additional ways to trigger the Trust Token API (form-based triggering could help deal with most of the requirements of issue #558), we're also looking at ways that this can be triggered through HTTP headers, potentially via HTTP Auth requirements for visiting a resources.

[plinss]

For tracking purposes:
WICG/trust-token-api#88
WICG/trust-token-api#89

[hober]

Hi,

Mozilla's position on Privacy Pass says:

[W]e will defer making a firm position until the protocol and the novel cryptographic primitives it relies on have had more thorough security analysis.

Has there been review from independent cryptography experts? Could you point us to it, if so? If not, are you making any effort to get independent review of the cryptography?

[torgo]

@dvorak42 further question: Where does this work go after WICG?

[dvorak42]

The crypto and protocols are in the process of getting standardized in the IETF and getting reviewed via CFRG (for the OPRF crypto primitives).

I'm not sure we know what the best home post-WICG, laterally for ecosystem/broader discussion the antifraud CG might be a good for further discussions, for standardizing and moving down the standardization path, not sure what the best home would be.

[torgo]

Ok thanks @dvorak42 – can you address the question raised by Tess regarding take-up and reception of the IETF specs (and the general issue of multi-stakeholder reception)? Also can I encourage you to have a discussion about where this will go after incubation? WebAppSec maybe? I'm just trying to get an idea.

[dvorak42]

The CFRG spec is on track and seems to have positive support, though the exact parameterization and knobs that will end up getting standardized are still shifting. The PrivacyPass spec recently updated it's charter timeline and focus on specific instantiation of the protocol, we're hoping that the focused approach there might simplify the scope of the work to get more positive signals. On the browser side we've mostly seen experimentation and analysis happening in Chromium and Edge.

Starting up the discussions and seeking advice, but yeah given the nature of the API WebAppSec seems like a potentially good home.

[torgo]

Hi @dvorak42 thanks for the chance to give this important work an early review. We're largely happy with the design and approach. We're still concerned about the multi-stakeholder issue and the dependency on PrivacyPass. We'd like the opportunity to review again when the spec is more concrete. Can you please either open a new issue or ping us and we can re-open this one. In the mean time we're closing this.