CHAIRS
Jim Miller (W3C)
Tom Wills (CommerceNet)
ATTENDEES
SANTA CLARA (TECHMART):
Einar Asbo (Visa International), Jeff Bettencourt (MCI), Eva Cabness (MCI), Lisa Croel (Corman-Croel Communications), Dave Grossman (USC/ISI), Brian Harp (USC/ISI), Chris Hibbert (Sun Microsystems), Rick Janowski (Hewlett Packard), Bill Jetter (Bank of America), Steve Knipping (Marshall Industries), Cathy Medich (CommerceNet), Manny Pasetes (Premenos), Allan Schiffman (Terisa Systems), Einar Stefferud (First Virtual Holdings), Connie Vaughan (Deloitte & Touche), Peter Will (USC/ISI), Tom Wills (CommerceNet), Jay Yamada (Compuserve), Pete Yeatrakis (NACHA).
BOSTON (BBN):
Scott Bradner (Harvard), Denise Diehl (USPS), Ed Gilmetti (First Virtual), Ken Rodrigues (OSF), Dave Solo (BBN), Win Treese (Open Market)
BOSTON (MIT):
Don Eastlake (CyberCash), Phill Hallam-Baker (W3C), Rohit Khare (W3C), Jim Miller (W3C), Michael Smith (Prodigy)
BY PHONE:
Randy Cato (MCI), Alireza Bahreman (VeriFone), Bill Filletti (MasterCard), Mark Greene (IBM), Ammiel Kamon (Netscape), Mark Linehan (IBM), Eduard Ritscher (Chase Manhattan), Dan Schutzer (Citibank), Gerry Smith (Zenith Data Systems), Marvin Sirbu (CMU), Jeff Stapleton (MasterCard), Tom Wagner (CMU), Stefek Zaba (Hewlett Packard)
AGENDA
1. OPENING REMARKS
JIM MILLER (W3C): The idea for this project came up last month at XIWT, where it was noted that one of the missing elements in Web commerce is negotiation across payment instruments and protocols. CommerceNet and W3C decided to work together to solve the technical side of this, and proposed a project of 6 months duration to begin in the New Year. This meeting is intended to give everyone enough information to decide whether and how they'd like to participate, and to solicit commitments for participation.
TOM WILLS (COMMERCENET): This project is exciting for CommerceNet because it gives us - as an industry - the opportunity to address a substantial barrier to the spread of electronic commerce on the Net. That is the ability for clients and servers to negotiate payment instruments, payment protocols, and transport method between one another.
2. MEETING OBJECTIVES
TOM WILLS: This is an informational meeting for those who have expressed interest in - or would like to be involved in - the project. We'll describe the project objectives and organization, requirements for participation, answer your questions, and solicit participation. It's not necessary to commit today - the deadline is January 8, 1996.
3. PROJECT OBJECTIVES
TOM WILLS: The project objectives are to:
DAN SCHUTZER: Are we talking about the ability to make payment, or to indicate which one of the different payment mechanisms you're using?
TOM WILLS: One way of looking at it - if you're a consumer going shopping and want to pay for something, you may have several different options to make payment. The merchant will also have several options for receiving payment. They might not be the same options. So there's a synching up process that has to happen between browser and server to enable the actual payment to take place, to enable transition from the shopping phase to the payment phase.
STEVE FABES: Do you expect the payment to actually go through the system?
TOM WILLS: In cases where the payment CAN go through the system, yes we do.
JIM MILLER: The goal of this project is to develop a negotiation mechanism where there are already existing payment mechanisms, so we will couple to those.
DAN SCHUTZER: Is the intent to develop a negotiation protocol so that two parties can check what's available and connect to a payment mechanism, including whatever software is necessary to handle it?
TOM WILLS: Correct - using existing payment mechanisms.
DAN SCHUTZER: FSTC will support that and will offer its sponsorship to the project. Is the project open ended so that we can include other things, or will it just include general payment instructions to banks?
TOM WILLS: The focus is on payments alone. We have to narrowly define the scope because there are other applications outside of payments for a negotiation process like the one we're talking about.
DAN SCHUTZER: We're focusing on payments alone, but are we including the ability to give just a general payment instruction like a funds transfer? This needs to be defined as well. There may be other things that people will come up with in the future, like digital cash.
TOM WILLS: That's potentially within the scope.
4. SERVICE FLOW
TOM WILLS: For example, Bob wants to buy flowers from Alice's shop on the Web. Bob may have e-cash, a credit card, and a debit card, or any combination that he may want to pay with. Those payment instruments may be carried using different end-to-end payment protocols like SEPP and STT, or any others like digital cash protocols (this is not an exhaustive list). Then there are transport protocols as well, like SSL, SHTTP. All of these have to synch up with one another. And SMTP and TCP/IP may also be used as transport mechanisms. So the whole purpose of this is to align the capabilities of the browser with those of the server and to effect an actual payment.
PETE YEATRAKIS: Is there any way to adjust the flow that this protocol will run through?
TOM WILLS: Yes - this doesn't necessarily have to be the flow at all - this is just a simplified diagram
LESTER MORRIS: Is this intended to be a web-only solution or are we thinking about something broader than this?
TOM WILLS: We want to build something that can be more broadly applied, with an initial focus on the web.
DAN SCHUTZER: Does that mean we might want to include other things like PGP, PEM, etc.?
TOM WILLS: Yes - the list is not exhaustive.
EINAR STEFFERUD: We'd like to include mail, FTP, Gopher, or anything else we can deliver with.
JIM MILLER: The core of the project -- what we are committing to deliver six months from the start date -- is using the web to do the negotiation, to pick from among several payment alternatives, and actually causing the payment to be delivered. The hope is that beyond that narrow focus of the project, which is for demonstration purposes, the protocols themselves will support all of the other things that EInar suggested, as well as possibly some others.
EINAR STEFFERUD: The Web has a history of proposing protocols that do not interoperate with other modes. Therefore, centering on the web and excluding others in the pilot is too narrow a scope.
TOM WILLS: That could well be - but this is a design issue that we should address in the design meeting on January 23 - rather than now. We'll of course need to put a box around the specific protocols that we'll follow. In the meantime, the general idea is that we'll use multiple transport protocols, with an initial focus on the web, but understanding that there are wider applications outside of the web and even potentially outside of the payment system.
AMMIEL KAMON: Agree with Tom.
GERRY SMITH: Will the scope include the social interface?
TOM WILLS: We're interested in looking at the whole end-to-end process, so to the extent that this includes the social interface, yes it will.
5. PROJECT SCOPE
TOM WILLS: The project scope is:
ALLAN SCHIFFMAN: How do you define 'existing' with respect to payment instruments and protocols.
TOM WILLS: Anything that a participant in the project claims exists (if you're confident that it works).
DAN SCHUTZER: Do you mean something like SEPP, which is out in spec but not implemented yet?
TOM WILLS: Yes - the project could even incorporate the implementation of that spec.
JIM MILLER: What we mean is that no resources from this project will go to developing new protocols -- what we're trying to build is a negotiation mechanism, and that's the entire scope.
6. DELIVERABLES
TOM WILLS: The project deliverables are: -Running Demo -Reference Code -Protocol Specifications, published as a W3C Working Draft -"Lessons Learned" white paper published through CommerceNet.
7. BENEFITS
TOM WILLS: The benefits to all participants will be:
MARK LINEHAN: How does this relate to the work in the same area that the IETF has started?
TOM WILLS: IETF, as I understand it, has also initiated an effort in the area of payment protocol negotiation.
SCOTT BRADNER: At this point there are requests to IETF and to the IESG, which manages IETF in this area. At this point there has been no working group formed.
DAN SCHUTZER: So does that mean you would join this one?
SCOTT BRADNER: No, this is just a factual report that the IETF has not yet instituted a working group in this area. The area director for applications, John Klensin, has stated his concern that IETF form such a working group only if we have expertise to bring to the table, and that by doing so we're not fractioning other efforts. If there are several uncoordinated efforts going on in parallel, that doesn't do anybody any good. We want to be sure that any IETF activity complement other activities rather than detract from them. At this point, it's not a foregone conclusion that the IESG or particularly the area directors in the Applications area will support the formation of a working group unless it can be shown that IETF brings expertise and constituency to the table.
MARK LINEHAN: What is the attitude of W3C and CommerceNet with respect to the relationship between yourselves and IETF?
JIM MILLER: I have been talking with John Klensin at IETF. We believe that the best way to proceed is to bring all the participants in as part of the specification process. It's our intention that at the end of this process, when all the specs seem to be working adequately, to turn them over for change control to IETF for them to continue with the work as they see fit and make an actual standard. The strength that W3C and CommerceNet bring to the table is in the implementation area, which is not normally within the scope of what the IETF does, and the intention is to hand off whatever specifications we develop at the end of this project to the IETF for change control.
ROHIT KHARE: Want to reiterate the IETF discussion three weeks ago about this working group. We hoped to put it in the same context as we're putting this project in, so IETF would take up the negotiation mechanism . The hope for the future relationship between this project and IETF is that if we do get involved it will be on the exact same issues - negotiation mechanism, user experience, and NOT protocol design. So we have a lot of faith in the relationship working out well should there become an IETF working group in this area.
DAN SCHUTZER: So CommerceNet and W3C will develop a missing piece of the infrastructure, and if it works will hand it off to IETF for proposal as a standard.
JIM MILLER: Correct.
UNIDENTIFIED: So IETF will just be a rubber stamp to validate the proposal?
SCOTT BRADNER : What it means is that IETF will look at this and, if indeed this goes through the normal IETF review and development process, they will turn it into a formal standard. There is no guarantee that what comes out of the standards process is identical to what goes in, just as its no guarantee for somebody within IETF who initiates a proposal. Development experience and a larger number of people with input in the discussion process frequently results in changes to the final product. So the IETF is not a rubber stamp, but is the next logical step in the deliberation process to develop a standard.
JIM MILLER: Agree with Scott.
TOM WILLS: We agree with that from the CommerceNet end too. (continuing the presentation) The benefits to individual participants are: -Browser Vendors can refine mechanisms for connecting to payment middleware -Server Vendors can refine negotiation protocols required for commerce applications -Payment Middleware Vendors will be able to test their products in a real-world environment -Merchants will be able to test alternative user interface designs to study customer acceptance.
8. PARTICIPATION REQUIREMENTS
TOM WILLS: Requirements for participating in the project are:
ALL PARTICIPANTS:
BROWSER VENDORS:
PAYMENT VENDORS:
MARK LINEHAN: Are we asking vendors to ship this in their products?
TOM WILLS: No.
MARVIN SIRBU: With respect to incorporating negotiation protocol and payment middleware in the client - does it make sense to define an open API, so that one isn't doing a whole series of incorporations that don't follow a pattern?.
TOM WILLS: It does make sense - we'll address this in the design phase.
ALI BAHREMAN: VeriFone is doing some work in this area as far as defining a common API. Is there someone else in the conference working on this?
JIM MILLER: We'll discuss this at the design meeting - table until then.
DAVE SOLO: Can you clarify why you see the negotiation process as being incorporated within the payment mechanism, as opposed to taking place prior and then branching off from the payment mechanism?
TOM WILLS: It can go either way - there are both scenarios. Again, we'll address this in the design phase.
JIM MILLER: Negotiation may take place in advance, or may be within the payment mechanism itself, and we don't want to view this as an either or situation, but as an ability to incorporate both, since in the real world both scenarios will happen.
DAN SCHUTZER : We'll endorse that.
AMMIEL KAMON: We should use a highly modular approach any time we do anything like this because of the wide variety of coherent protocols and instruments out there already.
TOM WILLS: Agree - the more modular the better.
9. TECHNOLOGY OWNERSHIP
TOM WILLS:
RICK JANOWSKI: Is there any thought to including companies who are not members of CommerceNet or W3C?
TOM WILLS: Restrict participation in core project team to members of one or the other consortium. Potential for nonmembers beyond that (Jim will elaborate in a few minutes)
DAN SCHUTZER: Since FSTC is endorsing this project - would a member of FSTC who is not an individual member of either CommerceNet or W3C be able to participate? We are hoping to include e-check.
JIM MILLER: FSTC can put e-check in as FSTC, but if individual members want to act themselves, they would need separate membership in either CommerceNet or W3C.
TOM WILLS: The proposed timeline for the project is:
10. PROJECT ORGANIZATION
JIM MILLER: The structure of the project is straightforward:
MARVIN SIRBU: What will you do if you get more than two people from each subcommittee wanting to be full participants?
JIM MILLER: The goal is to have all commitments by January 8. Companies wishing to participate will notify the Steering Committee by e-mail. Participants should state which committees they wish to be on and whether they can commit the required resources to be part of the Project Team. The Steering Committee will choose the two subcommittee members in the case of a conflict. The Steering Committee can also decide to accept more than two, but the problem is that coordinating large groups grows exponentially more complex with the number of members. Keeping the group relatively small is crucial given the 3-4 month development time we're committing to.
MARVIN SIRBU: Given that the negotiation protocol is going to affect browsers and servers and payment systems, how will we do the design if we're broken into subcommittees that don't have the same members?.
JIM MILLER: This is what the project team is for - it will consist of two members from each subcommittee
UNIDENTIFIED: Who are the chairs for each subcommittee?
JIM MILLER: Not selected yet. We have representatives from the Steering Committee who are ex-officio members of subcommittees. We're not sure that the organizational structure requires any further detail.
AMMIEL KAMON: Will the payment system team address interfaces to existing payment systems networks and legacy systems?
DAN SCHUTZER: They'll include existing and upcoming Internet payment systems that want to participate such as SEPP, STT, Open Market, CyberCash, etc. In some cases the interface to banks is being addressed - for example STT and SEPP address interfaces with the Visa and MasterCard clearing and settlement systems.
JIM MILLER: There's no reason that any individual company cant be represented on more than one subcommittees or more than one person. The commitment is 2 hours a week for each person for each committee you're on, and there are obviously some companies that do two or three of these functions so it would make sense for them to be present on as many subcommittees as they can afford to be present on. The Project Team has to have 12 human beings.
UNIDENTIFIED: How do you differentiate the roles of merchant and server vendor. Wouldn't the server provide what you would expect the merchant functionality to be?
JIM MILLER: The merchant is the person with merchandise he wants to sell. Although some servers have merchandise to sell as well, and in that capacity they're merchants but primarily they're interested in developing the capacity of their server software.
DAN SCHUTZER: Along the same lines as Visa and MasterCard, for e-check we may recommend that the merchant display a logo (for the payment method being accepted).
TOM WILLS - This is on the outer edges of the project scope. We're more concerned with getting the negotiation mechanism to work with this project and dealing with marketing issues later.
11. PARTICIPANT STATEMENTS
(Each attendee was asked to talk briefly about his or her interest in the project).
JIM MILLER (W3C): Interested in getting the negotiation protocol working on the Web, but also for more general use.
ROHIT KHARE (W3C): Interested in getting this to work with HTTP in particular, in a way that allows us to shift hardware and software architecture so that all of us can take advantage of this stuff.
PHILLIP HALLAM-BAKER (W3C): Interested in how this affects the Web payment system.
DONALD EASTLAKE (CYBERCASH): We have an operational payment system and also have an Internet draft out on a suggested negotiation mechanism.
MICHAEL SMITH (PRODIGY): We want to make payment services available to our subscribers and also want to be able to accept electronic payments for content.
DAN SCHUTZER (CITIBANK): Interested in general accessibility in a standard way of these payment systems interfacing so they can be promulgated.
GERRY SMITH (ZENITH DATA SYSTEMS): Want to play along the merchant route.
CLIFF NEUMANN (USC ISI): We're involved with the NetCheque and NetCash systems, and also the FSTC e-check project . We're also involved in the IETF 'not yet' working group.
BILL FILLETTI/JEFF STAPLETON (MASTERCARD): Interested in payment systems to ensure that the data being passed back and forth in transactions is appropriately secured and also is able to complete a transaction within our legacy systems
MARVIN SIRBU (CMU): We're developing the NetBill payment system for low-cost information goods and are interested to make sure that NetBill is supported by this protocol.
MARK LINEHAN (IBM): We've been involved in the design and development of iKP and SEPP with MasterCard. We have the general philosophy that there will be multiple payment mechanisms in the real world and we'd like to assist in making that happen and in such a way that will work effectively for the systems we understand.
ALI BAHREMAN (VERIFONE): We've been working on a system called Payment Transaction Application Layer which is, as one of it's primary goals, a system that allows multiple payment methods to coexist and interoperate. So we're very interested in participating in the payment systems subcommittee to make this happen.
EDWARD RITSCHER (CHASE MANHATTAN): We're active in the FSTC e-check and e-comm projects and our perspective is that we would like to be able to deliver to our customers a stable product for payment which allows them to execute their transactions to all merchants in the marketplace.
LESTER WATERS (MICROSOFT): We're interested in facilitating browsers and servers to negotiate payment methods. As you know, we've been involved with Visa and now with MasterCard in bootstrapping the payments part of this effort.
ED GILMETTI (FIRST VIRTUAL): We have a functioning payment system which we'd be interested in integrating with this, as well as a number of existing merchants who accept multiple payment forms and who may be interested in the merchant side.
DENISE DIEHL (USPS): We're interested in looking at alternative e-payment systems. We're working on an electronic postmark for e-mail.
KEN RODRIGUES (OSF): We're interested in open solutions to the electronic commerce infrastructure.
BOB NANNAL (SECURITY DYNAMICS) - I'm interested in the security aspects of this transaction.
DAVE SOLO (BBN) - I'm interested generally in the security mechanisms that may protect this exchange - and more specifically interested in the FSTC e-check project on the payments side.
SCOTT BRADNER (HARVARD/IETF): I'm here as an observer, concerned that the resulting standard that comes out of here is something that can facilitate the process of commerce over the Net.
AMMIEL KAMON (NETSCAPE): We're looking to conform to interoperability and would like even more than that the ability to use these technologies in our core product lines. We already have quite a few commerce customers for publishing and online merchant malls who are extremely interested in this type of technology. Also - we'll volunteer our chat server for next get together :-)
TOM WILLS (COMMERCENET): We're a consortium of 139 companies. Our purpose is to promote electronic commerce over the Internet and our interest in the project is to facilitate a cross-industry effort in an area that we believe is crucial to jump-starting commerce on the Net.
PETE YEATRAKIS (NACHA): I represent a local trade association of 1200 banks for interbank payments and also NACHA which provides operating and legal framework for exchanging payments. We think some of the electronic commerce systems we're dealing with will need to fit into the online systems from MasterCard and Visa.
CATHY MEDICH (COMMERCENET): CommerceNet has a sincere interest in wanting to see all the payment protocols work together - so we think this is a very critical project.
JAY YAMADA (COMPUSERVE): We're mostly interested from the payment side, the vendor side, and to a lesser degree the browser side of things.
CHRIS HIBBERT (SUN): we've been working on FSTC e-check and e-comm projects I'm sure there are a lot of other people at Sun looking at other pieces of this, but that's the piece I've been paying attention to.
CONNIE VAUGHAN (D&T CONSULTING): We get a lot of inquiries from our clients on how they should be planning to conduct business across the Internet - so we would be interested in this project primarily from the payment vendor and merchant sides.
EINAR ASBO (VISA INTERNATIONAL): Our main objective here is to make our payment products work securely and well on the Net (and perhaps make it difficult for anybody to choose anything else :-)
STEVE KNIPPING (MARSHALL INDUSTRIES): Marshall is an electronics distributor - we sell about 300,000 parts total and about 70,000 from our website ordering system - so I think we fit in as a merchant.
LISA CROEL (CORMAN-CROEL): We do public relations for CommerceNet and will be working to publicize this whole effort.
JEFF BETTENCOURT (MCI): I'm participating as a bystander, collecting information to take back.
MANNY PASETES (PREMENOS): Just observing but listening to the presentation - mainly interested in the merchant aspect.
EINAR STEFFERUD (FIRST VIRTUAL): We would be interested in at least three of the areas - servers, payment systems, and merchants, as we've been operating those things now for 14 months with a real operating payment system. We're not quite sure how we fit in to a pilot at this point.
PETER WILL (USC ISI): We're working on middleware for commerce, as a follow-on to the FAST project which has been operating about 7 years on buying things on the Internet. Currently we use blanket purchase orders, so we're very interested in anyone signing up to use the system - buyers and sellers.
RICK JANOWSKI (HEWLETT PACKARD): I'm wearing two hats - I was invited to come here by our research labs in Bristol who are working on payment protocols, and so my principle goal is to report back to them for them to make decisions about their potential participation in this work. Secondarily, I work in HP's Electronic Commerce group who run the WWW site - and am therefore potentially interested as a merchant.
ALLAN SCHIFFMAN (TERISA SYSTEMS): I'm here to make sure I don't get volunteered for anything without knowing about it.
12. QUESTIONS & ANSWERS
ALLAN SCHIFFMAN: The Steering Committee has representation from four different consortia. I understand this is a CommerceNet/W3C project. What is the standing of OSF and FSTC?
JIM MILLER: This is a joint project of CommerceNet and W3C. OSF and FSTC are members of one or the other, or both. We've invited representatives of two other consortia help us steer the project - but it's not a four-way project.
EINAR STEFFERUD: I understand that they are supposed to be neutral parties, but is OSF a neutral party?
TOM WILLS: It depends on where you stand. They represent a subset of the server vendors of the world.
JIM MILLER: Nobody is totally neutral if they have members. W3C, CommerceNet, FSTC, and OSF have members. OSF has a very large membership base. Their members are mostly computer companies but not exclusively. W3C has a smaller membership base. CommerceNet is a little bigger than W3C.
EINAR STEFFERUD: OSF is purporting to represent a particular server technology, which does not represent the whole field of servers. They may represent an operating system segment of the industry.
JIM MILLER: OSF provides no server technology to the web domain at all.
EINAR STEFFERUD: I just want an assertion from OSF that they will be neutral in the project.
TOM WILLS: Ken Rodrigues has left so he can't address this personally, but the intent of appointing various bodies to the Steering Committee is for them to be neutral. It's our commitment as the project managers to ensure that neutrality.
ALLAN SCHIFFMAN: There's been an emphasis on negotiation. I understand that as 'selection' - I'm not certain what 'negotiation' is in this context. One of the reasons the term 'negotiation' is confusing is that it might be more natural to refer to the haggling over price and quality and quantity that goes on between the buyer and the seller - and it's a very natural interpretation of 'negotiation. It's somewhat less natural to use the term 'negotiation' to refer to a matter of selection among payment methods. I'll use the term 'selection'.
There's another issue with respect to interoperation between various client/server technologies and payment systems - that is the bridging between finalization of the so-called business services - and bringing that into the payment protocol. At the IETF BOF meeting in Dallas, not only was the topic of payment system selection talked about - but also the notion of 'tagging and bagging' - the representation of a goods and service order - or the purchase details as agreed by the buyer and seller - to carry that forward into the payment protocol. Having looked at the payment protocols proposed by both MasterCard and Visa, I think that's a larger issue - making that bridge from the initial payment system selection. Is that one of the work items for this effort? What is the status of the tagging and bagging?
TOM WILLS: It's an issue we'll have to address at the design meeting.
ALLAN SCHIFFMAN: One scenario is that somewhere along the way after you've decided what you want to buy, there might be a selection mechanism where perhaps some software gets invoked - and at that point the transfer of the information that had been haggled over in the prior steps has to be brought into the payment mechanism. That bridging process is a relatively knotty problem because it's got cryptographic import - we have to agree exactly what's being purchased because that's going to be the payment mechanism detail - that's probably going to want to get some cryptographic protection for integrity and confidentiality. I suggest that this be included in the work item. This is probably more problematic than deciding the collection method.
CHRIS HIBBERT: If while you're negotiating payment, you discover that there's something in the shopping basket that you want to change your mind about, you don't want to put the whole basket away and start all over again. The problem isn't as hard as Allan makes it out to be.
TOM WILLS: That probably is going to be one of the crucial design issues because some payment mechanisms include the GSO information and others don't.
DAN SCHUTZER: We might also want to include the ability to split the payment method - to pay for some of the transaction with cash and another part with a credit card.
TOM WILLS: That's very possible - some merchants would want to offer that service.
MARVIN SIRBU: At some merchants (for example a gas station) you might be quoted a different price depending on the payment instrument.
TOM WILLS: All of the above are true, so obviously this thing has got to be very modular and very well conceived at the outset. We have to design it properly to make sure that it incorporates all of the major scenarios. Plus it's got to work internationally as well. There is a real haggling process that goes on between a buyer and a seller in a lot of countries and we have to accommodate to that at the outset.
BILL FILLETTI: If many of the shopping functions are happening via e-mail, I believe e-mail should be in the scope. The store-and-forward properties of e-mail present a whole different set of requirements in terms of handling the GSO, the negotiation process, and the transfer of secure payment information.
TOM WILLS: Absolutely - e-mail was one of the transport protocols that we presented earlier and it's one that we expect to see used in a lot of applications. First Virtual uses e-mail for instance. Lawrence Livermore uses e-mail for EDI. But again, the intent is to create an ability to negotiate across multiple payment methods, multiple end-to-end protocols like STT and SEPP, and multiple transport mechanisms like SMTP or TCP/IP or overlapping on that layer, SSL or Secure HTTP.
EDWARD RITSCHER: Who would the customer be?
TOM WILLS: This is still to be decided for the actual pilot - there are a couple of possible scenarios that we'll need to sort out with the browser vendors and the merchants. Who have in mind is ANYONE who's going to be at the receiving end of a payment - merchants, governments, or individuals. We want to be able to accommodate all of these scenarios. Initially the focus is again going to be on the Web, and what we see happening on the Web today is consumers and merchants in a credit card environment - but we certainly don't want to limit ourselves to credit cards - we want to build it in a modular way that handles other scenarios.
EINAR STEFFERUD: What are we going to use for customers, one of the ideas is that we use real customers buying real stuff.
TOM WILLS: That's certainly possible. If some of the browser vendors want to put out a version of the software
JIM MILLER: I think the best possible outcome is that come July, two or more browsers publish beta versions that incorporate our negotiation protocol.
TOM WILLS: I second that.
STEVE FABES: I thought that one of the deals with the merchant in the credit card relationship was that they were not allowed to offer a discount for alternative payment methods.
EINAR ASBO: The rule is that you're not supposed to have a surcharge for a credit card payment - that's not to say you can't have a discount for cash. And Visa can't govern cash transactions.
EDWARD RITSCHER: Will you include the transmission of the payment into the banking system?
TOM WILLS: That's beyond the scope because there are payment middleware vendors working on this - basically their function right now is to build a bridge between the Internet and the back-end financial systems like the ACH and VisaNet and Banknet.
STEVE FABES: Are ACH transactions within the scope?
TOM WILLS: Yes, to the extent that there's a message format that the ACH needs to accept. But we're not addressing the actual interface between banks and the ACH.
PETER WILL: Does the scope include classes of buyers in different roles - for example, one person could buy things as an individual, as an employee of a company, as a member of the Price Club, etc.?
TOM WILLS: I don't know if that's something that impacts the payment mechanism, but it's a very good issue and one that we'll have to explore.
EDWARD RITSCHER: Is it possible to aggregate payments to present them to a payment system to create volume purchases?
TOM WILLS: This isn't a new issue - the people looking at micropayments are addressing this because with credit card systems there's usually a minimum dollar amount below which a transaction isn't profitable.
STEVE FABES: Are you going to let the supplier of the payment service have promotional messages in their - e.g. you can have 400 frequent flyer miles if you use our card?
TOM WILLS: That's outside the scope.
ALI BAHREMAN: The mechanism of payment method negotiation on the customer side should be a local matter. There may be some configuration file where the customer says "I only use payment systems that give me credit for my United frequent flyer miles".
RICK JANOWSKI: There are presumably some political reasons why the payment negation protocol has been broken out from the payment protocol itself. How technologically feasible is it to address this as an isolated issue rather than looking at an overall solution that looks at both?
TOM WILLS: The main reason for keeping them separate is that we need to be focused and not try to solve all the world's problems at once. There are several standard features of a payment message - dollar amount, payor and payee account numbers transaction date, etc. We have to focus on this core functionality to get done in 6 mos.
BILL FILLETTI: We have to recognize that each card association has its own very specific requirements for messages, currency handling, etc. It may be premature to get into this debate right now, since all of us are reviewing what will be provided as specifications for the Open Data Network.
DAVE SOLO: There hasn't been any discussion of the authentication or integrity requirements on the negotiated information. I would ask, relative to the scope, have people thought about what security mechanisms are needed within/without this selection protocol?
DONALD EASTLAKE: My view is that you have to use a secure channel.
DAVE SOLO: I mean what about people attacking the integrity of the 'list of choices'?
DONALD EASTLAKE: if you're worried about real-time manipulation of packets, you need to use IPSEC, etc.
PHILL HALLAM-BAKER: Also, what about the scenario where a client offers two cards and indicates one, but the merchant uses the other?
MARK LINEHAN: How do you propose to get this started?
JIM MILLER: For negotiation, we are going to start from the PEP and UPP proposals.
MARVIN SIRBU: Is there any candidate API possible for integrating wallets?
ROHIT KHARE: PEP may offer an API
JIM MILLER: I hope that will be the first work item for the browser subcommittee.
EINAR STEFFERUD: I'm concerned about mixing protocol and API issues. APIs are too tied to operating systems.
JIM MILLER: I agree. However, we will have to address this separately from the selection protocol.
DONALD EASTLAKE: A browser and payment system may not even be on the same machine
MARVIN SIRBU: I think that's very unlikely because of the security risks.
DAVE SOLO: if you include palmtop solutions, the answer is yes, it does happen.
PHILL HALLAM-BAKER: Yes, what about smart cards, for example?
SCOTT BRADNER: One of the things done in the IETF in this area is to treat the protocol as a standard, but the APIs as information reference implementations.
ROHIT KHARE: Like CGI - API by convention.
CHRIS HIBBERT: Integrating with smart cards is purely local. Essential, but hidden. Not a matter that needs to be specified across platforms.
TOM WILLS: We need to get back to the discussion on organizational considerations.
BILL FILLETTI: We want to participate, but we need to talk with management about whom, and at what level.
EINAR ASBO: Visa has a question about the scope of this project. Sometime the discussion has been about payment protocol (not interesting), negotiation, and APIs.
JIM MILLER: I believe the scope is exactly negotiation over the instrument, protocol, and transport (and not "selection", as far as wording goes). We will also have to solve many ancillary engineering issues, but they are not guaranteed to be in scope.
UNIDENTIFIED: Can we clarify with an example of where this work begins and ends?
TOM WILLS: It begins when shopping ends - and ends once the payment method, payment protocol, and transport protocol have been agreed upon and the data is handed off to the payment module.
UNIDENTIFIED: This is an active issue in the Visa/MasterCard discussion.
JIM MILLER: Yes, however, MasterCard and Visa is not the central issue. If they continue in secret, we have to proceed on what's published.
MARK LINEHAN: MasterCard and Visa have already asked for input in that arena, just as in the letter to IETF.
TOM WILLS: Remember our schedule is January 23rd, plus about two weeks for discussion. What is MasterCard and Visa's schedule? Is there an expected delivery date?
BILL FILLETTI: My understanding is EARLY in the first quarter of 1996
EINAR ASBO: No, it's just 'the first quarter. We will republish a merged document by April Fool's Day. However, it should be immaterial to this project, if this project is really about payment negotiation. If this project stops when it calls a payment module, we would be very happy.
UNIDENTIFIED: Selection of the payments may be bound by the regulatory environment.
TOM WILLS: We haven't looked at this yet, but it is very important.
EINAR STEFFERUD: Once you've chosen a payment system, you have to abide by that system, e.g. chargeback vs. First Virtual's two-phase loopback.
EDWARD RITSCHER: Yes, even ACH's have different rules for the different protocols.
JIM MILLER: This is one of the main issues in the FSTC e-commerce working group, but it's the kind of issue we want Dan to track for us on the Steering Committee.
RICK JANOWSKI: We may want to be able to integrate with the shopping cart model. If the discussion over payments model can affect the basket of goods, then we need to acknowledge that (i.e.,. buy two more, get one free). You need to maintain some state so you can go back and add/modify/delete.
ALLAN SCHIFFMAN: I have a technical opinion I won't go into here, but I will note that some amount of "order revision" will come up within the payment protocol (i.e.,. back-order payments, etc.). I would say separate this out, since it's a very messy problem: the process of purchasing goods is not as formal as you might imagine.
TOM WILLS: I move that a deliverable for January 23 is to determine exactly when our work begins and ends.