Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 28 Next »

This page documents basic wallet implementation for aries-framework-go covering universal wallet 2020 interfaces. 


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.

option 2:  If "multiple wallets per agent instance" approach to be used.  Then challenges in handling data leaks between wallet users to be discussed.
For managing wallet using wallet server, we should support creating multiple wallet user profiles in single agent instance (i.e multiple kms & multi user EDV).

  • localkms to support name spacing
  • EDV store to provide vault id based support

Use did:key as default DID plugin for initializing DIDs and keys (for import/export).

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. 



API Dependencies: 

  • KMS: use key plugin for cryptographic operations, if not provided then fallback to aries-framework-go kms api.
  • VDRI: use DID plugin, if not provided then fallback to aries-framework-go vdri api.


Questions: 

  • 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 plugin:

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.

  • Verify: verifies a verifiable credential or a verifiable presentation.
  • Issue:  adds proof to a verifiable credential.
  • Prove:  creates a verifiable presentation (adding proof to presentation).
  • PresentationExchange & QueryByFrame: will be part of Query interface.


API Dependencies: 

  • KMS: use key plugin for cryptographic operations, if not provided then fallback to aries-framework-go kms api.
  • VDRI: use DID plugin, if not provided then fallback to aries-framework-go vdri api.


Questions: 

  • 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.

Key plugin:

Key plugin provides 2 interfaces : verifyRaw & signRaw. Framework will use aries-framework-go kms provider for these wallet features.

This plugins can be injected to customize the wallet to use other kms implementations like webkms.

API Dependencies: 

  • 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.

Store plugin should be able to add/remove/query all data models from universal wallet specifications. (Note:  add/remove/query interfaces should be generic enough to support all data models)

This plugin can be injected to customize the wallet to use custom storage providers like encrypted data vaults.

  • add: adds data models to wallet contents
  • remove: takes id of the content to be removed from wallet contents.
  • query: query wallet content based on search criteria. (TODO: search criteria to be decided)


Questions: 

  • 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



  • No labels