I am sorry to say that I just get confused between the different types of wallets and their business models. Rather like choosing Pick n' Mix.......
In one extreme, wallets can be considered as a simple exchange or presentation of verifiable credentials, and in the other extreme, a way of exchanging and combining types of verified information as part of a complex transaction between two anonymised persons (legal, natural, automated, or manual) and possibly governed by smart contracts etc.
So again, the very lack of definition of “wallets” causes confusion due to a multitude of different business models and intentions.
In the traditional case, one business model, albeit rather closed, is like the model used by Apple. In this case all parties agree to a centralised ruleset and governance. It does not matter if languages or semantics are different in their original form, but all attestations, values, formats etc are ‘normalised’ to a common agreed standard, no matter where or by whom they are executed. This has advantages. Most issues are determined as ‘The Rules of the Game’ by the operator of the application and accepted by all the relying parties and actors. The actual terms of the transaction are clear to read and see before entering the transaction. Issues like the question of liability, performance penalties, and jurisdiction are pre agreed to apply across each transaction using the application.
The mediation between parties is not computationally heavy on the wallet device, with most of the effort at each credential or attestation provider in the back-office. GLASS (https://GLASS-H2020.eu) uses this methodology. Also, it is clear as to possible paths for charging service fees etc. Usually, split between the application operator, who is contractually linked to the wallet operator, and the relying parties. A simple template would probably work across different applications too.
The other, very open business model is where there are no preorganised applications. The transaction type, rules and actors are all ad hoc and negotiation/mediation are decided at the time of transaction, although some pre-designed templates could be created and used. This could be very computationally heavy and possibly prone to error regarding semantics and lack of oversight regarding correct procedures, safeguards, and business cash flows towards operation of the system. (That is where pre-designed templates might come in).
However, while trying to create an open set of templates/semantics/procedures/liabilities to be used could work but it would take a long time to agree and would be subject to almost constant change in such a dynamic environment. The good news is that these templates could be compatible to the first model described above.
Of course, there will be other models between these extremes. But the question is, how do we differentiate between them when talking about wallets? Maybe the word ‘wallet’ should always be prefixed with a descriptor, ie a “Closed Wallet” or an “Open Wallet” or similar?
Any idea how this could work in our industry to clear up the ambiguities?
It is because digital wallets are so flexible in concept that we do have to be careful with descriptions.