Let's say that we want to develop a blogging service where only people with an
@example.com email can contribute.
Prior to post submission, the user requests that a large random token be generated by the service and sent to their
email@example.com email. This token is stored in the service's database and can then be used to verify that the person posting a certain message + token combination actually has control over an
@example.com email address.
This works well as long as the user trusts that the service is not associating their email address with the token that they received. However, consider a scenario where a user would like to post something that cannot be traced back to them (by other users [this is easy], or by the service itself [the hard part]).
Is it possible to prove to the service that I own a certain email address (by knowing the contents of an email sent to the address) without allowing the service to associate that email address with a specific secret?
Currently, assuming a benevolent service, it is easy to allow posters to prove that they are the authors of an anonymous post by storing a "signature" alongside each post for all to see. This would be computed as
hash(<posters_email_address>@example.com + <auth_token>) so that at any point, the original author could publicly announce their email and authorization token and the hashes could be checked. With this scheme, each poster is anonymous (if they choose to be) with respect to all other users / viewers of the platform, but critically, there is an unknown possibility that they are not anonymous to the platform (if it chooses to be malicious).
In summary, can we prove to a potentially malicious server that we received some sort of authorization (via access to an email address) in a way that prevents the service from associating that email address with the given token?
Edit: I have done some thinking and it appears as if the person who receives their token via email needs to do something to their token before they send it back to the server in order to make tracing that token back to them impossible. It must be modified in a way where it can't be compared to the original token, but still maintains some property where the server knows that there modified token is derived from some token that it issued.
Clarification: We are not administrators of the
@example.com domain. There is nothing special about this domain other than the fact that we explicitly check that clients have an email registered there.