We'll treat the fetch as if there weren't any issuer key commitments were empty (since technically we don't surface the difference between an issuer registration not being available due to the key endpoint not returning anything versus never being added in the first place because they didn't update their registration), for issuance/redemption the fetch fails with an error, while for trying to attach a redemption record, the fetch happens without the headers being attached.
If enrollment gets integrated with registering an issuer's key commitments, then without enrolling the issuer wouldn't function since we wouldn't include the key commitments to Chrome clients. On Wed, May 10, 2023 at 5:52 AM Mike West <[email protected]> wrote: > 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 >> > -- 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/CANduzxBiR9FJv3%2BcT1fQzyrYucjKA9A%3DH0w2G1JZRnskO8K9RA%40mail.gmail.com.
