Digital Wallets Project Home Page

The Digital Wallets project at Stanford is a joint collaboration between the Digital Library Initiative and the Network Security Group. We are currently studying electronic commerce issues surrounding digital wallets in a variety of operating environments.

Check out our generalized digital wallet architecture.


What is a Digital Wallet?

A digital wallet is a software component that allows a user to make an electronic payment with a financial instrument (such as a credit card or a digital coin), and hides the low-level details of executing the payment protocol that is used to make the payment.

Wallet Characterisitcs

We believe that digital wallets should be:

Wallet Architecture


Check out our javadocs.


Our digital wallet is designed to support the goals described above. Brief descriptions of the core components of our digital wallet follow:

1. The Instrument Manager manages all of the instrument instances contained in the wallet, and, for example, may be queried to determine which instrument classes and instances are available to execute a given payment or other operation.

2. The Protocol Manager manages all of the protocols that the wallet may use to accomplish various operations, and invokes protocols to carry out the interaction between the digital wallet and the vendors and banks.  The Protocol Manager relies on the Communication Manager to process low-level communications requests with other computers representing banks and vendors.

3. The Wallet Controller presents a consolidated interface for the wallet to the client.  The Wallet Controller hides the complexity of the other components of the wallet, and provides a high-level interface to the client.  A non-human client, or software agent, can make method calls on the Wallet Controller’s interface through the Client API.  A human client may use a graphical user interface (GUI) which may make method calls on the Wallet Controller.  The Wallet Controller coordinates the series of interactions between the User Profile Manager, Instrument Manager, and Protocol Manager necessary to carry out high-level requests received from the client, such as “purchase a product.”

4. The User Profile Manager manages information about clients and groups of clients of the wallet including their user names, passwords, ship-to and bill-to addresses, and potentially other user profile information as well.  In addition, the User Profile Manager keeps access control information about what financial instruments each user has the authority to access.

5. The Communication Manager provides the wallet with an interface to send and receive string messages between wallets and peer commerce components by setting up a “connection” with a remote Communication Manager.  The Protocol Manager builds on top of the “connection” abstraction to support the concept of a session.  A “connection” is typically asynchronous, while communications between peer commerce components in a Session occur in (message,response) pairs where one peer sends a message, the other peer receives the message, executes some action, and returns a response.  Depending upon the implementation of the Communication Manager, the messages may be sent over different types of networks using different communication protocols.
 For example, one implementation of a Communication Manager may send and receive messages over the Internet using HTTP requests and responses over a TCP/IP ethernet network.  In this case, a Session may be made up of a sequence of several HTTP GET messages and their corresponding responses.  In another example, a second implementation of a Communication Manager may send and receive messages over a RS232 serial interface using TCP/IP.
 Note that the Protocol Manager is responsible for making calls to the Cryptographic Engine to encrypt any data that is passed to the Communication Manager, such that the data can be securely transmitted over the communications medium.  The Communication Manager cannot be responsible for encryption of sensitive data from the wallet because it is formally outside the wall`et architecture, and can be replaced by another Communication Manager to run the wallet on another device.  If the Communication Manager is relied upon to encrypt sensitive data, then the Communication Manager might be replaced with a malicious Communication Manager that sends all sensitive data to an adversary.

6. The Client API is an interface provided by the Wallet Controller that may be used by an autonomous software agent acting on behalf of a human user.

7. The User Interface provides a graphical interface to the services offered by the Wallet Controller’s interface.  The User Interface is an optional component of the wallet.  Some devices, such as most smart cards, do not have the ability to display a graphical user interface, and hence the Wallet Controller interface must be accessed through the Client API.  Note that the user interface is a core component within the wallet because certain parts of the user interface have access to sensitive user data.  For example, the edit box object into which a user enters the password to “unlock” the wallet should run within the wallet’s protected address space.  On the other hand, users may want to customize the wallet’s interface by plugging-in GUIs developed by other software vendors.  To accomplish both these conflicting goals, the user interface exports parts of its interface as the User Interface API that may be overloaded by software vendors to render customized parts of the interface

For more information about our wallet architecture, please our our working paper.

Related Work