Hacker News Reader

Comment by IX-103 | Hacker News Reader

Unless it's a blinded token. In which case the endpoint cannot match the token that was issued to the token that was spent. They can only verify that the token is valid.

I first saw them used with Clouflare's Privacy Pass https://www.hcaptcha.com/privacy-pass, they've also been used with Google's trust token proposal.

View on HN

Thanks, know I have looked at Privacy Pass before, not 100% sure after quick review of the related links if it covers the all system attributes I described; still looking it over.

For those interested, here’s the related paper covering it:

https://www.petsymposium.org/2018/files/papers/issue3/popets...

And yes, my understanding was tokens entered a pool of one-time tokens and neither the government or endpoint was able to cross reference them to a specific user.

Would these be susceptible to the issuing organization refusing to issue new tokens to some individual?

If you load link below and look for “Problem: Malleability” it say, “ It’s possible to create an arbitrary number of pairs of points that will be verified. The client can create these points by multiplying both T and sT by an arbitrary number a. If the client attempts to redeem aT and a(sT), the server will accept it. This effectively gives the client unlimited redemptions.”

Which to me might mean it might address if user is refused new tokens, it might not account for if the tokens are revoked or the authorizing entity ceased to exist, but the attribute was uniform, for example age.

https://privacypass.github.io/protocol/

All and all, at very least, appears to be an extensive and extendable standard, assuming those involved are reasonable and there’s no conflicting interests.

Reply on news.ycombinator.com