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


Note: we are going to support only export and import options. Since exported wallets are always locked, no need to have explicit lock/unlock wallet interfaces.


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

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

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.

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.


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


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
      (Note: in case of localkms a masterkey will be generated and will be encrypted by user's secret)
  • getProfile: Takes a username string and returns profile info containing profile ID or any other information needed for client. 


Lock & unlock APIs (need naming suggestions):

Since profile KMS requires locking/unlocking features, it is not a good idea to expect user kms secret/token in each wallet api calls due to below reasons.

  • complexity of handling secrets in each API calls.
  • not user friendly
  • creating KMS instance by user for each API call is expensive operation.


Solution: client has to unlock the wallet before calling any wallet interface APIs and lock the wallet back when he/she is done. Wallet will also auto lock if unused for certain amount of time.
This leads to introduction of 2 more APIs given below: 

  • unlock: accepts user `secret/token` used to create profile, creates kms instance, keeps it in cache (with expiry) and returns a token which can be used for any subsequent operations.
    This token will be used by VC wallet to fetch kms instance from cache and also will be used to correlate user profile. Once token expires cache gets cleared and kms instance will be destroyed.
    This token has to be supplied by client while calling each VC wallet APIs.

  • lock: Can be called by user to lock the wallet back.



  • No labels