4 ms·

Agree, still trying to find full explanation, seen it described before. Aside from sharing the token, other issue is if the endpoint cached the token, it’s uniq

Agree, still trying to find full explanation, seen it described before. Aside from sharing the token, other issue is if the endpoint cached the token, it’s unique and could be cross-referenced to deanonymize the user if 3rd-party or government gained access to list of tokens an endpoint collected. Obviously looking for example, but if you’re able to think of an additional issues that need to be accounted for, let me know.

LegionMammal978 4y ago
Yep, that's another thing I was thinking of: if Alice uses the same token all the time for every endpoint, then the endpoints could trivially use that as a unique identifier to track Alice. Perhaps the government could create a service for Alice to create new age tokens whenever she wants. Even then, if the government actively compelling endpoints to hand over their data is within the threat model, the government could inspect any cached temporary tokens to deanonymize the users. This could perhaps be mitigated with some way for users to irreversibly transform the temporary tokens given by the government, but I'm not sure if that's possible while retaining the ability for endpoints to verify the tokens. Overall, though, the sharing problem seems to me to be the biggest issue by far with this scheme. What makes a user an individual human? In current implementations, their unique government ID (perhaps made illegal to falsify) is used for this. But I can't see how individual humans can be distinguished in a privacy-preserving way.
- O__________O 4y ago
  My memory was that the tokens enter a pool of tokens and that neither government or endpoint is able to trace which user used which token and they’re one-time use tokens, so users are unable to share them. Never really gave system much thought at the time, since governments rarely want less data or to provide anonymous access — and average person does not care about anonymous access, in fact, in my experience they want everything logged. Same topic could easily be applied to numerous functions such as border crossings, but governments want to track who is crossing instead of just checking individual authorization to enter.
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.
LegionMammal978 4y ago
Another possible issue, for any scheme that uses government-issued temporary tokens (even blinded tokens) that have an expiration date: the government could stop issuing tokens to a user at any time, preventing them from accessing any gated sites after their current tokens expire.
- O__________O 4y ago
  Agree, more to the point, once some attributes are verified, for example age, it shouldn’t require government to reverify. That said, some attributes should require if needed real-time verification, for example if an individual is legally allowed to drive, enter a country, etc.
  - LegionMammal978 4y ago
    Wouldn't caching verification data require the endpoints to hold user sessions? Thus, if the government withheld verification services for a user, wouldn't it prevent that user from creating new independent sessions on their current endpoints, as well as preventing that user from verifying on new endpoints?
    - O__________O 4y ago
      Not 100% sure understand you, but believe this comment might address your question: https://news.ycombinator.com/item?id=33133749 https://news.ycombinator.com/item?id=33133749 Ideally, endpoints would not even know the specific authentication provider, but that the authentication came from a authentication service that’s authorized to confirm a given identity and related attributes; for example, being over X age is a binary attribute and numerous entities should be able to authenticate that and it be honored by a jurisdiction similar to how passports are uniform.

LegionMammal978 4y ago

Yep, that's another thing I was thinking of: if Alice uses the same token all the time for every endpoint, then the endpoints could trivially use that as a unique identifier to track Alice. Perhaps the government could create a service for Alice to create new age tokens whenever she wants. Even then, if the government actively compelling endpoints to hand over their data is within the threat model, the government could inspect any cached temporary tokens to deanonymize the users. This could perhaps be mitigated with some way for users to irreversibly transform the temporary tokens given by the government, but I'm not sure if that's possible while retaining the ability for endpoints to verify the tokens. Overall, though, the sharing problem seems to me to be the biggest issue by far with this scheme. What makes a user an individual human? In current implementations, their unique government ID (perhaps made illegal to falsify) is used for this. But I can't see how individual humans can be distinguished in a privacy-preserving way.

O__________O 4y ago
My memory was that the tokens enter a pool of tokens and that neither government or endpoint is able to trace which user used which token and they’re one-time use tokens, so users are unable to share them. Never really gave system much thought at the time, since governments rarely want less data or to provide anonymous access — and average person does not care about anonymous access, in fact, in my experience they want everything logged. Same topic could easily be applied to numerous functions such as border crossings, but governments want to track who is crossing instead of just checking individual authorization to enter.

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.

LegionMammal978 4y ago

Another possible issue, for any scheme that uses government-issued temporary tokens (even blinded tokens) that have an expiration date: the government could stop issuing tokens to a user at any time, preventing them from accessing any gated sites after their current tokens expire.

O__________O 4y ago
Agree, more to the point, once some attributes are verified, for example age, it shouldn’t require government to reverify. That said, some attributes should require if needed real-time verification, for example if an individual is legally allowed to drive, enter a country, etc.
- LegionMammal978 4y ago
  Wouldn't caching verification data require the endpoints to hold user sessions? Thus, if the government withheld verification services for a user, wouldn't it prevent that user from creating new independent sessions on their current endpoints, as well as preventing that user from verifying on new endpoints?
  - O__________O 4y ago
    Not 100% sure understand you, but believe this comment might address your question: https://news.ycombinator.com/item?id=33133749 https://news.ycombinator.com/item?id=33133749 Ideally, endpoints would not even know the specific authentication provider, but that the authentication came from a authentication service that’s authorized to confirm a given identity and related attributes; for example, being over X age is a binary attribute and numerous entities should be able to authenticate that and it be honored by a jurisdiction similar to how passports are uniform.