I'm not sure about 8 months ago, but as of May (M101), the origin trial for
Trust Token concluded: https://chromestatus.com/feature/5078049450098688
We are still in the process of updating the API and figuring out next
steps, but in the meantime you can still enable the feature for local
experimen
You'll need "--enable-features=TrustTokens
--enable-blink-features=TrustTokens,TrustTokensAlwaysAllowIssuance
--additional-trust-token-key-commitments={...}"
The "enable-features" flag enables the feature in Chrome, while the
"enable-blink-features" flag enables the feature regardless of a
domain/
It can take between 2 to 8 hours for browsers to pick up the new key
commitments.
The recommended solution for rotating keys is to serve a key commitment
with overlapping keysets.
Chrome will use the oldest 3 (or 3 when using the VOPRF non-private
metadata mode) non-expired keys. So if you have a
(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.
On
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
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
thos
o 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?
>
> On Mon, Mar 20, 2023 at 3:54 PM 'Stev
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?
> On 3/29/23 7:59 PM, 'Steven Valdez' via blink-dev wrote:
>
> The primary features are generally the same,
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
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
>
on 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 t
ll 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.
>>>>&
;>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Eric & PST team
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 12, 2023 at 2:53 PM Mike Taylor
>>>>>&g
s raised, and we plan to
>>>>>>>>>> make the
>>>>>>>>>> following code changes:
>>>>>>>>>>
>>>>>>>>>>-
>>>>>>>>>>
>>>>>>>>
>> managing
>>>>>>>>>>> potential migrations).
>>>>>>>>>>>
>>>>>>>>>>> We have several specification improvements in flight, which will
>>>>>>>>>>> hopefully ad
al feedback in the wild before making
>>>>>>>>>>>> final
>>>>>>>>>>>> decisions on some of the other suggested changes. We believe
>>>>>>>>>>>> we'll be able
>>>>>>>
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 un
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
On Tue, May 16, 2023 at 5:30 AM Mike West wrote:
> LGTM2, with the understanding that cleaning up the developer-facing story
>
18 matches
Mail list logo
