4 ms·

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

by IX-103 4y ago

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 https://www.hcaptcha.com/privacy-pass, they've also been used with Google's trust token proposal.

O__________O 4y ago
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-2018-0026.pdf 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.
LegionMammal978 4y ago
Would these be susceptible to the issuing organization refusing to issue new tokens to some individual?
- O__________O 4y ago
  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/ 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.

by IX-103 4y ago

O__________O 4y ago

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-2018-0026.pdf 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.

LegionMammal978 4y ago

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

O__________O 4y ago
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/ 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.