search

GoogleChrome / private-tokens

Apache License 2.0
39 stars 9 forks source link

Private State Token Issuer Request - hCaptcha #4

Closed aliaksei-imi closed 1 year ago

aliaksei-imi commented 1 year ago

Issuer Name

hCaptcha Issuer

Origin

https://pst-issuer.hcaptcha.com

Contact Email

support@hcaptcha.com

Key Commitment Endpoint URL

https://pst-issuer.hcaptcha.com/pst/key-commitment

Purpose

To detect bots using trust signals

Disclosure and Acknowledgement

  1. I understand the technical restrictions on key rotation frequency of 60 days in the PST API.
  2. I understand that my issuer registration will be valid for a period of six months after the key commitment is accepted, and that I will need to re-register in this repository following that six-month period.
  3. I understand that in the future renewing my registration for this API may have additional requirements, to reduce the risk of abuse by token issuers.
dvorak42 commented 1 year ago

The content looks good, however one of the changes that landed since the origin trial was to require an "application/pst-issuer-directory" content-type/media-type on the key commitments (https://github.com/WICG/trust-token-api/blob/main/spec.bs#L183) to confirm that they're intended to be interpreted as key commitments.

Let me know when you've updated the endpoint and we can rerun the configuration.

(we'll hopefully have some tooling soon to automatically verify that on issue submission)

dvorak42 commented 1 year ago

You'll also want to update the version name to "PrivateStateTokenV1VOPRF". (if you're using libtrusttoken pulling the latest version should have the right format)

aliaksei-imi commented 1 year ago

@dvorak42 thank you for the feedback,

  1. fixed the media type
  2. changed the version to be PrivateStateTokenV1VOPRF

We don't use libtrusttoken, we're using boringssl instead, the keys were generated with TRUST_TOKEN_experiment_v2_voprf and now the code is using TRUST_TOKEN_pst_v1_voprf. It seems like the keys are compatible or do we need to regenerate them using TRUST_TOKEN_pst_v1_voprf?

dvorak42 commented 1 year ago

The key format is compatible, however the issuance/redemption messages have a slightly different serialization/format to bring it closer in-line with the IETF drafts so you should be fine if they were generated with the previous value.

dvorak42 commented 1 year ago

Your keys have been successfully parsed, they should be available in Chrome via component updater in approximately 4 hours (you can force an update if you have an up-to-date M114 with the feature enabled by going to chrome://components/ and hitting "Check for update" under Trust Token Key Commitments).

aliaksei-imi commented 1 year ago

Appreciate it, thank you

dvorak42 commented 1 year ago

It appears your endpoint is starting to error out and not providing valid keys.

aliaksei-imi commented 1 year ago

@dvorak42 we are fixing it at the moment

aliaksei-imi commented 1 year ago

@dvorak42 We were having a network related issue, which is fixed now. The keys are the same as they used to be, sorry for the inconvenvience,

dvorak42 commented 1 year ago

No worries, we might make our fetcher fallback to previous results in case of a network error. If you could have your endpoint respond with a HTTP error code rather than a 200 (if it doesn't already do so) that would be good in case of future issues. We'll update our documentation if we support that fallback.

aliaksei-imi commented 1 year ago

Deal, I will double check that it returns non-20x code on error, thank you

aliaksei-imi commented 1 year ago

@dvorak42 by the way, is there some SLA on allowed downtime in key commitment?