As Tony Rutkowski said recently in Tokyo, the Internet works best when things come from the bottom up. Things that require a lot of sophisticated infrastructure before you can even get started are hard to get off the ground. This tends to be a problem with all security technology and particularly with proposals for electronic commerce. We need a testbed where we can play with the various proposals without having the dangers associated with using real money in an experimental environment. On the other hand we need a large number of people using the experimental software because scalability and usability are two key criteria. This document will describe: 1. The technical requirements for such a testbed. 2. The social engineering necessary to get a large number of Internet users participating in the testbed. Testbed Structure ----------------- Initially there would be only one bank. Multiple banks and inter-bank issues would be brought in later. Protocols should be designed to allow for multiple banks. The intention would be to implement (and thus compare) multiple forms of electronic money: everything from open electronic cheques (and other EDI) to sophisticated double-blinded digital cash schemes. All source for software used in the testbed is openly available. It is not necessarily available for reuse - all that is required for the testbed's purposes is to ensure that there is no security-through- obscurity. The system must support multiple currencies in simultaneous use. The only requirement for a currency is that the mechanism for creating new money is defined and does not allow people to get an arbitrarily large amount of money. [E.g. if it is done by allowing registered people to receive an "income" then people shouldn't be able to register multiple times in different guises without sustaining a real cost for doing so.] I discuss some ideas for how to do this later. A currency market should be set up at an early stage, if only as a fun application. People are encouraged (preferably by real physical prizes) to try to break the electronic commerce protocols. To facilitate this all communication for the system goes through "virtual" paths which are are on one or more computers. People who register as attackers can take over one or more virtual links and can delete/insert/change packets on those links. Denial of service attacks are not allowed. Nor (obviously) are attacks that don't use the officially sanctioned attack points. While the last sentence seems obvious it needs to be made strongly so we don't get people claiming in court "I broke into their machine because they wanted people to try to break their system". Finally, and this is perhaps the hardest part, we need applications which use the electronic commerce protocols and which a lot of people will want to use. This is hard with only "play" money, but I have a few ideas below. The protocols and the applications will not be tied to particular currencies. Particular servers and users will only accept particular currencies. This might be partly handled by having a currency market but ultimately some currencies may have real value while others don't, and the problem of acquiring the currencies with real value will be no different to our experience of real life. Possible Detail: Creation of Money ---------------------------------- The Internet Society might issue "Internet Dollar" play money to all its (financial) members who are interested, at some steady rate. Then organizations wishing to support the Internet Society while participating in the testbed might provide some services (e.g. by www) and charge with Internet$s. This would encourage people to join the Internet Society to use those services. It will also allow people to provide services which they would provide free except for a fear that they would be overused and thus affect the organizations network link - the play money charge limits possible use. A charity (or group of charities) could provide play money to people making donations. For example a donation of $100 to charity X might get you 100 X$s. Then organizations wishing to support charity X can provide services which are charged for in X$s. All the people involved in these experiments need to be aware that the software is experimental and that people are encouraged to break the protocols and "steal" the play money. So they shouldn't use it for anything serious. However when things stabilize and become trusted it is possible to imagine slightly more serious uses before we get to pure commercial applications. Network providers could experiment with charging algorithms. For example AARNet could issue AARNet units to its customers in proportion to their bill. A certain amount, say 40%, of the international link could be reserved for priority traffic. Users wanting a share of that priority component of the link would participate in an auction that is run every 30 minutes using AARnet units as currency. Possible Detail: Competitions and Gambling ------------------------------------------ I've speculated above on the possibility of people supporting the testbed by providing some useful services while charging play money. We shouldn't depend on that. There is a class of applications which are fun but need (or at least are helped by) money to give the measure of success or failure. These are games, competitions and gambling. I believe that done right they can be sufficiently interesting with play money that people will want to take part: enough people to test the scalability of the various proposals. Some of the games that can be played between individuals on the Internet really need the ability to have a bet to make play really meaningful: poker and backgammon are examples. The question is: will betting with "play" money work or will people play frivolously because the money does not have real value? The key here is that the currency used is reasonably hard to obtain. If you play badly and lose your money you can't play. If you win and get a lot of money you can move into the higher stake games where, presumably, the better and thus more interesting opponents play. I think it could work quite well. Beyond that we can produce a lot of gambling games which we know interest a lot of people and perhaps if they played with play money on the Internet their kids would eat better: casino games, lotteries, numbers games, bingo, poker machines, betting on events like horse races. I have some ideas in this area that can only be done on a computer network. Possible Detail: Getting Things Done ------------------------------------ I think the best way to move this forward would be through the IETF. There would be an ect working group. The rules for taking part in the testbed would be published as informational or experimental RFCs. We would need machines to run the Internet Experimental Bank and the attacker-accessible virtual links. I imagine that many organizations would be keen for the cachet of providing these services provided that the banks protocols didn't require human intervention. I imagine that account numbers will be PGP public keys. Subscribers claiming to be financial members of the Internet Society will receive an initial allocation and steady income of Internet-dollars. Other currencies will be created as required. The particular electronic commerce protocols experimented with may require additional infrastructure. For example accounts can be associated with other keys, for the use with protocols which don't use RSA, by means of appropriate PGP-signed documents. Clearly there is a lot of coding to be done, from hack to cryptographic. I think if we got the support of the IETF then we'd get support from individuals and organizations. The fact that it would add a certain respectability to playing games over the Internet would also help to attract some young and talented contributors. Interest? --------- Without endorsing the particular details above, if you think an Electronic Commerce Testbed is possible and that you would be prepared to contribute to an IETF WG on the subject then let me know. With sufficient interest I will propose the idea to Jeff Schiller (IETF Security Area Director). Bob Smart