I was having this conversation this morning with Hu on the design of attestation.id where he asked if there is any use of a database on attestation.id, the forthcoming attestation issuer site we are going to make and maintain.
For those who didn't follow the TokenScript weekly meetings (of which I stopped making meeting minutes which typically takes 1~2 hours each week that I no longer could afford), attestation.id is going to be a website that issues attestation on email identifiers, similar to how CACERT.org did email certificates for the last decade and Thawte did before that through their Web-Of-Trust, in the era when Shuttleworth still drove the project and had not moved on to the making of Ubuntu. The difference is that we cryptographically hide the email address in the "certificate" (now called identifier attestation but still based on x.509) so that it can be used on public blockchain like Ethereum.
The part where the identifier attestation state needs to be "remembered is to "remember" the verification code, typically a 6-digit decimal sent in an email to the user.
The easy way is to use a session manager and keep the 6-digit one time code in the session (held by the server memory - lost by reboots). The user has to type the same 6-digit code to get the server to agree to issue an identifier attestation. However, it doesn't allow the use-case where the user opens a link in a different browser than where they requested it, and it doesn't allow the use of micro architect (such as AWS Lambda) unless a state-persisting database is used, which stores the 6-digit one time code until it expires.
The following protocol should allow the return of micro architect as an option or keeping such an option open for future use without much modification.
Assume that the server-side has a static key 𝑠 on top of a signing key which it already has.
When the user requests an attestation, the server sends a signed message 𝑚 to the user, which contains the user's email address and a validity field that times out in a few minutes. In the meanwhile, it sends the user a 6-digit code by email, which is the decimal representation of the first 10 bits of ℎ𝑚𝑎𝑐(𝑠, 𝑚). The static key 𝑠 is not shared with the user.
When the user types the 6-digit code in a web form, the web form submits the message 𝑚 together with its signature to the server in the same POST.
The server verified that the message was signed by its own private key, hence not forged by the user. It then verifies the validity, then computes the first 10 bits of ℎ𝑚𝑎𝑐(𝑠, 𝑚) and checks against the user's input. The user is not able to forge the 6-digits unless she received it by email.
This allows the server to be completely stateless. Just an idea. Do you think it might work or be simplified?
This method would require the user to submit CSR at the same time it submits the 6-digit code, so the server can issue attestation in one go without having to store anything in the session.