# An SSI-Based Solution to Support Lawful Interception
## 5 Design of the SSI Stack
### Layer 1  
The first layer refers to identifiers and keys. It allows the entities of the system to access (read and/or write) data without relying on a third central authority. This requires introducing a verifiable data ledger, known as theDID Registry.  
In our solution, we selected Sovrin [18] as DID Register, a special-purpose blockchain deployed for SSI. It is a public and permissioned blockchain [27] (accessible to all entities but only authorized parties can write data on it). We store the following information on the blockchain:  
* Public DIDs of LEA, LEMF, and EA: They are the DIDs of the entities playing the role of issuers and verifiers in our approach. They are used by the employee E to establish an off-chain connection with them. Moreover, the public DIDs allow the parties acting as verifiers (i.e., the LEA, the EA, and the LEMF) to obtain the public keys to check a cryptographic proof of ownership of a credential.
* Schema: It defines the format (in terms of allowed attributes) of the credentials released by the issuers. Observe that it does not contain any personal data about the employee E.
* Credential Definition: It is an instance of the Schema including the public keys allowing the verification of the credentials. Similar to the Schema, the Credential Definition does not include any personal data about [PERSON]. The inclusion of the Schema and the Credential Definition at the blockchain level makes the credential exchanges fully decentralized enabling a fast release and verification of the credentials from anywhere.
* Revocation Registry: We include two revocation registers, one managed by the LEA and one managed by the EA. Only the issuer (LEA or EA) can update each register, which links to a Credential Definition. The registers are stored on-chain, but, again, they do not contain any personal data about [PERSON]. As the name suggests, they allow  
Figure 3: Comparison between the general SSI stack (**a**) and its instantiated version (**b**).  
the LEA and the EA to revoke the credentials released to the employee [PERSON] and the LEMF. They are based on the cryptographic accumulator described in Section 4.3. The advantage of this approach is that the LEA and EA do not have to maintain a public API for the revocation, but the entities playing the role of verifiers can check the revocation of the credentials in a decentralized way by accessing the blockchain.
* Agent Authorization Policies: This component implements a mechanism of protection in the case the device of [PERSON] is stolen or lost. In the device used by [PERSON], an agent is installed to exchange proofs of the credentials owned by [PERSON] In the case this device is stolen or lost, a revocation mechanism is enabled. In particular, when [PERSON] authorizes a new agent (device), an authorization key is stored in an on-chain registry. This key is used to sign messages exchanged peer-to-peer between [PERSON] and the other entities. To remove the authorization for an agent, [PERSON] can delete its key from the register.  
It is worth highlighting that the following information is not stored on the blockchain:  
* Private DIDs: They are the DIDs of the actors used in the peer-to-peer connection.
* Private Data: They are personal data about the employee [PERSON]. These data have not been stored even in encrypted form. Indeed, since the data stored on the blockchain are immutable, they could be compromised in the long term.  
To conclude, we observe that our solution leverages Peer DIDs to establish peer-to-peer communications. Even though the selection of the communication protocol regards Layer 2 of the stack, the choice to rely on Peer DIDs is performed at Level 1. In this case, the DID Registry is represented by the digital wallets of the entities generating and storing the Peer DIDs.