# Decentralized Identity Authentication with Auditability and Privacy
## 5 Privacy-Preserving Protocol
### Final Protocol
#### 5.2.1 New Token and Its Consistency  
To generate a new token \(tkn\), the client increments the counter and computes the token and its proof as in the previous protocol, i.e., \(\langle tkn,\gamma\rangle\gets VRF_{sk}(cnt)\). We emphasize that, due to the properties of VRFs, the value of each token is unique and deterministic. After a new token is computed, the client has to create proof that this token is consecutive to its previous token \(tkn_{-1}\), which is already logged in the blockchain's token set, but without revealing any information about this token (in particular, this can be proof of the initial token). To accomplish this, we use a non-interactive zero-knowledge computation integrity proofing system (Section 2.3) together with the _Token_ circuit used to conduct the relevant computations (see Section 3). The circuit takes as an input the client's verification key, the current counter, the VRF outputs corresponding to the new and previous tokens, and the inclusion proof of the previous token. Note that only the new token is passed as a public argument; thus, the computation integrity proof will not reveal any other information, such as the client's counter or identity. In the first two lines, the circuit ensures that the tokens are created by an entity that possesses the same secret key \(sk\) and that they are for consecutive values of the counter \(cnt\). The third line validates the inclusion proof \(\beta^{tkn_{-1}}\), thus ensuring that the previous token \(tkn_{-1}\) is indeed in the blockchain. For a new token \(tkn\) and a list of secret arguments (as shown in Algorithm 3), the client generates a computation integrity proof \(\pi\gets zkProce_{z_{pk}}(tkn,w)\), where \(w\) is a witness. The proof will ensure a verifier (i.e., the blockchain platform) that the two tokens are created by using the same secret key and the consecutive counter values, and that the previous token is part of the blockchain. Once the proof is generated, the client is ready to contact the service and conduct the authentication process. Although generating the proof is relatively time-consuming (i.e., seconds), it does not have to be conducted just before the authentication. It can be computed at any point between two consecutive authentications. ```
\(Token\left(\forall vk\right)\), \(tkn\), \(\gamma\), \(\left\lceil\frac{tkn_{-1}}{\gamma}\right\rceil\), \(\beta^{tbm_{-1}}\), \(\gamma\), \(\gamma\), \(\gamma\)



integrity computation proof is correct, calling \(zkVrfy_{z_{\pm k}}(\pi,tkn)\), and that (b) \(tkn\) is not in the token set. These checks ensure the blockchain platform that the new token is not yet added and that it was created with the same secret key and as a consecutive counter of some other (unrevealed) token that has already been logged. After successful validation, the new token is added to the token set, and the blockchain nodes create an inclusion proof \(\beta^{tkn}\), which states that the \(tknReq\) request was processed correctly and the new token is added to the blockchain. The service receives and validates the proof, it sends it to the client (who validates it, too), and proceeds with session establishment. ```
TokenVrfy(\(\pi\), \(tkn\)) assert\(tkn\
ot\in tokenSet\) assert\(zkVrfy_{z_{\pm k}}(\pi,tkn)\) tokenSet.add(\(tkn\))
```

**Algorithm 4**Smart contract method for logging authentication events (the final protocol). The protocol provides auditability, since the client can query the token set from the blockchain for its consecutive tokens or just notice the blockchain's error response (while processing \(tknReq\)) during an authentication. In contrast to the previous protocol, a token added to the token set (except for the registration) has to be accompanied by proof that its preceding token is already in the set (which proves the tokens' continuity with zero knowledge).