What is a Digital Wallet?

Digital wallets are small electronic packages that automatically supply information such as credit card numbers and shipping addresses for use in conducting Internet transactions. Also known more broadly as Internet payment services, they provide a means by which customers may order products and services online without ever entering sensitive information and submitting it via e-mail or the World Wide Web, where it is vulnerable to theft by hackers and other cyber-criminals. Digital wallets thus allow consumers to make online purchases easily and securely, safeguarding the privacy of purchasing habits and financial information alike.


Traditionally, digital wallets were stored on the desktops of personal computers. By the early 2000s new digital wallets were compatible with wireless and other mobile devices, and were more often stored on a central server owned by a digital wallet vendor or Internet service provider (ISP). Among the technologies touted as a cornerstone for the growth of e-commerce, digital wallets had a history of promise interrupted by false starts. They evolved in stages, with a series of incarnations since first emerging in the mid-1990s.


Digital wallet vendors maintain relationships with online merchants in a manner similar to those between credit card companies and brick-and-mortar stores. The digital wallet vendor either charges a commission to the retailer on every purchase involving the vendor's wallet, or merchants pay the vendor a flat fee for accepting the vendor's wallet in their transactions. In turn, businesses and customers mutually agree to use the products, software, and services of a particular digital wallet vendor, which then acts as an intermediary for all transactions between the firm and its customers. In this way, customers needn't transmit credit card numbers for each transaction. Instead, they send the purchase order to the wallet vendor, which simply charges it to the customer's account.

                                 Wallet Characteristics

• Extensible.  A wallet should be able to accommodate all of the users different payment instruments, and inter-operate with multiple payment protocols.  For example, a digital wallet should be able to hold a users 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 clients 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 clients 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 someones 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

  
  
  
  
  
  Brief descriptions of the core components of the 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 Controllers 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 Controllers 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 wallets protected address space.  On the other hand, users may want to customize the wallets 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.