Private State Token Issuer Request - hCaptcha
Closed this issue · 12 comments
Issuer Name
hCaptcha Issuer
Origin
https://pst-issuer.hcaptcha.com
Contact Email
Key Commitment Endpoint URL
https://pst-issuer.hcaptcha.com/pst/key-commitment
Purpose
To detect bots using trust signals
Disclosure and Acknowledgement
- I understand the technical restrictions on key rotation frequency of 60 days in the PST API.
- 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.
- 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.
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)
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)
@dvorak42 thank you for the feedback,
- fixed the media type
- 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?
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.
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).
Appreciate it, thank you
It appears your endpoint is starting to error out and not providing valid keys.
@dvorak42 we are fixing it at the moment
@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,
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.
Deal, I will double check that it returns non-20x code on error, thank you
@dvorak42 by the way, is there some SLA on allowed downtime in key commitment?