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.

People

• Dan Boneh
• Neil Daswani
• Hector Garcia-Molina
• Steven Ketchpel
• Andreas Paepcke

What is a Digital Wallet?

Wallet Characterisitcs

• Extensible.  A wallet should be able to accommodate all of the user’s different payment instruments, and inter-operate with multiple payment protocols.  For example, a digital wallet should be able to “hold” a user’s credit cards and digital coins, and be able to make payments with either of them, perhaps using SET in the case of the credit card, and by using a digital coin payment protocol in the latter case.  As banks and vendors develop new financial instruments, a digital wallet should be capable of holding new financial instruments and make payments with these instruments.  For instance, vendors should be able to develop electronic coupons that offer discounts on products without requiring that users install a new wallet to hold these coupons and make payments with them.
• Client-Driven.  The interaction between the wallet and the vendor, we believe, should be driven by the client (i.e., the customer).  Vendors should not be capable of invoking the client’s digital wallet to do anything that the end-user may resent or consider an annoyance.  For example, a vendor should not be able to automatically launch a client’s digital wallet application every time the user visits a web page that offers the opportunity to buy a product.  Imagine what life would be like if, simply by walking into someone’s store, the store owner had the right to reach into your pocket, pull out your wallet, hold it in front of you, and ask you if you wanted to buy something from him!  A client-driven approach for building a digital wallet is important because software which customers consider “intrusive” will hinder the success of electronic commerce for all participants involved.
• Symmetric.  Vendors and banks run software analogous to wallets, which manages their end of the financial operations.  Since the functionality is so similar, it makes sense to re-use, whenever possible, the same infrastructure and interfaces within wallets, vendors, and banks. For example, the component that manages financial instruments (recording for instance account balances, authorized uses) can be shared across these different participants in the financial operations.  If the wallet components that are re-used are extensible, then we automatically get extensibility at the bank or vendor.  So, for instance, an extensible instrument manager will allow the bank or vendor to easily use new instruments as they become available.
• Generalized.  Interfaces should be similar regardless of what type of device or computer that the wallet, bank, or vendor application is running on.  A digital wallet running on an “alternative” device, such as a personal digital assistant (PDA) or a smart card, for example, has substantial functionality in common with a digital wallet built as an extension to a web browser.  Thus, a digital wallet in these two environments should re-use the same instrument and protocol management interfaces.

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

• Java Electronic Commerce Framework
• Microsoft Wallet
• CyberCash Wallet
• DigiCash