by Eric Ries
The Internet has provided a tremendous opportunity for business. Many millions have already been made by businesses related to the Internet and companies that have taken advantage of the Internet's unique features. Like any financial medium, the Internet has sparked concerns about the safety and reliability of doing business online. Part of this hesitation stems from the fact that there is no real standard for conducting secure, safe, and simple transactions online. Although several methods do exist for Internet commerce, they are all built upon proprietary protocols and existing, static payment methods. Although most of these systems now have secure encryption-based security, none provides a comprehensive solution for developers and entrepreneurs seeking to conduct business over the Internet.
This is where the JECF comes into play. As an open, cross-platform,
extensible API, it has all the advantages of Java without the
drawbacks of proprietary protocols. In short, it is the first
all-inclusive solution for online commerce.
Although the JECF is still only in the specification phase, it is important to understand the concepts behind it. You may not be able to create an application using the JECF today, but you can start planning for it today. You can design your current applications so they can take advantage of the JECF when it becomes available. A good system designer always looks to the horizon to see what's coming and designs with future extensions in mind.
The problems associated with online commerce are many. Understanding why the JECF is so well-suited to the task of conducting business online requires a full understanding of the difficulties involved.
The first main difficulty in electronic commerce is, ironically, both the easiest to solve and the source of the most consternation: the theft of important information. People who are wary of electronic commerce fear that their credit card number, or other personal information, will be stolen by "hackers" or other miscreants and used for illicit purposes. Luckily, with the advent of public-key encryption, and its implementation in the Java Security API and Netscape's Secure Sockets Layer (SSL) 3.0, intercepting encrypted information across the Internet is nearly impossible.
Good encryption does not necessarily equal good security, however. Especially with a comprehensive commerce system, there are many points at which a hostile applet or application could gain access to sensitive system information. These problems can potentially increase in an object-oriented environment such as Java. For instance, an applet posing as a legitimate service provider could make illegitimate charges on a user's credit card, unless sufficient preventative measures are taken.
Other barriers to electronic commerce include proprietary protocols and solutions. Every time a developer tries to write an application for conducting online commerce, he or she must overcome the same set of problems (encryption, security, and so on) from scratch. This is redundant and makes commercial Internet development expensive and time-consuming. In addition, developers who use existing protocols are often locked in to a specific commerce system. For instance, many credit card companies have their own centralized network for conducting electronic transactions. However, in order to access this network, developers must use the protocols established by that specific company-which may or may not be compatible with other companies. An application that supports many protocols can become bulky and hard to manage.
Further, existing commerce solutions are based on existing forms of commerce-mainly credit cards and checks. A comprehensive solution must account for many other forms of transactions, and most importantly, must be able to adapt to future forms, like game tokens, cash cards, "smart" cards, and so on. A dynamic extensible architecture such as this is essentially absent from the field of Internet commerce.
Even commerce systems that overcome these problems often run into the barrier of single-platform support. Because the Internet is made up of numerous types of computers running many different operating systems, a commerce system needs to support this wide range.
Every aspect of the JECF was designed to combat one of these potential problems in an online transaction. One offshoot of this is that many parts of the API are complex, often taking two or three steps to accomplish-securely-what might have been accomplished in one insecure step. Also keep in mind that, as of August, 1996, the full JECF API has not been published; it is still under development by JavaSoft and its corporate partners. All JavaSoft has done thus far is to publish a theoretical framework (the JECF White Paper) that details what the goals and structure of the finished API will be. Do not be surprised if this changes somewhat in the months to come.
The JECF, like all other Java APIs, is made up of several key classes. They are divided into several packages based on their function. These separate pieces interact to provide the full functionality of the JECF. Each component acts independently in order to increase the security of the whole system. They are all contained in something called the Java Wallet, which manages all transactions relating to the user.
The JECF is centered around the Java Wallet. Each user has his or her own wallet which contains a number of cassettes. Cassettes are to a wallet what an applet is to a browser. Cassettes provide some form of financial service to a wallet. In a way, cassettes are like credit cards. When you are shopping and go to pay for something, you open your wallet and select an appropriate credit card (or that old-fashioned cash stuff). When you perform an online transaction, you may select a payment cassette from your wallet. The online service then interacts with your cassette, which may, in turn, interact with your credit card company or an electronic cash server.
One of the most important parts of the Java Wallet is the Wallet database. This stores all kinds of information about the Wallet's owner, including a record of all previous transactions conducted using the Wallet. Because of the sensitive but useful nature of this information, the Wallet must be simultaneously secure yet robust and accessible-never an easy compromise! Each cassette is allowed to keep its own data in the Wallet database. When you write a cassette, you can count on the Wallet database being available so you can store any data that you may need the next time the cassette is used.
The Wallet database provides only limited access to its information. Access to the database is managed by a system of Permit objects that designate certain roles to various components. Components wishing to gain access to the database can have one of three roles: DatabaseOwner (the Wallet, the Wallet's owner, and any classes designated by the user), DatabaseUser (any applet, cassette, or component seeking to use some information stored in the database), and DatabaseMaintainer (applets and objects that perform maintenance or non-financial functions on the database). These roles are delegated by the database based upon a user-configurable understanding of which objects are to be trusted with the various roles. When an object applies for a Permit from the database, it must be authenticated and digitally signed by a trusted agency. The user has final control over which objects get access to what information.
The Wallet database can also give access to specific Table or Row objects. These classes comprise the internal structure of the Wallet database, and each class operatesindependently to ensure the security of its contents. Permits can be registered at this level, so that outside objects can be given access to only a small part of the database rather than the entire thing. Table and Row permits and roles are the same as those used in the database class, only they apply to a smaller region of the database.
The Wallet database has classes for conducting all kinds of transactions. These include record-keeping transactions, as well as user interactions and exchanges of money, goods, or services. Each type of transaction has its own class type that determines its parameters and functionality. Transactions can also be extended to include more interesting exchanges, such as barter agreements or contracts. Further, the JECF can create tallies, which are essentially electronic receipts for products purchased. All of this provides a robust framework for conducting commerce.
These are the two most common forms of transactions in the database. Database transactions include the storage of transaction information and are discussed in detail in the "Backing out Pending Transactions" section of this chapter. User transactions are those in which the Wallet's owner makes a purchase using a payment cassette, and are discussed throughout this chapter, most notably in the shopping cart and cassette sections.
An exchange transaction is an extension of the standard user transaction in which money is exchanged for goods. In an exchange transaction, any kind of value can be traded, including money, but also including trades for stock, goods, services, time, and so on. In fact, this opens up the possibility of having online contracts, which could be legally as legitimate and binding as paper contracts. This requires that digital signing be extended from applets and cassettes to create signable documents, which requires a whole other set of protocols and classes for authenticating user signatures and enforcing contracts signed online. These issues, however, are still a long way off - signable applets will probably not become a reality until 1997, and signable documents will probably take another year.
Complex transactions are just like regular exchange transactions, except that they can include more than two parties. This is ideal for multiple-party sales, or loans involving a third party. This could also make it possible for groups of people to form contracts with companies-perhaps an online mutual fund could contract with all of its members at once. This type of transaction has the advantage of being fully adaptable to a variety of circumstances-it is not locked into traditional two-party contracts, but can be used for just about anything. This helps maintain the dynamic nature of the JECF.
Microtransactions are used by companies to issue cash substitutes such as cash cards or tokens. These transactions allow small, predefined charges to be made against a pre-authorized account. This would allow gaming companies to issue online tokens redeemable for games, with the money charges being made against a special company account. Or, a company could issue coupons or vouchers that could be used to purchase certain products from a third party, which would be paid out of the issuing company's account. Microtransactions are important because they allow companies to engage in non-cash sales and promotions. Because many people are wary about spending their own money online, this gives Internet vendors the opportunity to let users "win" tokens or coupons and then redeem those for prizes. Services such as Riddler (http://www.riddler.com) allow users to play games and earn "CAPS," which can be redeemed for certain prizes that the company buys. While this is effective, the JECF allows such companies to issue same-as-cash tokens that can be redeemed at other vendor locations, thus freeing them to provide a much wider variety of services.
The process of purchasing products is handled by a Shopping Cart applet. This is the basic unit of user interaction. When a user chooses to make a purchase, it is this applet which must load the necessary JECF components and ensure that the transaction completes successfully. It is also responsible for authenticating the user and establishing a secure link. Rather than completing a sale in one step, as many online commerce programs do today, the Shopping Cart uses a three-step process.
First, the user selects the goods to be purchased from the vendor. Next, the applet shows a tally of the items selected and allows the user to select a payment method. Before the final transaction is conducted, the applet constructs a page displaying the total prices registered by the Java Wallet. This is different from the previous tally page, because this one is constructed locally-displaying the actual charges incurred rather than the ones displayed by the vendor. If these two sets of prices do not match, the user can abort the transaction. This is the vendor's only chance to charge money to the user's account (or credit card, and so on.); they cannot charge more or less than is registered with the Wallet. Further, no financial information about the user is transmitted to the vendor; all transactions are handled by the Wallet on a separate secure link.
The actual work of transacting money is done by small portable objects called Cassettes. Each Cassette implements a specific payment or service protocol. Cassettes are provided by vendors, who may or may not charge a fee for their use. Cassettes are a convenient method for software distribution, because any Java object (applet, servlet, and so on) can become a cassette by simply conforming to the JECF Cassette Interface. This means that currently existing Java products will have an easy transition to the JECF.
Payment cassettes are provided by money management companies such as banks and credit card providers. These cassettes contain the necessary instructions to access a user's account with one of these companies. From the user's perspective, this provides a convenient way to add new payment instruments; they simply request a cassette corresponding to a particular credit card or bank account. From the standpoint of companies, this provides an easy way to give their customers online access to their accounts in a secure, standard, cross-platform way.
The other kind of cassette is called a service cassette. These cassettes are modules that provide non-payment kinds of services, such as accounting or budget management. Service cassettes are used mainly to access and maintain the user's financial database. For instance, a tax cassette might automatically fill out online tax forms for a user based upon his or her online purchases. This provides developers with an ideal way to create lightweight, portable financial applications without requiring the user to enter in redundant data; all records are kept securely by the Java Wallet. Only cassettes that are designated as safe by the user have access to the Java Database.
The JECF takes many measures to ensure the security of the user's data, and to prevent access to it by a malicious applet or cassette. One of the most important security measures implemented in the JECF is digital signing. This is a process whereby one or more trusted entities certify that a particular piece of Java code is safe and reliable. If the code is tampered with in any way, the digital signature is invalidated, thus ensuring that Java applets or packages remain unchanged since their last digital signature.
JECF cassettes require a digital signature in order to gain access to the Java Wallet database. Based on a cassette's signature, the User can assign to the cassette a level of "trust." This trust is used by the Wallet to grant various roles to the cassette. A role determines what parts of the JECF system a cassette or applet can access. As an example, Sun describes a service Cassette that provides backup and restore services for the Java Wallet database. This Cassette needs to be granted a "maintenance" role in order to gain read and write privileges for the database.
Two important classes to maintaining Cassette and Wallet security are the PassPhrase and Access Control List (ACL) classes. These two classes are used to determine which roles are assigned to which cassettes. Although only loosely defined in the prerelease API, the PassPhrase class will provide user authentication services for each wallet, thus preventing unauthorized access by any user other than the owner of the wallet. Each wallet must have a PassPhrase associated with each user. The ACL provides a similar service for cassettes loaded into the wallet. Just like each wallet must have a PassPhrase, each wallet component or cassette must have an ACL that determines what other components or cassettes can gain access to it. This requires signing and other authentication routines in each and every Wallet component. Although this is cumbersome, having each object operate separately makes the whole system much more secure.
The identity of a Cassette is provided by the entity that signed it. Every Cassette must have a special Identity object that is used to give the user (and the JECF system) accurate information about the behaviors of the cassette. This Identity is digitally signed to prevent tampering. Further, to prevent another cassette from "borrowing" its signed status, the cassette makes use of a Ticket object. Tickets are an indirect method of accessing the Identity object. Because of security considerations, the Identity object cannot be directly accessed; this might allow a malicious applet to steal its Identity. Instead, a Cassette generates a Ticket object based upon its Identity. Although a Ticket can be created from an Identity, the reverse is not true. When queries are made of the Ticket, it fetches the required information from the Cassette Identity, but does not contain this information itself. The process is very much like the pointers used by Java to represent data in memory; the Ticket (pointer) allows the data (Identity) to be accessed, but does not actually contain the data itself. This, combined with the digital signature and shopping cart security measures, makes it virtually impossible for anyone to gain access to a user's personal financial information by posing as a legitimate vendor.
Another important aspect of the Java Wallet is the way in which it ensures reliable transactions. Even more so than in the "real" world, Internet transactions are prone to both human and computer error. The Internet itself is chaotic and fluctuating, and a huge number of problems could easily arise during the simplest of transactions. Servers going down, power outages, software or hardware bugs, viruses, and incompetent operators can all interrupt a transaction at any stage. In order for an electronic commerce system to be fully robust, it must be able to handle such problems with style and grace. It should also give users and vendors a way of resolving any disputes that arise from botched transactions. The JECF provides methods for both canceling a transaction that has encountered errors and also for resolving transaction disputes between users and vendors.
A transaction is never permanently written to the Wallet database until it is completely finished. During the various stages of the transaction, information is posted to the Pending Transactions list. If, for any reason, the transaction is interrupted before it is complete, the information contained in the Pending Transactions list can be used to undo any monetary exchange that has taken place. This protects the user from any damages that might result from accidental computer failure. It also helps prevent a malicious applet from making unauthorized charges by faking a failure of some kind.
Despite all of the measures the Java Wallet takes to prevent a dispute from arising from an erroneous transaction, these are still possible. For instance, if a transaction is interrupted en route to the vendor, but is still transmitted by the payment Cassette to a credit card company, a user might wind up paying for a product they never received. Although this scenario is unlikely, the JECF still provides a method to resolve disputes among any combination of the buyer, seller, and cassette vendor. This functionality is implemented in the Problem class, which allows for convenient correspondence between any of the three parties. This eliminates the need for tedious phone calls, conference calls, and hard copies of correspondence. Instead, parties use the Problem Resolution System to send Problem reports back and forth. These can be easily responded to, and allow problem troubleshooters to keep track of each problem separately. All transactions are sent and received via e-mail, so problems can be answered immediately.
The JECF API is expected to be released as an "alpha" test product in the last quarter of 1996. Currently, only a brief White Paper and code outline are available, although JavaSoft says it is reviewing the API with major commerce vendors. Many companies have also endorsed the JECF concept, but only time will tell which products will support it. In any event, the JECF will definitely not be ready for full-fledged application development until sometime in 1997, possibly even as late as 1998. Until that time, developers and users will have to make do with existing inferior, yet viable, solutions.
More information is available on the Internet at any of the following locations:
Although still a long way off, the JECF is one of the most exciting new additions to the Java API. If adopted by the Internet, business, and legal communities (it already has a long list of sponsors), the JECF could one day replace, or at least enhance, the current process of selling products and completing contracts. This is one of the truly revolutionary ramifications of Java's development and it promises abundant benefits. As long as it is implemented cautiously and thoroughly, the Java Electronic Commerce Framework could become the most significant and secure form of commerce yet devised.