CURRENT MEETING REPORT Reported by Rohit Khare, World Wide Web Consortium Minutes of the Internet Secure Payments BOF One goal for today: To be a working group or not. No technical discussion allowed. Previous BOF was good introduction but IETF ultimatum for a second BOF is produce working group or disappear. In the two-hour time of a BOF, we can do no more than organize for future action. AGENDA o Where we are: o Draft Charter (good, but overtaken by events) o MC/Visa activities o Where we might go o Where we will go o Originally circulated agenda o New agenda, on yesterdays events: o Payment specs (15) o Other Domains (20) o micropayments o non-bank o negotiation o Choose one deliverable o Reformulate charter SOME BACKGROUND MasterCard has handed its protocol over to ANSI. Yesterday, letter produced jointly by Mastercard and Visa was provided to IETF Area Directors Jeff Schiller & John Klensin. o (Copy is attached to these notes.) Do not envision a formal role for IETF in protocol development for merchant-bank realm. Encouraged us to work on client-merchant, e.g., order placement and payment-type selection Commercenet/W3C have begun a payments-selection prototyping project. They have interest in working with the IETF. SHOULD IETF PURSUE "COMPETITIVE" BANKCARD PROTOCOLDEVELOPMENT EFFORT? Small discussion about likely benefits and outcome. Consensus of the group (80-100 present?) was NOT to pursue an effort to develop a merchant-bank payment authorization protocol, of a type that would be essentially competitive with STT and SEPP. CONCERN FOR CLIENT-SERVER ARCHITECTURE "THEORY" In the Web, clients are presentation-only; they don't do semantics. This only works when the client and the server have high quality, low- latency, high bandwidth connectivity. These conditions are not met for email-only channels. POSSIBLE "NEGOTIATION PROTOCOL" WORK BY AN IETF COMMERCE-RELATED WORKING GROUP Define what we mean by negotiation: o haggling over the purchased object, vs. payment protocol selection DISCUSSION OF REASONABLE TASKS FOR IETF TO PURSUE o Product purchasing, e.g., price, payment-method, etc. o Micropayments Recommendations for both. Concern for "experimental" nature of micropayments, in spite of their great potential and interest in them. Question of relationship between IETF and Commercenet-W3C project. Review of IETF requirements for change control over specifications. (Internet ENGINEERING Task Force) David Crocker observed the difficult history of IETF collaboration with other consortia. Area Director Schiller's suggestion that "match" between the two sides' cultures probably determine the outcome. Other possible work items: o Encapsulation of payment protocols over various "transport" protocols such as http and smtp. (The ANSI effort will NOT include this.) o APIs for commerce o Operations and integration guide for commerce over Internet. Discussion of implications and issues: o APIs are not typically in IETF purview. o Interactions in the haggling and commitment phase bring in serious legal issues. Proposal for specific work items: 1. Payment selection 2. Basic payments transport Target completion date: June 1996 A third task? o Offer specification o (Lay definition: agreement on product and price and agreement to buy it.) Separate into price tagging and offer rules? Conclusion from discussion on Offer Specification: o Considerable interest in developing and having such a protocol exists o Little shared understanding of the nature or details of such a protocol existed among those present. BOF RESULTS WITH STRONG ROUGH CONSENSUS Pursue chartering to develop 1. Payment selection protocol 2. Basic payments transport 3. Offer specification protocol Subscribe to IETF-PAY-REQUEST@IMC.ORG. This is a NEW LIST, different from other payments lists. ALSO NOTE THAT IT IS IMC.ORG, NOT IMC.COM. The meeting adjourned 5 minutes early. December 5, 1995 John Klensin, IESG Applications Area Co-Directors Jeff Schiller, IESG Security Area Director Dear Sirs, We write in order to encourage the IETF to take up the technical issues regarding selection of on-line payment mechanisms, which we believe if addressed properly, will aid the deployment of electronic commerce applications on the Internet. As you know, both MasterCard and Visa have been developing protocols for the secure transmission of bankcard payment information among cardholders, merchants, and banks over public networks. Our associations agree that the development of protocols to support bankcard payments is a matter to be resolved by the payment industry. We will, of course, be pleased to have advice and cooperation from the Internet community, but we do not at this time anticipate a formal role for the IETF in the bankcard standards. In contrast, the mechanisms required in the negotiation phase of a purchase is an arrangement between the systems of the buyer and seller- less in our purview (and expertise), but more in the IETF's. Payment protocols in the context of the World Wide Web, motivate at least two external mechanisms: 1) A way for a seller to specify acceptable payment mechanisms, and for the buyer to specify which mechanisms will be used. For example, Don Eastlake's UPP Internet-Draft is a start in this area. 2) A way for a seller to specify the details of a particular order such that a buyer may commit to the purchase. Attribute-value pairs (with a defined list of attributes) may be adequate here, but it would be useful to provide for the graphic expressiveness that sellers are likely to want. We would very much like to see the IETF address these and similar issues, perhaps in the context of a payments working group. We would be eager to participate in such a effort. Please contact us if we can assist this process in any way. Sincerely, /signed/ John Wankmueller Director, Electronic Commerce, MasterCard International Steve Herz Senior Vice President, Electronic Commerce Visa International