Minutes of the Electronic Commerce DSIG 4th June 1996 Minutes: Jonathan Legh-Smith Attendees Greg Newman, Oracle Corp gsnewman@us.oracle.com Ralph Brown, Timo Warnor Cable ralph.brown@twcable.com Wayne Jerves, IBM wjerves@vnet.ibm.com Kent Steffen, Andersen Consulting kent.a.steffen@ac.com Jonathan Legh-Smith, BT jleghsmi@jungle.bt.co.uk Michael Tao, SGI tao@sgi.com Chris Crafford, Verifone crafford@eit.com Gary Lorenz, University of Tulsa lorenzg@euler.mcs.utulsa.edu James Schneider, Chase Manhattan Richard J Pledereder, Sybase richard.pledereder@sysbase.com Harvey Rubinovitz, Mitre hhr@mitre.org John Warne, Nortel jpw@nortel.co.uk Naotiko Mori, Nippon CALS Research Partnership mori@ncals.cif.or.jp Jeff Kyser, Kurt Salman Associates jeff@kurtsalman.com Melony Katz, Mitre mkatz@mitre.org Ron Zahavi, Concept Five rzahavi@concept5.com Ken McCoy, Tandem mccoy_ken@tandem.com John Wankmueller, Mastercard john_wankmueller@mastercard.com Welcome Greg Newman, Chair This is 3rd OMG meeting for the "group". Prior to thisthe "group" met as the Object Definition Allianceindependently of the OMG. The specific goals for this meeting will be: _ to develop an RFP for ElectronicPayment _ an RFI for Content Management _ to become a Task Force _ to approve minor changes to the Mission Statement for theEC DTF Note that the EC DSIG must become a Task Force before it can issue RFPs orRFIs. The vote will take place on Friday 7th June. There is the potential for overlap with Finance and Business Object Task Forces however Greghas been communicating with the chairs of relevant groups. Specifically,the Finance DTF have been consulted about the Electronic Payment RFP and itis possible that it will be issued jointly. The EC DSIG/DTF will require a Roadmap and Architecture. A roadmap has beensketched out at the previous meeting but will be developed fully at thenext meeting. Similarly an Architecture will need to be developed butintend to initiate the Electronic Payment RFP before tackling this. There is also a great deal of overlap with other external organisations.There are currently four separate groups working on Electronic Payment: theW3C, FSTC (Financial Services Technology Consortium), CommerceNet, and nowthe OMG. The first three have recently joined to form a joint group called JEPI - Joint Electronic Payment Initiative. Tom Willis, CommerceNet and chair of JEPI, has contacted Greg and invited the OMG EC SIG/TF to join JEPI. The OMG's role in JEPI would be to develop the relevant CORBA specifications. Jon Siegal willbe setting up the liaison through the Liaison Sub-Committee - the intentionis for the OMG to join JEPI as a member. Greg is looking for participants to work on the RFP outside of the meeting,and also a volunteer to act as liaison representative to JEPI. Presentation: Importance of Public Key Technology in ElectronicCommerce John Warne Manager for Security Technology and Services, Nortel Slides will be made available electronically. John's concludingstatements were: _ Public Key Technology simplifies keymanagement and distribution _ it puts and keeps secrets where they belong _ minimises secret key sharing _ permits both off-line and on-line working _ facilitates digital signatures and non-repudiation _ can be used with conventional cryptography for generatingsession keys _ active focus in OMG security SIG - important to ElectronicCommerce Key areas in Security SIG of relevance to Electronic Commerce Ken McCoy, Tandem There are a number of areas that were not addressed in the first Securityspecification. One was interoperability: Secure IIOP. Another was securityrequirements for electronic commerce. Secure IIOP was originally scheduled to complete at this meeting but hasbeen extended to the Madrid meeting. Are looking for out- of-the-boxinteroperability. Critical factor concerning private vs public keytechnologies, or rather how to combine technology to ensure that today's products are capable of working with whatis now emerging technology. The following are key security requirements for supporting EC, particularlyin the Internet: _ Federated Security Domains _ Distributed Authorisation Credentials, centrally managed _ Distributed Policy Management, Centrally managed _ Hierarchy of Certificate Authorities Services _ Certificate Signing and Validations Servers _ Standardised Internet Security Model The Security SIG is now considering its relationship with otherorganisations such as W3C, IETF etc. There is already common personalmembership and notably the Secure IIOP submissions are all based on draftor accepted IETF standards. Secure Electronic Transactions SET John Wankmueller, Mastercard, john_wankmueller@mastercard.com Slides have been made available electronically. Principles in development of SET: _ Open and non-proprietary: in publicdomain _ Platform independent _ supports multiple models for EC _ Built on existing standards _ Interoperable _ Reference Implementation available royalty-free They are looking for an industry/world-wide root certification authorityfor all public keys and are currently trying to identify a suitable body toundertake this. The failure model is based on idempotency. That is, the same purchaserequest can be submitted many times but the request will only be processedonce. Those Merchants that operate over the Internet may well accumulate and store sensitive information e.g. card numbers. Although SETdoes not require information such as card numbers to be passed to theMerchant, it may be necessary to do so e.g. to cater for the requirementsof legacy back-end systems. This implies that there should be requirements placed on the Merchants to ensuresecurity e.g. firewall, encryption of data. This has been recognised butrules have yet to be established. SET documentation is available at http://www.mastercard.com Chris Crafford, VeriFone Slides will be made available electronically. Current issues and requirements were summarised as follows: Current issues Requirements Emerging Internet payment open product architecture infrastructure toaccommodate technology ad payment method advances new payment methods are likely payment transactions are not proven security solutions secured (SET)specifications are not sufficient for full payment process Product support Transaction fees are high compliance with due to risk industrystandards (SET) payment is not a end to end paymentsolutions corebusiness for the from proven suppliers Internet browser/server vendors solutions don't scale for solutions that mass merchant distribution allowscaleability and can roll out through acquirer - merchant distributionchannel Electronic Payment RFP Discussion John Siegal described the RFP process. Richard Herbert, ICL, is the representative from the Architecture Board There was discussion about how to start the work of the EC DTF. E.g. architecture first, then roadmap, then RFPs. Greg Newman and Richard Soleynoted that any work on an architecture and roadmap before the first RFP islikely to be changed as a result of the adopted specification. Consequentlythe group agreed to outline the area in sufficient depth to scope the first RFP. The group discussed the interactions between the principal roles in EC:Certification Authority, Consumer, Merchant, Acquirer and Issuer. Theconclusions i.e. the set of interactions will be documented by GregNewman. It was noted that the Charter for task force only covers consumer to"bank" interactions. Any work on bank-to-bankinteraction would have to be discussed with the Financial DTF. Payment Types Credit Cards Debit Cards Micro Payment Electronic Cash Electronic Checks Stored-value cards EFT Other (Frequent Flyer,etc.) Security Audi Acce Admini Author Datai Authen Priv Non- t ss strati izatio ntegr ticati acy repudi Cont on ity n on ation rol Transaction X X X X X X X Security SystemSecuri X X X X ty Firewall Security Certificate Authority Model Interfaces Consumer->Merchant I. Payment Negotiation II. Issuance of Payment ( I want to pay) A. Payment(ecash) B. Request for authorization(credit, debit,_) III. Status Query (what is the status of an order) IV. Transaction Summary (History of what has been purchased in thepast) V. Receipt - detail of what was purchased VI. Return (Request for a return) VII. Cancel Merchant->Cunsumer 1.Payment Negotiation Response 2.Payment Response 3.Query Response 4.Transaction Report 5.Receipt Generation 6.Credit Issuance 7.Cancel Confirmation Consumer -> Certification Authority 1.Request Certificate 2.Verification of other certificates 3.Revocation of certificate Certification Authority -> Consumer 1.Issue Certificate 2.Verify Certificate 3.Revoke Certificate Acquiring Institution-> Consumer 1.Callback Messaging ??? 2.Cash on Card Consumer -> Issuing Institution 1.Request for transaction summary 2.Transaction Query 3.Dispute 4.Payment 5.Profile Modification Issuing Institution->Consumer 1.Transaction Summary Report 2.Payment Device Revocation 3.Transaction Query Report 4.Dispute Resolution 5.Billing 6.Profile Modification Merchant -> Acquiring Institution 1.Authorization Request 2.Settlement Request (sum total) 3.Capture(individual transaction items) 4.Dispute 5.Return 6.Status Request Acquiring Institution-> Merchant 1.Authorization Authentication 2.Settlement Response 3.Capture Response 4.Dispute Response 5.Return Response 6.Status Response Acquiring Institution to Issuing Institution Existing Legacy System End of Minutes for 4th June ================================================================= =====