## 4 Model Proposal
### DID Document and Medical Reports as Verifiable Credentials  
The proposal relies on the smart contract _EthereumDIDRegistry.sol_, based on ERC1056, a standard for creating and updating SSIs. This contract uses the blockchain, using its resources in a lightweight way (refs. [37; 38]). Through the interactions with the smart contract _EthereumDIDRegistry.sol_, and through the events emitted by it, the DDO of a given DID is built using the _ethr-did-resolver_. This resolver, given an ethereum address, builds the DDO corresponding to that address (ref. [39]), hence allowing us to retrieve all useful data to authenticate the DID. The DDO contains both attributes and authentication methods, and transactions on the blockchain are required to update its data. The DDO is updated by the DID thanks to its private key, and this update involves gas consumption. The model proposal relies on Ganache, and Ganache accounts are imported through the method _didManagerImport_, managed by a core plugin of Veramo in which the public and private key have to be set, as shown in Figure 3 (ref. [40]). Figure 3: Method _didManagerImport_. Figure 2: Veramo framework (image extracted from [[https://veramo.io/docs/veramo_agent/plugins](https://veramo.io/docs/veramo_agent/plugins)]([https://veramo.io/docs/veramo_agent/plugins](https://veramo.io/docs/veramo_agent/plugins)) (accessed on 10 October 2024)). In Figure 4, the default DDO, built when the DID is created, is shown. The DID document is built using the contract _EthereumDIDRegistry.sol_ deployed on the Ganache network, and the method _resolveDid_ returns the document of the DID, passed as an argument to the method mentioned (refs. [41; 42])  
The DDO is associated with the DID via the _id_ field. There is also a _verificationMethod_ field, an _authentication_ field, and an _assertionMethod_ field. The _verificationMethod_ field contains verification material properties, that is, parameters to be used to verify a proof. The field _controller_ defines the entity that controls the keys. In the case of a DID associated with an individual, the entity that controls the keys can be the individual themselves. In the case of a DID associated with an organization, the entity that controls the keys can be a member of the organization itself. In the case of a DID associated with a device, the entity controlling the keys can be the individual whom the device is associated with. Thanks to this smart contract, a DID can delegate the performance of a specific function to a third party. In this case, the third party signs on behalf of the DID as long as the owner of the DID does not revoke the issued proxy. Through interactions with the smart contract _EthereumDIDRegistry.sol_, a DID can also set off-chain attributes' values. For example, it can set the endpoints through which it can be reached by another DID, thus making communication between DIDs using the DIDcomm protocol possible. Figure 5 shows the DID document containing the added endpoint. As regards the creation of the medical report, the issuer, and hence a doctor or an IoT medical device, starts with the creation of a credential message, which conforms to a precise VC schema and builds the verifiable credential through the method _createVerifiableCredential_ (ref. [43]), passing on as arguments the credential message and the proof format to be used. In addition, since the proposed model relies on a blockchain to ensure the integrity of the claims declared in the credentials and to make the VC status publicly accessible, the issuer has to store on chain the proofs to ensure claims' integrity and the VC's status. A detailed description of the smart contract that implements these functionalities is provided in the next section. The Veramo default platform only manages the proof format JWT (refs. [44; 45; 46]). The proof in the VC is a Json Web Token (JWT), which is a way to securely transmit json objects, and hence our credentials. The transmitted information is signed using a public/private key  
Figure 4: Default DID document.