github.com/yacovm/fabric@v2.0.0-alpha.0.20191128145320-c5d4087dc723+incompatible/docs/source/developapps/wallet.md (about)

     1  # Wallet
     2  
     3  **Audience**: Architects, application and smart contract developers
     4  
     5  A wallet contains a set of user identities. An application run by a user selects
     6  one of these identities when it connects to a channel. Access rights to channel
     7  resources, such as the ledger, are determined using this identity in combination
     8  with an MSP.
     9  
    10  In this topic, we're going to cover:
    11  
    12  * [Why wallets are important](#scenario)
    13  * [How wallets are organized](#structure)
    14  * [Different types of wallet](#types)
    15  * [Wallet operations](#operations)
    16  
    17  ## Scenario
    18  
    19  When an application connects to a network channel such as PaperNet, it selects a
    20  user identity to do so, for example `ID1`. The channel MSPs associate `ID1` with
    21  a role within a particular organization, and this role will ultimately determine
    22  the application's rights over channel resources. For example, `ID1` might
    23  identify a user as a member of the MagnetoCorp organization who can read and
    24  write to the ledger, whereas `ID2` might identify an administrator in
    25  MagnetoCorp who can add a new organization to a consortium.
    26  
    27  ![wallet.scenario](./develop.diagram.10.png) *Two users, Isabella and Balaji
    28  have wallets containing different identities they can use to connect to
    29  different network channels, PaperNet and BondNet.*
    30  
    31  Consider the example of two users; Isabella from MagnetoCorp and Balaji from
    32  DigiBank.  Isabella is going to use App 1 to invoke a smart contract in PaperNet
    33  and a different smart contract in BondNet.  Similarly, Balaji is going to use
    34  App 2 to invoke smart contracts, but only in PaperNet. (It's very
    35  [easy](./application.html#construct-request) for applications to access multiple
    36  networks and multiple smart contracts within them.)
    37  
    38  See how:
    39  
    40  * MagnetoCorp uses CA1 to issue identities and DigiBank uses CA2 to issue
    41    identities. These identities are stored in user wallets.
    42  
    43  * Balaji's wallet holds a single identity, `ID4` issued by CA2. Isabella's
    44    wallet has many identities, `ID1`, `ID2` and `ID3`, issued by CA1. Wallets
    45    can hold multiple identities for a single user, and each identity can be
    46    issued by a different CA.
    47  
    48  * Both Isabella and Balaji connect to PaperNet, and its MSPs determine that
    49    Isabella is a member of the MagnetoCorp organization, and Balaji is a member
    50    of the DigiBank organization, because of the respective CAs that issued their
    51    identities. (It is
    52    [possible](../membership/membership.html#mapping-msps-to-organizations) for an
    53    organization to use multiple CAs, and for a single CA to support multiple
    54    organizations.)
    55  
    56  * Isabella can use `ID1` to connect to both PaperNet and BondNet. In both cases,
    57    when Isabella uses this identity, she is recognized as a member of
    58    MangetoCorp.
    59  
    60  * Isabella can use `ID2` to connect to BondNet, in which case she is identified
    61    as an administrator of MagnetoCorp. This gives Isabella two very different
    62    privileges: `ID1` identifies her as a simple member of MagnetoCorp who can
    63    read and write to the BondNet ledger, whereas `ID2` identities her as a
    64    MagnetoCorp administrator who can add a new organization to BondNet.
    65  
    66  * Balaji cannot connect to BondNet with `ID4`. If he tried to connect, `ID4`
    67    would not be recognized as belonging to DigiBank because CA2 is not known to
    68    BondNet's MSP.
    69  
    70  ## Types
    71  
    72  There are different types of wallets according to where they store their
    73  identities:
    74  
    75  ![wallet.types](./develop.diagram.12.png) *The four different types of wallet:
    76  File  system, In-memory, Hardware Security Module (HSM) and CouchDB.*
    77  
    78  * **FileSystem**: This is the most common place to store wallets; file systems
    79    are pervasive, easy to understand, and can be network mounted. They are a good
    80    default choice for wallets.
    81  
    82    Use the `FileSystemWallet`
    83    [class](https://fabric-sdk-node.github.io/master/module-fabric-network.FileSystemWallet.html)
    84    to manage file system wallets.
    85  
    86  
    87  * **In-memory**: A wallet in application storage. Use this type of wallet when
    88    your application is running in a constrained environment without access to a
    89    file system; typically a web browser. It's worth remembering that this type of
    90    wallet is volatile; identities will be lost after the application ends
    91    normally or crashes.
    92  
    93    Use the `InMemoryWallet`
    94    [class](https://fabric-sdk-node.github.io/master/module-fabric-network.InMemoryWallet.html)
    95    to manage in-memory wallets.
    96  
    97  
    98  * **Hardware Security Module**: A wallet stored in an
    99    [HSM](https://en.wikipedia.org/wiki/Hardware_security_module). This
   100    ultra-secure, tamper-proof device stores digital identity information,
   101    particularly private keys. HSMs can be locally attached to your computer or
   102    network accessible. Most HSMs provide the ability to perform on-board
   103    encryption with private keys, such that the private key never leave the HSM.
   104  
   105    Currently you should use the `FileSystemWallet`
   106    [class](https://fabric-sdk-node.github.io/master/module-fabric-network.FileSystemWallet.html)
   107    in combination with the
   108    [HSMWalletMixin](https://fabric-sdk-node.github.io/master/module-fabric-network.HSMWalletMixin.html)
   109    class to manage HSM wallets.
   110  
   111  
   112  * **CouchDB**: A wallet stored in Couch DB. This is the rarest form of wallet
   113    storage, but for those users who want to use the database back-up and restore
   114    mechanisms, CouchDB wallets can provide a useful option to simplify disaster
   115    recovery.
   116  
   117    Use the `CouchDBWallet`
   118    [class](https://fabric-sdk-node.github.io/master/module-fabric-network.CouchDBWallet.html)
   119    to manage CouchDB wallets.
   120  
   121  ## Structure
   122  
   123  A single wallet can hold multiple identities, each issued by a particular
   124  Certificate Authority. Each identity has a standard structure comprising a
   125  descriptive label, an X.509 certificate containing a public key, a private key,
   126  and some Fabric-specific metadata. Different [wallet types](#types) map this
   127  structure appropriately to their storage mechanism.
   128  
   129  ![wallet.structure](./develop.diagram.11.png) *A Fabric wallet can hold multiple
   130  identities with certificates issued by a different Certificate Authority.
   131  Identities comprise certificate, private key and Fabric metadata.*
   132  
   133  There's a couple of key class methods that make it easy to manage wallets and
   134  identities:
   135  
   136  ```JavaScript
   137  const identity = X509WalletMixin.createIdentity('Org1MSP', certificate, key);
   138  
   139  await wallet.import(identityLabel, identity);
   140  ```
   141  
   142   See how the `X509WalletMixin.createIdentity()`
   143  [method](https://fabric-sdk-node.github.io/master/module-fabric-network.X509WalletMixin.html)
   144  creates an `identity` that has metadata `Org1MSP`, a `certificate` and a private
   145  `key`. See how `wallet.import()` adds this identity to the wallet with a
   146  particular `identityLabel`.
   147  
   148  The `Gateway` class only requires the `mspid` metadata to be set for an identity
   149  -- `Org1MSP` in the above example. It *currently* uses this value to identify
   150  particular peers from a [connection profile](./connectionprofile.html), for
   151  example when a specific notification [strategy](./connectoptions.html) is
   152  requested. In the DigiBank gateway file `networkConnection.yaml`, see how
   153  `Org1MSP` notifications will be associated with `peer0.org1.example.com`:
   154  
   155  ```yaml
   156  organizations:
   157    Org1:
   158      mspid: Org1MSP
   159  
   160      peers:
   161        - peer0.org1.example.com
   162  ```
   163  
   164  You really don't need to worry about the internal structure of the different
   165  wallet types, but if you're interested, navigate to a user identity folder in
   166  the commercial paper sample:
   167  
   168  ```
   169  magnetocorp/identity/user/isabella/
   170                                    wallet/
   171                                          User1@org1.example.com/
   172                                                                User1@org.example.com
   173                                                                c75bd6911aca8089...-priv
   174                                                                c75bd6911aca8089...-pub
   175  ```
   176  
   177  You can examine these files, but as discussed, it's easier to use the SDK to
   178  manipulate these data.
   179  
   180  ## Operations
   181  
   182  The different wallet classes are derived from a common
   183  [Wallet](https://fabric-sdk-node.github.io/master/module-fabric-network.Wallet.html)
   184  base class which provides a standard set of APIs to manage identities. It means
   185  that applications can be made independent of the underlying wallet storage
   186  mechanism; for example, File system and HSM wallets are handled in a very
   187  similar way.
   188  
   189  ![wallet.operations](./develop.diagram.13.png) *Wallets follow a
   190  lifecycle: they can be created or opened, and identities can be read, added,
   191  deleted and exported.*
   192  
   193  An application can use a wallet according to a simple lifecycle. Wallets can be
   194  opened or created, and subsequently identities can be added, read, updated,
   195  deleted and exported. Spend a little time on the different `Wallet` methods in
   196  the
   197  [JSDOC](https://fabric-sdk-node.github.io/master/module-fabric-network.Wallet.html)
   198  to see how they work; the commercial paper tutorial provides a nice example in
   199  `addToWallet.js`:
   200  
   201  ```JavaScript
   202  const wallet = new FileSystemWallet('../identity/user/isabella/wallet');
   203  
   204  const cert = fs.readFileSync(path.join(credPath, '.../User1@org1.example.com-cert.pem')).toString();
   205  const key = fs.readFileSync(path.join(credPath, '.../_sk')).toString();
   206  
   207  const identityLabel = 'User1@org1.example.com';
   208  const identity = X509WalletMixin.createIdentity('Org1MSP', cert, key);
   209  
   210  await wallet.import(identityLabel, identity);
   211  ```
   212  
   213  Notice how:
   214  
   215  * When the program is first run, a wallet is created on the local file system at
   216    `.../isabella/wallet`.
   217  
   218  * a certificate `cert` and private `key` are loaded from the file system.
   219  
   220  * a new identity is created with `cert`, `key` and `Org1MSP` using
   221    `X509WalletMixin.createIdentity()`.
   222  
   223  * the new identity is imported to the wallet with `wallet.import()` with a label
   224    `User1@org1.example.com`.
   225  
   226  That's everything you need to know about wallets. You've seen how they hold
   227  identities that are used by applications on behalf of users to access Fabric
   228  network resources. There are different types of wallets available depending on
   229  your application and security needs, and a simple set of APIs to help
   230  applications manage wallets and the identities within them.
   231  
   232  <!--- Licensed under Creative Commons Attribution 4.0 International License
   233  https://creativecommons.org/licenses/by/4.0/ -->