This page documents basic wallet implementation for aries-framework-go covering universal wallet 2020 interfaces.
Some useful links
- Universal Wallet 2020
- Initial Proposal for Universal wallet 2020
- Presentation Exchange
High-level Framework Architecture
Aries Framework Go wallet has plugin based architecture which can be used to replace specific features to customize a wallet. Features like KMS, VDR, storage provider etc
Initialize wallet:
option 1 : If "wallet per agent instance" approach to be used for aries-framework-go, all additional wallet specific initialization steps like creating keys, DIDs can be either performed during very first access to any of the below interface functions or it can be done using a dedicated initialization method.
...
For credential issuer/prove/verify interfaces, options like verification method, controller etc will be used.
Wallet core features:
Basic wallet features independent of wallet types (like VC wallet, currency wallet etc) will be part of core interface.
...
Does aries wallet really needs universal wallet lock/unlock feature?
→ Lock/Unlock features are only suitable for wallets having local wallet content storages. In case of remote wallet content storage like EDV, there is no need of converting wallet contents to ciphertext (lock) or back to plaintext (unlock). But to support interoperability wallet might have to specify its state as 'LOCKED' or 'UNLOCKED', so that serialized representation of exported wallet can be imported into any wallet with local content storage.- Should we provide password in each api call as given in specification?
→ Password seems too specific, an issue to be opened to update specifications to include any kind of auth tokens.
VC wallet features:
VC plugin adds verifiable credential features to the wallet. By default aries-framework-go verifiable command features will be used for creating and verifying credentials/presentations.
The additional interface 'presentationSubmission' can be used to submit presentation definitions to the wallet and to get presentation submission as response.
...
Why we need a new query interface for querying VCs using presentation exchange? Why can't we use existing 'query' interface from store plugin?→ 'add' interface function from store plugin can be used to add any data model. Modifying 'query' interface to support presentation exchange may increase the complexity for non-VC data model users.
RESOLVED IN SPEC: query interface can be customized to match underlying wallet implementation.
Plugins: Non core interfaces (need not to be exported)
Key plugin:
Key plugin provides 2 interfaces : verifyRaw & signRaw. Framework will use aries-framework-go kms provider for these wallet features.
...
- KMS: use key plugin for cryptographic operations, if not provided then fallback to aries-framework-go kms api.
Store plugin:
Store plugins adds features for maintaining wallet content stores. Framework will use aries storage provider for these wallet features.
...
- As per specifications for query interface, how can we use map and reduce functional arguments effectively for REST bindings?
→ we can use functional arguments in JS bindings & SDK bindings. But REST & mobile bindings it needs to be modified to support some sort of generic query feature.
DID plugin:
Unlike other plugins, DID plugin functions won't be part of exposed wallet APIs, since aries-framework-go already has vdri interfaces exposed.
This plugin can only be used to inject custom DID features like using custom did methods for wallet operations.
Questions:
- Why can't we get rid of this plugin and use ask client's to use their customized aries framework go vdri.
→ to be decided during design discussion
Bindings
aries-framework-go wallet is going to be available in all the bindings - Go SDK, REST, JS & Mobile
User profile design
Since VC wallet can also be hosted in a server (aries command REST binding), it should be able to support multiple users with separate kms & partitioned stores.
In order to do that we have to introduce 2 APIs for creating and request profiles
- createProfile: This API creates user's wallet profile and returns info of profile created (ID and any other information needed by client). It returns error if wallet profile is already created or if profile creation fails.
Here are the arguments that can be passed to create user profile- username: unique loginname to identity user. This parameter will also be used as db namespace,
- authURI: webkms key server URI, if not provided then this profile will use localkms.
- authString: secret in case of localkms or auth token in case of webkms
- getProfile: Takes a username string and returns profile info containing profile ID or any other information needed for client.
Lock & unlock APIs:
Since profile KMS