Re: [w3ctag/design-reviews] Trust Token API (#414)

While we don't have concrete numeric data yet on how effective the API is, the OT and external feedback has indicated that some parts of the API need to have a few more toggles to support various use cases. The largest change has been making the redemption record be a free-form blob that issuers can structure however it most makes sense for specific issuers. This change also introduces the possibility of merging the various redemption flows into one API (the issuer can decide whether or not to return a redemption record, which either matches with the previous 'raw-token-redemption' or 'srr-token-redemption' flows).

We also need to add more explicit support for issuers not necessarily being the first party on an issuing site. For the CAPTCHA use case, the CAPTCHA issuance logic might be embedded in sites as 3P content, and not be the same as the top-level page the user is visiting. Along with potentially optimizing those paths (allow an issuance to also be a redemption in the case that you want a redemption record at the time the issuer is issuing tokens, or you want to use the presence of a redemption record to guide the decision to provide more tokens).

This ties in a bit with the user activation question. The actual mitigation is that we want to have a signal that the user is intentionally navigating to/interacting with the page, rather than this page being loaded in the background or via a long redirect chain through a ton of sites that are issuing tokens. From a user's perspective, the user activation signal is implicit in their use of a web page using the API, rather than an explicit pop up they have to click or prompt they have to interact with.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/414#issuecomment-767667983