On Fri, May 5, 2023 at 7:14 PM Steven Valdez <[email protected]> wrote:
> Rick: For the spec work, we've merged the type parameter removal into the > spec and have a PR <https://github.com/WICG/trust-token-api/pull/239> to > add the permission policy integration. We've already updated Chrome for > both of those changes. > > Mike: We would be checking enrollment/attestation when the issuer > update/re-register their key commitments rather than on the browser at > run-time, so it wouldn't need defined user-agent behavior. Some mechanism > for verifying attestations on an ongoing basis seems like it would add > additional value, but that would be future work. > Hey Steven! My question was about the developer-facing implications of registering or not. That is, if a developer sends an issuance request to a server that hasn't registered as an issuer, what can they expect to see after calling `fetch(issueRequest)`? Will the request happen, just without additional headers? Will the fetch reject with a network error? Will devtools help guide developers towards enrollment? >From your response, though, it sounds like there might not be any runtime implications to enrollment? I'm not sure I understand why anyone would enroll if that's the case. :) -mike > > > On Wed, May 3, 2023 at 11:45 AM Mike West <[email protected]> wrote: > >> I agree with Rick on the merits, but would point out one aspect of the >> enrollment mechanism that I think does have interop considerations that >> Chromium needs to consider. If embedders have a gate on issuance, we need >> to ensure that both sides of that gate have defined developer-facing >> behavior. It's not clear to me how enrollment status is represented in the >> spec, whether relevant errors are surfaced to developers through devtools, >> etc. Have y'all thought through that distinction from the platform >> perspective? >> >> -mike >> >> >> On Wed, May 3, 2023 at 4:15 AM Rick Byers <[email protected]> wrote: >> >>> Looking through the open issues and Martin's great feedback, it seems >>> pretty clear that there are some significant interoperability risks here >>> still. That said, Chrome's inability to remove 3PCs until we can >>> demonstrate adequate replacements is also an ongoing interop (and privacy) >>> cost for the web. As with most things privacy sandbox related, I'm >>> personally leaning more towards a ship-and-iterate model being less bad >>> than risking delaying the 3PCD timeline >>> <https://privacysandbox.com/open-web/#the-privacy-sandbox-timeline>. >>> >>> That said, it looks like there's at least a little low hanging fruit >>> remaining in spec work. Eg. this issue >>> <https://github.com/WICG/trust-token-api/issues/226> suggests we've >>> implemented an API (permissions policy integration) in chromium that isn't >>> spec'd out, is that right? Permissions policy is usually pretty straight >>> forward to integrate these days, right? Any reason we can't just get that >>> landed in the spec now before shipping? Also there's a few discussions of >>> removing >>> the type parameter <https://github.com/WICG/trust-token-api/issues/222>, >>> can we just do that now to reduce the need for a breaking change analysis >>> in the future? If we can get these spec fixes landed quickly, then I'm >>> personally willing to approve this I2S with the expectation of continued >>> spec investment and cross-browser alignment. >>> >>> There's clearly also a lot to discuss about the enrollment mechanism >>> <https://developer.chrome.com/blog/announce-enrollment-privacy-sandbox/#attestations> >>> shared >>> by a number of privacy sandbox APIs, but I see that as a Chrome >>> implementation detail, not something necessarily subject to the web >>> standards process (though certainly still open to public scrutiny and >>> debate). >>> >>> Rick >>> >>> >>> >>> On Fri, Apr 28, 2023 at 1:23 PM Steven Valdez <[email protected]> >>> wrote: >>> >>>> Thanks for the feedback, I've replied on Github with the reasoning and >>>> to continue the conversation. There's definitely some spec work to make >>>> the registration behavior clearer. >>>> >>>> -Steven >>>> >>>> On Wed, Apr 26, 2023 at 9:59 PM Martin Thomson <[email protected]> wrote: >>>> >>>>> I just raised https://github.com/WICG/trust-token-api/issues/240 >>>>> based on this. I had missed that you were planning to register issuers. >>>>> See the issue for more. >>>>> >>>>> On Thu, Apr 27, 2023 at 6:31 AM Steven Valdez <[email protected]> >>>>> wrote: >>>>> >>>>>> We've added this as a WIP document in the repository: >>>>>> https://github.com/WICG/trust-token-api/blob/main/REGISTRATION.md. >>>>>> >>>>>> While the WICG repo won't be the final resting place for the >>>>>> policy/registration hopefully that works as an interim until we've got >>>>>> the >>>>>> final repo/policy published. >>>>>> >>>>>> On Wed, Apr 26, 2023 at 3:51 PM Rick Byers <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Thanks Steven, sorry I missed that. +1 to getting it on GitHub and >>>>>>> links updated. >>>>>>> >>>>>>> Rick >>>>>>> >>>>>>> On Wed, Apr 26, 2023 at 3:09 PM Mike Taylor <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> On 4/26/23 12:07 PM, Steven Valdez wrote: >>>>>>>> >>>>>>>> From higher in the thread: >>>>>>>> >>>>>>>> The WIP registration document is at >>>>>>>> https://docs.google.com/document/d/1oB_YdRMvQWWAsqXsvxMr4FJCngcSBj2rLJzW15l8a_A/edit?usp=sharing >>>>>>>> . >>>>>>>> >>>>>>>> We're planning on hosting it on a Github repo and using that as the >>>>>>>> source of truth for issuer registrations. >>>>>>>> >>>>>>>> We have a slightly chicken and egg problem where setting up the >>>>>>>> Github repo is reliant on the launch process for this feature. >>>>>>>> >>>>>>>> Even if the feature isn't shipping yet, having the docs/process on >>>>>>>> GitHub (even with a disclaimer as the first line that can be deleted as >>>>>>>> soon as you get approvals) seems like a better immediate outcome than >>>>>>>> having the info in a google doc which doesn't seem to be linked from >>>>>>>> https://github.com/WICG/trust-token-api, >>>>>>>> https://wicg.github.io/trust-token-api/, or >>>>>>>> https://developer.chrome.com/en/docs/privacy-sandbox/trust-tokens/. >>>>>>>> >>>>>>>> Would that be possible? >>>>>>>> >>>>>>>> -Steven >>>>>>>> >>>>>>>> On Wed, Apr 26, 2023 at 11:57 AM Rick Byers <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hey folks, >>>>>>>>> Thanks for driving these improvements and taking Mozilla's >>>>>>>>> feedback seriously. This seems almost ready to ship a V1 to me, modulo >>>>>>>>> Yoav's last comment. >>>>>>>>> >>>>>>>>> Are there current docs somewhere for issuer registration? The >>>>>>>>> chromestatus entry points to this google doc >>>>>>>>> <https://docs.google.com/document/d/1cvUdAmcstH6khLL7OrLde4TnaPaMF1qPp3i-2XR46kU/edit#heading=h.4jz5ms3xrpq1> >>>>>>>>> that >>>>>>>>> says it's obsolete and will be updated. I went through the developer >>>>>>>>> docs >>>>>>>>> <https://developer.chrome.com/en/docs/privacy-sandbox/trust-tokens/>, >>>>>>>>> but couldn't find anything explaining how someone might act as an >>>>>>>>> issuer. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Rick >>>>>>>>> >>>>>>>>> On Tue, Apr 25, 2023 at 8:31 AM Yoav Weiss <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Thanks Eric! >>>>>>>>>> >>>>>>>>>> A couple of issues Martin Thomson filed and I don't think were >>>>>>>>>> addressed are #232 >>>>>>>>>> <https://github.com/WICG/trust-token-api/issues/232> and #230 >>>>>>>>>> <https://github.com/WICG/trust-token-api/issues/230>. It'd be >>>>>>>>>> good to address them in some way. >>>>>>>>>> I also noticed that a bunch of issues were addressed, but not >>>>>>>>>> closed. It might make it easier to review if the settled discussions >>>>>>>>>> were >>>>>>>>>> marked as such :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Apr 21, 2023 at 4:31 PM eric trouton < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> We wanted to provide an update after reviewing Mozilla’s >>>>>>>>>>> feedback and a few rounds of good discussion in the threads. We >>>>>>>>>>> are making >>>>>>>>>>> several small but significant changes based on the suggestions, >>>>>>>>>>> after which >>>>>>>>>>> we’d like to launch Private State Tokens in order to support some >>>>>>>>>>> anti-fraud use cases that are currently using 3rd party cookies, so >>>>>>>>>>> developers don't turn to fingerprinting as a replacement. This >>>>>>>>>>> will also >>>>>>>>>>> let us benefit from additional feedback in the wild before making >>>>>>>>>>> final >>>>>>>>>>> decisions on some of the other suggested changes. We believe we'll >>>>>>>>>>> be able >>>>>>>>>>> to migrate the ecosystem to whichever option we settle on in the >>>>>>>>>>> final >>>>>>>>>>> standard (issue #235 >>>>>>>>>>> <https://github.com/WICG/trust-token-api/issues/235> explains >>>>>>>>>>> our rationale and approach for how we’re triaging the feedback and >>>>>>>>>>> managing >>>>>>>>>>> potential migrations). >>>>>>>>>>> >>>>>>>>>>> We have several specification improvements in flight, which will >>>>>>>>>>> hopefully address all of the spec concerns raised, and we plan to >>>>>>>>>>> make the >>>>>>>>>>> following code changes: >>>>>>>>>>> >>>>>>>>>>> - >>>>>>>>>>> >>>>>>>>>>> Removal Private Metadata Bit from web API (we still intend >>>>>>>>>>> to keep the Chromium implementation around to support >>>>>>>>>>> non-web-visible >>>>>>>>>>> features; but it will no longer be available via the Private >>>>>>>>>>> State Token >>>>>>>>>>> API) until the crypto can be standardized. >>>>>>>>>>> - >>>>>>>>>>> >>>>>>>>>>> Update to the current VOPRF version. >>>>>>>>>>> - >>>>>>>>>>> >>>>>>>>>>> Add permissions policy for token issuance to match the >>>>>>>>>>> existing policy for token redemption. >>>>>>>>>>> - >>>>>>>>>>> >>>>>>>>>>> Remove 'type' from the API. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We are targeting these changes to land in M114. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Eric & PST team >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Apr 12, 2023 at 2:53 PM Mike Taylor < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Whoops, that happened in >>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/780#issuecomment-1422995031 >>>>>>>>>>>> - please ignore. :) >>>>>>>>>>>> On 4/12/23 2:37 PM, Mike Taylor wrote: >>>>>>>>>>>> >>>>>>>>>>>> One other comment, in >>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/414#issuecomment-975743619 >>>>>>>>>>>> - the TAG requested that y'all ping the thread when the spec was >>>>>>>>>>>> more >>>>>>>>>>>> concrete (or open a new issue). Probably a good time to do so now. >>>>>>>>>>>> On 4/6/23 11:18 AM, Mike Taylor wrote: >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the response, appreciated. >>>>>>>>>>>> On 4/6/23 10:02 AM, Steven Valdez wrote: >>>>>>>>>>>> >>>>>>>>>>>> Re: Supporting multiple crypto versions, there's no real >>>>>>>>>>>> utility beyond compatibility because particular UAs will only >>>>>>>>>>>> select one of >>>>>>>>>>>> the versions (based on their preferences), rather than trying to >>>>>>>>>>>> negotiate >>>>>>>>>>>> the crypto version. >>>>>>>>>>>> >>>>>>>>>>>> There's some discussion on standardizing to a RFC version of >>>>>>>>>>>> privacypass, however for the actual API surface, the PAT API is >>>>>>>>>>>> primarily triggered via HTTP-Authentication and they haven't seen >>>>>>>>>>>> a strong >>>>>>>>>>>> need for a JS API to trigger issuance, while for PST we see the >>>>>>>>>>>> other >>>>>>>>>>>> direction where the JS API is the primary way of triggering it >>>>>>>>>>>> (since its >>>>>>>>>>>> harder for origins to make server-side changes to their >>>>>>>>>>>> header/challenge >>>>>>>>>>>> via HTTP auth compared to adding new JS API calls). >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Apr 5, 2023 at 6:33 PM Mike Taylor < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Thanks for linking to >>>>>>>>>>>>> https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md >>>>>>>>>>>>> - it's a really useful doc that I missed on my first read of this >>>>>>>>>>>>> Intent. >>>>>>>>>>>>> >>>>>>>>>>>>> The API OWNERs (Yoav, Alex, Daniel, Philip, myself) were >>>>>>>>>>>>> discussing this intent today and had some questions that are >>>>>>>>>>>>> partially >>>>>>>>>>>>> answered by the PST_VS_PAT doc. Another question - have there >>>>>>>>>>>>> been any >>>>>>>>>>>>> discussions with Apple on a possible convergence of these APIs? >>>>>>>>>>>>> The doc >>>>>>>>>>>>> hints at a future unification to create a shared API surface for >>>>>>>>>>>>> token >>>>>>>>>>>>> issuance/redemption. >>>>>>>>>>>>> On 4/5/23 10:03 AM, 'Steven Valdez' via blink-dev wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Private Access Tokens is roughly based on the Rate Limited >>>>>>>>>>>>> privacy pass specification ( >>>>>>>>>>>>> https://github.com/ietf-wg-privacypass/draft-ietf-privacypass-rate-limit-tokens/ >>>>>>>>>>>>> ). >>>>>>>>>>>>> >>>>>>>>>>>>> It is primarily triggered via HTTP-Authentication headers and >>>>>>>>>>>>> doesn't have a way of exposing that via a JS API. Developers are >>>>>>>>>>>>> expected >>>>>>>>>>>>> to have endpoints that provide HTTP-Authentication challenges >>>>>>>>>>>>> that trigger >>>>>>>>>>>>> the OS to issue/redeem tokens. >>>>>>>>>>>>> >>>>>>>>>>>>> There's a bit of a discussion of the similarities/differences >>>>>>>>>>>>> between the APIs at >>>>>>>>>>>>> https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>>> There's some overlap between the use cases, but for the >>>>>>>>>>>>> CAPTCHA use case, while the platform-level signal is useful, >>>>>>>>>>>>> anti-fraud >>>>>>>>>>>>> providers tend to want to use additional signals to feed into >>>>>>>>>>>>> their >>>>>>>>>>>>> decision whether to present something like a CAPTCHA, and being >>>>>>>>>>>>> able to >>>>>>>>>>>>> store the result of their distillation of the decision in tokens >>>>>>>>>>>>> they issue >>>>>>>>>>>>> can be useful. >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Apr 5, 2023 at 3:53 AM Yoav Weiss < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Mar 17, 2023 at 5:35 PM Steven Valdez < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Contact emails >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [email protected], [email protected], >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Explainer >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/WICG/trust-token-api >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NB: We'll rename the repository to private-state-token-api >>>>>>>>>>>>>>> when it's adopted by the antifraud CG. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Specification >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://wicg.github.io/trust-token-api >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Design docs >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Summary >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The Private State Token API is a new API for propagating >>>>>>>>>>>>>>> user signals across sites, without using cross-site persistent >>>>>>>>>>>>>>> identifiers >>>>>>>>>>>>>>> like third party cookies for anti-fraud purposes. Anti-fraud >>>>>>>>>>>>>>> methods that >>>>>>>>>>>>>>> rely on third party cookies will not work once third party >>>>>>>>>>>>>>> cookies are >>>>>>>>>>>>>>> deprecated. The motivation of this API is to provide a means to >>>>>>>>>>>>>>> fight fraud >>>>>>>>>>>>>>> in a world with no third party cookies. The API prevents >>>>>>>>>>>>>>> cross-site >>>>>>>>>>>>>>> identification by limiting the amount of information stored in >>>>>>>>>>>>>>> a token. >>>>>>>>>>>>>>> Blind signatures prevent the issuer from linking a token >>>>>>>>>>>>>>> redemption to the >>>>>>>>>>>>>>> identity of the user in the issuance context. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Private State Token API does not generate or define >>>>>>>>>>>>>>> anti-fraud signals. This is up to the corresponding first party >>>>>>>>>>>>>>> and the >>>>>>>>>>>>>>> token issuers. The API enforces limits on the information >>>>>>>>>>>>>>> transferred in >>>>>>>>>>>>>>> these signals for privacy concerns. Private State Token API >>>>>>>>>>>>>>> is based on the Privacy Pass protocol from the IETF working >>>>>>>>>>>>>>> group <https://datatracker.ietf.org/wg/privacypass/about/>. >>>>>>>>>>>>>>> It can be considered as a web-exposed form of the Privacy Pass >>>>>>>>>>>>>>> protocols. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The Private State Token API was formerly known as the Trust >>>>>>>>>>>>>>> Token API. It is renamed to more accurately reflect its >>>>>>>>>>>>>>> functionality. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Blink component >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Internals>Network>TrustTokens >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NB: As a part of the process of renaming the Trust Token API >>>>>>>>>>>>>>> to the Private State Token API, the blink component will also >>>>>>>>>>>>>>> be renamed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TAG review >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/414 >>>>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/780 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TAG review status >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No concerns, aside from lack of clear interest from other >>>>>>>>>>>>>>> browsers >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Risks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We intend to update the underlying cryptographic and token >>>>>>>>>>>>>>> issuance protocols to align with the eventual Privacy Pass >>>>>>>>>>>>>>> standard. This >>>>>>>>>>>>>>> will affect compatibility with the small number of token >>>>>>>>>>>>>>> issuers. Private >>>>>>>>>>>>>>> State Token API fetch requests include a token type and >>>>>>>>>>>>>>> version field that enables backward compatibility while >>>>>>>>>>>>>>> allowing possible >>>>>>>>>>>>>>> extensions for future token types and versions. While we >>>>>>>>>>>>>>> will have a standard deprecation path of supporting multiple >>>>>>>>>>>>>>> versions, we >>>>>>>>>>>>>>> expect this to be easier with this API as each issuer using >>>>>>>>>>>>>>> this API will >>>>>>>>>>>>>>> need to register to become an issuer and will provide contact >>>>>>>>>>>>>>> information >>>>>>>>>>>>>>> as part of that process. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Gecko: Defer >>>>>>>>>>>>>>> <https://mozilla.github.io/standards-positions/#trust-token> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> WebKit: Pending ( >>>>>>>>>>>>>>> https://github.com/WebKit/standards-positions/issues/72), >>>>>>>>>>>>>>> already shipping similar technology >>>>>>>>>>>>>>> https://developer.apple.com/news/?id=huqjyh7k (see PST vs. >>>>>>>>>>>>>>> PAT >>>>>>>>>>>>>>> <https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md> >>>>>>>>>>>>>>> for more information about the differences in the technologies). >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Not on you, but do Private-Access-Tokens have something >>>>>>>>>>>>>> resembling a specification or an explainer, other than marketing >>>>>>>>>>>>>> material? >>>>>>>>>>>>>> Do I understand correctly that they are strictly based on >>>>>>>>>>>>>> protocol-level negotiation, without a JS API? How are developers >>>>>>>>>>>>>> supposed >>>>>>>>>>>>>> to interact with them? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is there overlap between the use-cases? (e.g. I would naively >>>>>>>>>>>>>> think that CAPTCHA avoidance can rely on either/both OS-level and >>>>>>>>>>>>>> anti-fraud provider attestation) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Web developers: Positive >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A limited set of developers provided feedback on Private >>>>>>>>>>>>>>> State Tokens, indicating that the tool was valuable for >>>>>>>>>>>>>>> anti-fraud >>>>>>>>>>>>>>> capabilities while also acknowledging some utility challenges >>>>>>>>>>>>>>> (1). Other >>>>>>>>>>>>>>> developers also found that Private State Tokens provided >>>>>>>>>>>>>>> ability for >>>>>>>>>>>>>>> authentication purposes (as illustrated by its use in the >>>>>>>>>>>>>>> Privacy Sandbox >>>>>>>>>>>>>>> k-Anonymity Server) (2). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1: >>>>>>>>>>>>>>> https://github.com/antifraudcg/meetings/blob/main/2022/yahoo-trust-token.pdf >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2: >>>>>>>>>>>>>>> https://github.com/WICG/turtledove/blob/main/FLEDGE_k_anonymity_server.md#abuse-and-invalid-traffic >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Other signals: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ergonomics >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> N/A >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Activation >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Using this feature requires spinning up a (or partner with >>>>>>>>>>>>>>> an existing) Private State Token issuer that can issue and >>>>>>>>>>>>>>> verify trust >>>>>>>>>>>>>>> tokens, which is non-trivial. Verifying properties of the >>>>>>>>>>>>>>> Signed Redemption >>>>>>>>>>>>>>> Record or the client signature requires additional cryptographic >>>>>>>>>>>>>>> operations. It would be beneficial to have server-side >>>>>>>>>>>>>>> libraries that >>>>>>>>>>>>>>> developers can use to help make using this API easier. Sample >>>>>>>>>>>>>>> code can be >>>>>>>>>>>>>>> found at https://github.com/google/libtrusttoken. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Security >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> N/A >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> WebView application risks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does this intent deprecate or change behavior of existing >>>>>>>>>>>>>>> APIs, such that it has potentially high risk for Android >>>>>>>>>>>>>>> WebView-based >>>>>>>>>>>>>>> applications? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As this feature does not deprecate or change behavior of >>>>>>>>>>>>>>> existing APIs, we don't anticipate any risk to WebView-based >>>>>>>>>>>>>>> applications. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Debuggability >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This API is debuggable via the DevTools Application Data >>>>>>>>>>>>>>> panel and the operations are exposed in the Network panel. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes >>>>>>>>>>>>>>> <https://wpt.fyi/results/trust-tokens?label=experimental&label=master&aligned>*, >>>>>>>>>>>>>>> some of the tests are currently failing as renaming/API changes >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> preparation for shipping these feature haven't propagated to >>>>>>>>>>>>>>> those tests >>>>>>>>>>>>>>> yet. Additionally, due to the requirements of having a >>>>>>>>>>>>>>> server-side issuer >>>>>>>>>>>>>>> (with bespoke crypto) to fully test the API, a majority of the >>>>>>>>>>>>>>> testing is >>>>>>>>>>>>>>> done in wpt_internal with a bespoke python implementation of a >>>>>>>>>>>>>>> PST issuer. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Flag name >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TrustTokens (in the process of being renamed to >>>>>>>>>>>>>>> PrivateStateTokens) >>>>>>>>>>>>>>> Requires code in //chrome? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> False >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Non-OSS dependencies >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does the feature depend on any code or APIs outside the >>>>>>>>>>>>>>> Chromium open source repository and its open-source >>>>>>>>>>>>>>> dependencies to >>>>>>>>>>>>>>> function? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes. Token operations are dependent on having the key >>>>>>>>>>>>>>> commitment information configured. Chrome (and Chromium >>>>>>>>>>>>>>> implementations >>>>>>>>>>>>>>> that consume components from component updater) supports this >>>>>>>>>>>>>>> via a >>>>>>>>>>>>>>> component, other clients will need to consume the component or >>>>>>>>>>>>>>> come up with >>>>>>>>>>>>>>> their own method of shipping the key commitment information to >>>>>>>>>>>>>>> the client. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Chrome for desktop: 113 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Chrome for Android: 113 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Android Webview: 113 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Anticipated spec changes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Open questions about a feature may be a source of future web >>>>>>>>>>>>>>> compat or interop issues. Please list open issues (e.g. links >>>>>>>>>>>>>>> to known >>>>>>>>>>>>>>> github issues in the project for the feature specification) >>>>>>>>>>>>>>> whose >>>>>>>>>>>>>>> resolution may introduce web compat/interop risk (e.g., >>>>>>>>>>>>>>> changing to naming >>>>>>>>>>>>>>> or structure of the API in a non-backward-compatible way). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The major feature changes we expect are likely to be around >>>>>>>>>>>>>>> the versions of tokens we support, as other use cases may need >>>>>>>>>>>>>>> differing >>>>>>>>>>>>>>> properties from those provided with the initial API and other >>>>>>>>>>>>>>> format/API >>>>>>>>>>>>>>> changes to align better with standardization and interop (see >>>>>>>>>>>>>>> the Interoperability >>>>>>>>>>>>>>> and Combatibility section up above). Most potentially >>>>>>>>>>>>>>> web-observable changes in our open issues ( >>>>>>>>>>>>>>> https://github.com/WICG/trust-token-api/issues) are around >>>>>>>>>>>>>>> ergonomics of using the APIs and ways to use the API in more >>>>>>>>>>>>>>> locations/manners which should pose minimal compatibility risk >>>>>>>>>>>>>>> to existing >>>>>>>>>>>>>>> users of the API. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://chromestatus.com/feature/5078049450098688 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Links to previous Intent discussions >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Intent to prototype: >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X9sF2uLe9rA >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Intent to experiment: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/UIvia1WwIhk/m/stu7iXTWBwAJ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Intent to extend origin trial: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/fpfbKgJF8Vc/m/aC8HJfGdDwAJ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>>>>>> <https://chromestatus.com/>. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> 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 [email protected] >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxCC8T5D9WSrvo0yq7Tu7hdAj-YXLwuOyu2DqqkTRoHQRg%40mail.gmail.com >>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxCC8T5D9WSrvo0yq7Tu7hdAj-YXLwuOyu2DqqkTRoHQRg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUOedJX%2BHs1kHDRGByLPaTV23nDHUCxzbRqDz81hbO0Jw%40mail.gmail.com >>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUOedJX%2BHs1kHDRGByLPaTV23nDHUCxzbRqDz81hbO0Jw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>> . >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> Steven Valdez | Chrome Privacy Sandbox | [email protected] >>>>>>>>>>>>> | Cambridge, MA >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxBRmxhQ4e_LTK_fDG7e9VKyNCe1EUOmmkkUXmDc02Md_A%40mail.gmail.com >>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxBRmxhQ4e_LTK_fDG7e9VKyNCe1EUOmmkkUXmDc02Md_A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> Steven Valdez | Chrome Privacy Sandbox | [email protected] >>>>>>>>>>>> | Cambridge, MA >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0c07740f-e250-772d-5c4b-a2726dc86e81%40chromium.org >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0c07740f-e250-772d-5c4b-a2726dc86e81%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>> 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 [email protected]. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXEtEOujuvyMNjZNc5xZpGhxTadtnt1asO_CQJ3629M%3DA%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXEtEOujuvyMNjZNc5xZpGhxTadtnt1asO_CQJ3629M%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Steven Valdez | Chrome Privacy Sandbox | [email protected] | >>>>>>>> Cambridge, >>>>>>>> MA >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Steven Valdez | Chrome Privacy Sandbox | [email protected] | >>>>>> Cambridge, >>>>>> MA >>>>>> >>>>> >>>> >>>> -- >>>> >>>> Steven Valdez | Chrome Privacy Sandbox | [email protected] | >>>> Cambridge, >>>> MA >>>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9a6sYbTs8s27%2ByTspAWiodBbkPP0hXSRDo60fLPr8R8A%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9a6sYbTs8s27%2ByTspAWiodBbkPP0hXSRDo60fLPr8R8A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> > > -- > > Steven Valdez | Chrome Privacy Sandbox | [email protected] | Cambridge, > MA > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DeiT_T3NO5hyReA8APB%3DAvFVwa7Ur87n6iQ_YKcqZwc5Q%40mail.gmail.com.
