# Decentralized Identity Authentication with Auditability and Privacy
## 5 Privacy-Preserving Protocol
### Final Protocol
#### 5.2.1 New Token and Its Consistency
## Appendix A

Here, we formally model the final protocol (Section 5.2) under the UC framework [49] by using the ideal-world/real-world paradigm, in which parties are modeled as probabilistic polynomial-time interactive Turing machines. A protocol \(\pi_{\text{DID}}\) is secure if there exists no environment \(\mathcal{Z}\) that can distinguish whether it is interacting with adversary \(\mathcal{A}\) and parties running protocol \(\pi_{\text{DID}}\) or with the ideal process for carrying out the desired task, where the ideal adversary \(\mathcal{S}\) and dummy parties interact with the ideal functionality \(\mathcal{F}_{\text{DID}}\). Every functionality and every protocol invocation should be instantiated with a unique session ID that distinguishes them from other instantiations. More formally, we say that the protocol \(\pi_{\text{DID}}\) emulates the ideal process if, for any adversary \(\mathcal{A}\), there exists a simulator \(\mathcal{S}\) such that for all environments \(\mathcal{Z}\), the ensembles \(\text{IDEAL}_{\mathcal{F}_{\text{DID}},\mathcal{S},\mathcal{Z}}\) and \(\text{REAL}_{\pi_{\text{DID}},\mathcal{A},\mathcal{Z}}\) are computationally indistinguishable, i.e., \(\text{IDEAL}_{\mathcal{F}_{\text{DID}},\mathcal{S},\mathcal{Z}}\approx\text{ REAL}_{\pi_{\text{DID}},\mathcal{A},\mathcal{Z}}\). We outline a security proof in the UC framework to show the registration and authentication subprotocols that match \(\mathcal{F}_{\text{Reg}}\) and \(\mathcal{F}_{\text{Auth}}\) under a concurrent composition. ### UC Modeling of the Final Protocol

**Functionality \(\mathcal{F}_{\text{DID}}\)**: We briefly re-formalize our privacy-perserving protocol with a UC model, which consists of three phases: (1) _initialization_, (2) _registration_, and (3) _authentication_. The functionality \(\mathcal{F}_{\text{DID}}\) is parameterized with the security parameter \(\lambda\) and the algorithms of cryptographic primitives. In the initialization phase, \(\mathcal{F}_{\text{DID}}\) receives a command \((\text{Start},\mathit{sid})\) from the client \(\text{C}_{i}\in\mathcal{C}\) and forwards a notification \((\text{Start},\mathit{sid},\text{C}_{i})\) to the simulator \(\mathcal{S}\) (and stores this session). During registration, it receives a command (Register, \(\text{Sid}\), \(\text{C}_{i}\), \(\mathit{regReq}_{i}\)) from the client \(\text{C}_{i}\in\mathcal{C}\). \(\mathcal{F}_{\text{DID}}\) checks for a possible entry; if not, it makes a new entry \((\mathit{sid},\text{C}_{i},\mathit{regReq}_{i},1)\) and sets \(b_{i}=1\); otherwise, the command is ignored, and it returns (Unregistered, \(\mathit{sid}\), \(\text{C}_{i}\), Error) to \(\text{C}_{i}\) and halts. After that, it forwards the command (Register, \(\mathit{sid}\), \(\text{C}_{i}\), 1) to the adversary \(\mathcal{S}\). Next, it receives \((\text{Corrupt},\mathit{sid},\text{C}_{i})\) from \(\mathcal{S}\), to which it responds with \((\text{Leak},\mathit{sid},\text{C}_{i},\mathit{regReq}_{i})\) and records \((\mathit{sid},\text{C}_{i},\mathit{regReq}_{i}^{\ast})\). In addition, \(\mathcal{F}_{\text{DID}}\) passes the message to \(\text{C}_{i}\) along with the \(\mathit{did}\) and token inclusion proofs (\(\beta^{\mathit{did}}\) and \(\beta^{\mathit{fan}}\), respectively), and it records (Registered, \(\mathit{sid},\text{C}_{i},\mathit{regReq}_{i}\)) (the client \(\text{C}_{i}\) is registered). Finally, in the authentication phase, it receives a command \((\text{Login},\mathit{sid},\text{C}_{i},\mathit{authReq}_{i})\) from \(\text{C}_{i}\in\mathcal{C}\), where \((\mathit{authReq}_{i})_{i=1}^{N}\). The ideal functionality \(\mathcal{F}_{\text{DID}}\) checks for a possible entry \((\mathit{authReq}_{i},1)\) and then sends a notification \((\text{Login},\mathit{sid},\text{C}_{i},\mathit{authReq}_{i})\) to \(\mathcal{S}\) and \(SP\). Otherwise, it outputs \(\bot\) and aborts.