> So given that the current spec is not in use, this seems incorrect.
No, that's not what they mean. They just mean that the spec (and for now only the spec, not the implementation) will be amended with an experimental feature, while the implementation will not (yet).
I understand (?) that you are interpreting this as: "we'll later document something that we've already implemented", but this is not the case. That isn't how this project operates, and I'm intimately familiar with the codebase so I'm completely certain they haven't implemented this at all. There is no beginning or even a stub for this feature to land, which is problematic, as an unlinkable signature scheme isn't just a drop-in replacement, but requires careful design. Hence privacy by design.
> If you have a key with the attribute of course you can 'bypass' it, I don't think that's bug.
Anyone of age can make an anonymous age attribute faucet [1] for anyone to use. That it's not technically a bug doesn't make it any less trivial to circumvent. I wouldn't expect the public or even the Commission to make such a distinction. They'll clamor that the solution is broken and that it must be fixed, and at that point I expect the obfuscation and weakening of privacy features to start.
So as we already know that the solution will be trivial to circumvent, it shouldn't be released without at least very clearly and publicly announcing it's limitations. Only if such expectations are correctly set, we have a chance not to end up in a cycle where the open source and privacy story will be abandoned in the name of security.
[1] Because of the linkable signature scheme in principle misuse can be detected by issuers, but this would be in direct contradiction with their privacy claims (namely that the issuer pinky promises not to record any issued credentials or signatures).
> Anyone of age can make an anonymous age attribute faucet [1] for anyone to use. That it's not technically a bug doesn't make it any less trivial to circumvent. I wouldn't expect the public or even the Commission to make such a distinction. They'll clamor that the solution is broken and that it must be fixed, and at that point I expect the obfuscation and weakening of privacy features to start.
I can see this argument, but it has a few caveats:
- The 'faucet', providing infinite key material in an open proxy is also very vulnerable
- If the only attribute is age verification then uniqueness is not required; i.e. you can borrow the key of someone you trust and that should be fine.
- The unlinkability is a requirement from the law itself, i.e. the current implementation cannot be executed upon assuming rule of law holds
No, that's not what they mean. They just mean that the spec (and for now only the spec, not the implementation) will be amended with an experimental feature, while the implementation will not (yet).
I understand (?) that you are interpreting this as: "we'll later document something that we've already implemented", but this is not the case. That isn't how this project operates, and I'm intimately familiar with the codebase so I'm completely certain they haven't implemented this at all. There is no beginning or even a stub for this feature to land, which is problematic, as an unlinkable signature scheme isn't just a drop-in replacement, but requires careful design. Hence privacy by design.
> If you have a key with the attribute of course you can 'bypass' it, I don't think that's bug.
Anyone of age can make an anonymous age attribute faucet [1] for anyone to use. That it's not technically a bug doesn't make it any less trivial to circumvent. I wouldn't expect the public or even the Commission to make such a distinction. They'll clamor that the solution is broken and that it must be fixed, and at that point I expect the obfuscation and weakening of privacy features to start.
So as we already know that the solution will be trivial to circumvent, it shouldn't be released without at least very clearly and publicly announcing it's limitations. Only if such expectations are correctly set, we have a chance not to end up in a cycle where the open source and privacy story will be abandoned in the name of security.
[1] Because of the linkable signature scheme in principle misuse can be detected by issuers, but this would be in direct contradiction with their privacy claims (namely that the issuer pinky promises not to record any issued credentials or signatures).