## 3 Motivation for the SSI Wallet Survey
### Results of the Evaluation
#### 3.2.2 Wallet Usage  
When receiving claims, the user can either accept or decline the attempt. In one case (VIDwallet), QR codes cannot be scanned twice. If one workflow does not work, then this will stop the user from proceeding. We shortly summarized the findings during wallet usage in [30]. Few wallets allow self-asserted claims (VIDwallet and SmartWallet). However, the requests may fail nonetheless in the case of the VIDwallet. The amount of information on the issuer and verifier varies from wallet to wallet. Some only display a logo and basic information (esatus Wallet and SmartWallet), whereas others provide a long list (Data Wallet) or visual signs that the entity is verified (Lissi Wallet). The three examples of the Lissi Wallet (see Figure 2a), the esatus Wallet (see Figure 2b), and the SmartWallet (see Figure 2c) are shown in Figure 2.  
In the case of the Data Wallet, the data on claims is blurred similar to passwords. This can enhance the perspective that the data is as important as passwords. However, this could also lead to sharing data without thinking. The difference between the Data Wallet (see Figure 3b,c) and another wallet, the Lissi Wallet (see Figure 3a), is shown in Figure 3. In the Data Wallet, users can unblur the claims by clicking on the eye button. However, this is not mandatory. On the contrary, most wallets, such as Lissi Wallet, show all information in clear text, which can also be critical.  
In the case of the esatus Wallet, the issuer or verifier can be set to automatically accept (see Figure 4a). On the one hand, this may reduce the number of notifications for the user, so they can pay attention to those that appear. On the other hand, the entity may change its behavior to a malicious one without the user being notified. The default setting is being asked next time. However, if the user decides not to be asked again, then the default setting is to receive notifications about interactions. Default notifications may provide  
Figure 3: Screenshots of selected wallets found in the Google Play Store 2/3. (a) Lissi Wallet receiving an information request [30]. (b) iGrant.io Data Wallet receiving blurred claims [30]. (c) iGrant.io Data Wallet receiving a blurred information request.  
Figure 2: Screenshots of selected wallets found in the Google Play Store 1/3. (a) Lissi Wallet receiving a request. (b) esatus Wallet receiving an information request [30]. (c) SmartWallet with an incoming request [30].  
a higher degree of transparency. In addition, we missed information about redirects and other actions in the VIDwallet (see Figure 4b). The VIDwallet is one of the few wallets that accept self-issued credentials. However, it is debatable how qualitative they are, as shown in Figure 4c. Here, we used a throwaway email address to receive a verifiable email address credential.  
Based on these observations, we could not find guidance for the user to decide whether to trust and accept the offer or request of an entity. For example, we only noticed information about issuers and verifiers being certified once. Also, we could not see if the amount of data requested was typical or more than required. Both design variants of Data Wallet and esatus Wallet can either help reduce the burden or lead to just accepting everything. The issue is that too many notifications (see cookie banners or warnings) may make the users tired, whereas too little information may lead to a similar result. With SSI, the user has more possibilities but also more responsibilities. Consequently, further work is required to find suitable designs to guide users.