# Decentralized Identity Authentication with Auditability and Privacy
## 4 Baseline Protocol
### Extended Authentication  
Our protocol extends the standard authentication process. In the authentication phase, the client first derives a new counter \(cnt\) by incrementing it by 1, generates an ephemeral keypair \(\langle vk_{e},sk_{e}\rangle\leftarrow\mathit{KeyGen}(\mathit{1}^{\lambda})\) (a new ephemeral keypair is created in each session, and we describe its purpose later in this section), and creates the requests  
\[cntReq\leftarrow\langle did,cnt,Sig_{sk}(did\|cnt),Sig_{sk_{e}}(did\|cnt), vk_{e}\rangle\] \[authReq\leftarrow\langle\beta^{did},cntReq\rangle\]  
with its \(did\), proof of inclusion of the \(did\), a new (consecutive) counter, and the signatures over \(did\) and \(cnt\). The \(authReq\) request is sent to the service, which, upon receiving the request, verifies the proof of inclusion and the signatures. At this point, the client and service run any authentication protocol that they wish to use. We do not mandate a specific scheme, since we foresee that our protocol will be integrated within existing protocols, such as DIDAuth or a TLS, which may require additional message flows or may provide additional security properties (such as service authentication). However, we require that during the authentication process, the service ensures that the client possesses the secret keys corresponding to its \"long-term\" \(did\) key (\(vk\)) and its ephemeral key \(vk_{e}\). (We also envision that the ephemeral key pair can be used to provide other session security features, such as perfect forward secrecy.) A way of realizing such authentication, similarly to some popular TLS authentication modes, would be to require the client (a) to sign \(vk_{e}\) with \(sk\) and send the corresponding signature to the service and (b) to use \(sk_{e}\) to sign the authentication context, which would contain all exchanged messages and a nonce provided by the service. This \"standard\" authentication phase, which ensures the possession of \(vk\) and \(vk_{e}\), is also part of other protocols that we propose later in this paper (i.e., the protocols from Sections 5.1 and 5.2). After a successful authentication, the service extracts and forwards \(cntReq\) to the blockchain platform, where the _incrementCounter_ smart contract method handles the request, as shown in Algorithm 1. The method verifies (1) the signature and ensures that it belongs to the right \(did\), and (2) the current counter mapped to \(did\) has the value \(cnt-1\), which confirms that there is no occurrence of credential misuse. Once validated, the counter value in the _identity map_ is incremented. Upon successful execution of the code, blockchain nodes create an inclusion proof \(\beta^{cnt}\) (i.e., a statement signed by at least \(f+1\) nodes) that states that the request \(cntReq\) was successfully processed by the platform. The service validates the inclusion proof, as shown in Algorithm 2, and forwards it to the client, who verifies that the inclusion proof is correct and matches the intended \(cntReq\) message. After the process is finished, the service proceeds to establish a session with the client. Signing \(cntReq\) with an ephemeral key prevents replay attacks, thus guaranteeing the client that the blockchain processed their request. Since an adversary can control the service and the client's long-term credentials (i.e., \(sk\)) without signing the request with an ephemeral key, the adversary could create the same \(cntReq\) (even if a random nonce accompanied it), use it to authenticate with an honest service, and replay the blockchain inclusion proof to the client. With an honest service verifying the possession of ephemeral \(sk_{e}\), such a replay attack is impossible. The baseline protocol satisfies the auditability property, since for each authentication event using \(did\), the identity map's entry corresponding to \(did\) is updated with the consecutive counter value. The client can easily audit the consistency between its local counter value with the counter value stored in the identity map to check for any credential misuse.