Intent to Ship: Private State Tokens API

[Steven Valdez]

Contact emails

ayk...@google.com, sva...@chromium.org, kaust...@chromium.org

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

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 for more information about the differences in the technologies).

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?

Yes*, 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.

[Mike West]

I'm quite excited to see this ready to ship, thanks for the work you've put into it over the years.

Both Mozilla and Apple's positions seem dependent upon analysis of the underlying Privacy Pass protocol. Have you had additional communication with them about how things are going, since it's been a while since the initial request in both cases?

-mike

[Steven Valdez]

Folks from Mozilla have done some recent analysis on the privacypass protocol and some supportive of the general protocol, however we haven't gotten any newer signals on whether the PST system where some sites are issuers and other sites redeem tokens is of interest to them. Apple has been pursuing Private Access Tokens, which is a version of privacypass with the device vendor acting as the issuing party.

--
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/633d35ef-2bd9-43c3-9799-8243ff24d764n%40chromium.org.

--

Steven Valdez |

Chrome Privacy Sandbox |

sva...@google.com |

Cambridge, MA

[Mike West]

Thanks.

https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md#privacypass-version suggests that the privacypass versioning concern that Apple raised in https://github.com/WebKit/standards-positions/issues/72#issuecomment-1279177030 will be mitigated through the protocol solidifying nowish, followed by y'all updating the private state tokens to match. Given https://datatracker.ietf.org/wg/privacypass/documents/, it looks like things are generally stable and proceeding to WG last call. Have y'all considered adopting the final version of the protocol prior to shipping? That would avoid the necessity of a future migration, and remove one avenue of objection others might have.

Regarding Mozilla, they deferred judgement on both this API and privacypass (https://github.com/mozilla/standards-positions/issues/261) in 2020. Pinging those threads might be helpful in soliciting an opinion that takes the last 2+ years into account. :)

-mike

[Steven Valdez]

The larger differences between privacypass and PST include some of the token versions that we are currently using and that privacypass supports. Even once the core drafts get standardized (which may still be months out) we'll need to update drafts for the token types we're using in PST and get those standardized. We're hoping to get a list of the differences between the current draft of privacypass and PST out in the explainer repository, though that has been delayed a bit getting the spec document and other I2S requirements sorted out.

[Yoav Weiss]

So, you're sticking to the current version (which is an older version of privacypass) and will switch to the latest version once it stabilizes?

What's the forward compat story for this as well as future changes to the privacypass protocol?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxAdWEhA1BkPd7xVRStDqPNRXpsQKdVbtz3CHMiMGToQnw%40mail.gmail.com.

[Steven Valdez]

The primary features are generally the same, with some internal format/wire format changes. Only the clients implementing the API and the issuers will need to make code changes to update to the new version, websites calling the fetch/JS APIs will not need to make any changes. We also believe that the upgrade/deprecation story should be easier as issuers will need to register to be issuers in Chrome and we'll have direct paths to communicate with the smaller set of issuers that will need to make changes.

[Mike Taylor]

Hi Steven,

Is the issuer registration process documented somewhere (I don't see anything in the explainer or spec)?

Also, just to make sure I understand - when the upgrade to the latest privacy pass draft happens, will that add a new value to the TokenVersion enum in the PrivateToken dict? So existing sites w/ fetch calls to issuers/redeemers can continue to use the older version "1", as long as it's supported by the issuers/redeemers?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxAkvAi07owonKvrtUYLqfNYC2-WUaOoUKa0HjjoOe6wAA%40mail.gmail.com.

[Steven Valdez]

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.

There's a couple of "versions" in the API, the field in the PrivateToken/TokenVersion refers to tokens as exposed to the web API (so if the semantics of how a website interacts with the tokens changes or if the API fields change meaning). We don't expect that either of those changes will be needed to update to the standardized privacypass token versions. Separately there's the cryptographic protocol version (referred to as cryptoProtocolVersion in the spec) which indicates the cryptographic tokens and is sent between the UA and individual issuers (not the websites using the API). That's the version we'd see updated to support the final privacypass spec.

-Steven

[Martin Thomson]

I will note that the current state of the specification does not seem to match IETF Privacy Pass documents.  I think that shipping is premature on that basis.

Mozilla deferred our position on this because the specifications were not in a particularly healthy state at the time.  That situation doesn't seem to have changed much.  More concerning is the lack of a widely acceptable key consistency and correctness mechanism.  A more rigorous analysis of the information transfer properties of the proposed system will be needed before we can be confident that this is OK to ship.

(I'm sorry Steven that I didn't notice this before I had a chance to discuss this in person this week, but I've been overwhelmed and blink-dev isn't something I watch closely.)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxB9WoK8nJ4J_R8L7cyb6JtidzJopoN5xxSdS4--4kbEuQ%40mail.gmail.com.

[Mike Taylor]

Thanks - so it seems the value of Sec-Private-State-Token-Crypto-Version will change, after the update to the latest privacypass spec happens.

Forgive another naive question - is there any utility for an issuer/redeemer to support multiple Sec-Private-State-Token-Crypto-Version versions, besides compat?

[Mike Taylor]

Hey Martin,

On 3/31/23 3:38 AM, Martin Thomson wrote:

I will note that the current state of the specification does not seem to match IETF Privacy Pass documents.  I think that shipping is premature on that basis.

Mozilla deferred our position on this because the specifications were not in a particularly healthy state at the time.  That situation doesn't seem to have changed much. 

I think the spec has improved significantly from where it was just a few months ago, that said...

More concerning is the lack of a widely acceptable key consistency and correctness mechanism.  A more rigorous analysis of the information transfer properties of the proposed system will be needed before we can be confident that this is OK to ship.

It would be great if you could file issues with these concerns: https://github.com/WICG/trust-token-api/issues/new

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLxc%3DXb_rRjf0PcjbvQH7i2ctwx1P-etgGsP4NfxJPbd42QtQ%40mail.gmail.com.

[Martin Thomson]

Hi Mike,

Unfortunately, I think that the specification needs considerable work before it would be considered to be acceptable.  I've started filing issues, but I am finding it rough going.  It is very hard to follow, it lacks basic explanations of key features and their operation (this information is encoded in a labyrinth of algorithms), and I don't think that the design is appropriate.

I still don't understand the proposed consistency mechanism completely (see above), but it looks like the current design is one where issuer commitments are delivered by a user agent vendor to each user agent, using an update or remote configuration system.  This is not a bad way to achieve consistency (and maybe correctness), but it sacrifices other properties that are important, such as avoiding having browser vendors as gatekeepers in the system.  Also, this expectation is not documented.

Perhaps greater familiarity with this will come with time, but as of this moment, I would have to say that this is not ready to be interoperable.  I've opened a few issues with larger concerns, though there are lots of minor things I've found that follow on from each of these.

[Mike Taylor]

Thanks for filing issues!

[Yoav Weiss]

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)

 

--
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/CANduzxCC8T5D9WSrvo0yq7Tu7hdAj-YXLwuOyu2DqqkTRoHQRg%40mail.gmail.com.

[Steven Valdez]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUOedJX%2BHs1kHDRGByLPaTV23nDHUCxzbRqDz81hbO0Jw%40mail.gmail.com.

[Mike Taylor]

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.

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.

[Steven Valdez]

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

[Mike Taylor]

Thanks for the response, appreciated.

[Mike Taylor]

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.

[Mike Taylor]

Whoops, that happened in https://github.com/w3ctag/design-reviews/issues/780#issuecomment-1422995031 - please ignore. :)

[eric trouton]

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

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.

[Yoav Weiss]

Thanks Eric!

A couple of issues Martin Thomson filed and I don't think were addressed are #232 and #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 :)

[Rick Byers]

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 that says it's obsolete and will be updated. I went through the developer docs, but couldn't find anything explaining how someone might act as an issuer. 

Thanks,

   Rick

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.

[Steven Valdez]

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.

-Steven

[Eric Trouton]

Hi Yoav and Rick,

Thanks for pointing out that we were missing a few responses (sorry about that!), but we are all caught up now.  We'll keep an eye out for further discussion within each issue.

Please let us know if you have any other questions, and thanks all for the great feedback!

Eric

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxADs4r-902vHUp_y7ZebwnXEJqW1agZLrzt5YW31EoyQw%40mail.gmail.com.

[Mike Taylor]

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?

[Rick Byers]

Thanks Steven, sorry I missed that. +1 to getting it on GitHub and links updated. 

Rick

[Steven Valdez]

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.

[Martin Thomson]

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.

[Steven Valdez]

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

[Rick Byers]

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. 

That said, it looks like there's at least a little low hanging fruit remaining in spec work. Eg. this issue 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, 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 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

 

[Mike West]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9a6sYbTs8s27%2ByTspAWiodBbkPP0hXSRDo60fLPr8R8A%40mail.gmail.com.

[Steven Valdez]

Rick: For the spec work, we've merged the type parameter removal into the spec and have a PR 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.

[Steven Valdez]

We've merged the permissions policy integration into the spec document.

[Mike West]

On Fri, May 5, 2023 at 7:14 PM Steven Valdez <sva...@google.com> wrote:

Rick: For the spec work, we've merged the type parameter removal into the spec and have a PR 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. :)

[Steven Valdez]

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.

[Mike Taylor]

LGTM1 % resolving the following spec issues:

https://github.com/WICG/trust-token-api/issues/232

https://github.com/WICG/trust-token-api/issues/230

On Wed, May 10, 2023 at 5:52 AM Mike West <mk...@chromium.org> wrote:

Will devtools help guide developers towards enrollment?

Also I think Mike's question on devtools support is worth answering.

[Steven Valdez]

Thanks, we'll work on fixing those two issues.

I'm not sure what the general flow for enrollment in DevTools will look like, but if there's a general flow to detect when enrollment is missing for other APIs that check at runtime, we can try to integrate with that when PST calls are made with an unregistered issuer.

[Mike West]

LGTM2, with the understanding that cleaning up the developer-facing story around this work is important. I think the unenrolled case probably falls into step ~8  of https://wicg.github.io/trust-token-api/#issue-request, in which case I think the web-facing behavior is clearly-enough specified. I'd like y'all to make sure that that failure mode is debuggable, which I'm happy for you to wrap into a larger story around enrollment in devtools if that's what you land on when working with that team.

Thanks!

-mike

[Steven Valdez]

We've filed crbug.com/1445984 to keep track of that and will update the developer articles to point more explicitly to the failure condition/requirements there.

-Steven

[Yoav Weiss]

LGTM3

[Rick Byers]

LGTM4 FWIW. Thank you for working through these issues Steven!

Rick

--

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/325d36cb-52a4-4c2e-8124-09036014cbcbn%40chromium.org.

[Steven Valdez]

As an update, we're currently shipping to 1% to collect metrics to ensure this feature does not regress core web vitals, before ramping up the rollout to 100% in the coming weeks.

[Mike Taylor]

Side note: is there anything blocking https://github.com/WICG/trust-token-api/pull/257 from landing?

[Johann Hofmann]

It looks like it needs review, and I'm one of the assigned reviewers... Sorry that I missed this. I'll take a look.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/db001cd5-8d9a-0e3c-83fa-decf3a17d592%40chromium.org.

[Steven Valdez]

(sending as a late FYI update as we discovered we never updated the blink-dev thread post ramp-up)

Private State Tokens have been enabled for 100% of Chrome 114+ users. The feature is also  enabled by default on the Chromium tip-of-tree as of July, which corresponds to the Chrome 117 release.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4iGC4NAn9q3ZF7HN%3DniSC9Np815Qcku0VnANwXAfAHx3Q%40mail.gmail.com.