# Self-Sovereign Identity-Based E-Portfolio Ecosystem
## 3 System Design
### Smart Contract Design  
Figure 6 illustrates the relationship diagram featuring roles and smart contracts within the EApp-chain. The EApp-chain hosts three active smart contracts: the certificate authority manager contract (_CAMcon_), award manager contract (_AMcon_), and access control contract (_ACcon_). Specifically, the _CAMcon_ and _AMcon_ are deployed in the _CaAch_, while the _ACcon_ takes residence in the _ACch_. This deployment configuration ensures a structured and efficient distribution of functionalities within the EApp-chain, delineating the roles and interactions of each smart contract in facilitating the operations of the e-portfolio ecosystem. Figure 5: E-portfolio ecosystem architecture. In the _HLF_ framework, when an organization becomes a participant in two channels, it gains the capability to store the ledger data of both channels concurrently. This capability allows smart contracts within the organization to execute cross-channel read operations. For instance, when both the _LEU_ and the _CEU_ join two channels simultaneously, the _AMch_ deployed in both entities can access and read the permissions of _STUs_ stored in the _ACcon_. This cross-channel read functionality enhances the flexibility and interoperability of smart contracts, allowing them to seamlessly access data across multiple channels within the HLF network. * Certificate Authority Manager Contract (_CAMcon_)  
_CAMcon_ is responsible for managing information related to _REs_ and approved activities. The diagram of CAMcon is presented in Figure 7, and it stores the structure of reviewer and activityInfo in key-value pairs. When invoking smart contracts, X.509 certificates can be used to extract user identities and attributes, such as \(P_{u}k\)s and roles. These attributes can be utilized to restrict contract function execution to specific users. The addActivityInfo function allows the administrator of the _LEU_ and _CEU_ to add approved _AO_s to _CAMcon_, which can then be used by _AMcon_ to grant awards to users. On the other hand, the addReviewer function is used by the _CEU_ to add an _RE_. _HS_s can access the \(P_{u}k\)s of all _REs_ through the getAllReviewer function, which can help users generate authorization for _REs_. * Award Manager Contract (_AMcon_)  
_AMcon_ is used to manage award records for users. The diagram of ACcon is presented in Figure 8 and the structure of awardInfo is stored in _AMcon_, as shown in Table 1. The award function can be invoked by the _AO_, and then the award function will invoke the getActivityInfo function in _CAMcon_ to check whether the _AO_ has the right to give an award. After a successful invocation, the addAward event is generated to notify the _HS_ where  
Figure 6: Smart contracts and role relationships in App-chain. Figure 7: CAMcon diagram. the user is registered. The getAccessLink function is used to enable the reviewer to obtain the data access link authorized by the user. First, _AMcon_ reads the world state about the user's awards and calls getPermission in _ACcon_ to obtain the user's permission. Finally, authorized access links are returned to the _RE_. * Access Control Contract (_ACcon_)  
_ACcon_ is primarily responsible for managing the access control of users' data. The diagram of ACcon is presented in Figure 9. Each user is associated with an accessControl structure in _ACcon_, as shown in Table 2. This structure comprises two objects, namely awardAttributes and permission, which only the user can modify. The unconfirmAwards object stores the awards added by organizations but not yet confirmed by the user. When an organization receives the addAward event, it confirms that the user is a member of the organization and then invokes the addAwardForUser function in _ACcon_ to add the award to the user's unconfirmAwards object. The user can subsequently call the \"confirmAward\" function to transfer the award from the unconfirmAwards object to the awardAttributes object.