OII Standards and Specifications List

I'M Europe
OII Home Page
What is OII?
Whats New in OII?
  • Monthly reports
  • Conferences
    OII Fora List
    OII Guides
    OII Index
    OII Feedback *
    Search Database

  • OII Guide to Electronic Commerce

    The OII Standards and Specifications List provides a chapter on Electronic Commerce, structured in accordance with key processes. This compendium OII Guide to Electronic Commerce is intended to provide additional information on current activities in Electronic Commerce which have a standardization perspective. It is divided into the following major sections:

    Electronic Commerce is about doing business electronically (European Commission Communication on A European Initiatives in Electronic Commerce, COM(97)157, available at http://www.ispo.cec.be). Given the broad scope of Electronic Commerce and the current world-wide interest in this area, the following information can only be indicative and should not be construed as either comprehensive or exhaustive.

    Section Contents
    OII Documents
    OII Index
    OII Help

    Technical approaches

    The following is an overview of some of the key approaches to define a technical model for Electronic Commerce. It should be noted that these models vary considerably in scope – some aim to provide a complete "architecture" (or "framework", "reference model"), whereas others focus on particular aspects of Electronic Commerce. Direct comparison between these models is difficult, and indeed inappropriate, as their development is motivated by different purposes. This is attributable to the identity of the providers of these models, who include standardization bodies, different types of industry consortia, and industry initiatives driven by specific vendors. However, what is common across these models is their attempt to address the technical requirements of Electronic Commerce in a coherent and systematic manner.

    Further information on the standardization bodies and industry consortia referenced in this section is available from the OII Fora List.

    With the exception of the (more established) Java Electronic Commerce Framework, this section does not include the Electronic Commerce frameworks announced by specific individual vendors recently (such frameworks are also known as "platforms", defined in CommerceNet's White Paper on eCo System as "frameworks that define APIs" and which function as middleware). They will be added to this section in future editions.

    Note: These frameworks/platforms include IBM CommercePoint, Microsoft Internet Commerce Framework, Netscape Open Network Environment, Oracle Network Computing Architecture.

    This section includes information on:

    All of these technical models are expected to continue to evolve. They are yet to be translated into commercial product or service implementations. These models should, therefore, be viewed with extreme caution.

    CommerceNet's Architectural Framework for Internet Commerce (eCo System)

    CommerceNet described eCo System as its "flagship project" for 1997. A White Paper on eCo System is available at the CommerceNet Website at http://www.commerce.net.

    The objective of the eCo project is to:

    • Develop an object-oriented architectural framework for Internet commerce that promotes the interoperation and reuse of applications and services
    • Establish an ongoing process for achieving broad industry consensus on issues of interoperability and reuse critical to open digital markets.

    The eCo System is intended to be "a framework of frameworks" which model key business processes and services for building Internet Markets ("iMarkets"). According to CommerceNet, there is "a unique opportunity" to create a truly open architectural framework for Internet commerce that will be fully compatible with leading proprietary platforms and synthesise their "unique strengths".

    The focus of the eCo project is on de facto interoperation, rather than on de facto standards ("the IT industry is moving so fast that there's seldom time even for de facto standards to emerge"). This means getting incompatible products that are already in the marketplace "somehow" to communicate. This may be accomplished through negotiation protocols ("I don't care what standard you use, just tell me what it is and I'll speak it"), bridging gateways, and mediators (smart gateways).

    The eCo System framework is conceived to consist of:

    • Applications and services that model real markets and business processes
    • A Common Business Language so that applications can communicate using messages and objects analogous to those used in real commerce
    • An extensible set of interface specifications, class libraries and network services so that applications can be quickly assembled from existing components and subsequently reused themselves
    • A layer of middleware that insulates applications from each other and from platform dependencies.

    Each eCo System framework can be categorised according to: Vetical Market, Business Process & Applications, Commerce Services, and Network Services. In the eCo System, each framework specifies:

    • The core services that all application objects belonging to that class (e.g. payments, catalogues) must provide
    • A network services interface (NSI) - a set of messages for requesting the core services
    • The business objects on which the services operate, e.g. invoices, contracts, products, companies
    • The APIs for any software modules (or cartridges) involved in delivering services.

    It should be noted that the NSI messages, business objects and product taxonomises constitute the Common Business Language (CBL) in the eCo System. CBL is intended to be an alternative to the "ad hoc" text strings currently used in EDI systems.

    The eCo System White Paper provides preliminary documentation of how various existing Electronic Commerce frameworks could be implemented within the overall eCo framework. According to the White Paper, the framework will leverage commercial Internet platforms such as IBM CommercePoint, Netscape Open Network Environment, and Sun Java Electronic Commerce Framework. It will also use emerging standards such as CORBA 2.0 ORB, IIOP, Java and HTTP/HTML.

    EBES/EWOS Building Blocks for Electronic Commerce

    In this EBES/EWOS report, sponsored by the European Commission DG III/B2, the concept of Electronic Commerce building blocks is developed as an analytical tool to identify the key technical components for Electronic Commerce and to position the example products and services currently on offer or planned. The building blocks approach is then applied for assessing the likely impact of specific legal and regulatory measures on the technical infrastructure of Electronic Commerce and for identifying the critical components and/or interfaces for interoperability. The objective is to identify and categorise the key issues which are of public interest through a comprehensive and systematic examination of the relationships and interactions between the technical, legal/regulatory, and standardisation dimensions of Electronic Commerce.

    The report was submitted to the European Commission in October 1997 and is available athttp://www.ebes.cenclcbel.be/structur/ebes/project/prb/prbinfo.htm. See also the OII Fora List entries on EBES and EWOS.

    The primary audiences of this report are Electronic Commerce policy makers and standardisers.

    Building blocks are derived from the sub-processes which comprise the commercial activities of Electronic Commerce. They are defined as (Electronic Commerce specific) functions which may be implemented into a discrete Electronic Commerce product or service. Three categories of building blocks have been identified in relation to where it "belongs" (buyer, seller or the commercial/third party service) and its relationship with other building blocks. Using the building blocks technology, two further basic concepts are defined – solutions, defined as the implementation of a building block, and solution sets, defined as a set of integrated products or services in which a number of implemented building blocks are being used together to provide a complete Electronic Commerce functionality.

    The following local building blocks are identified. A local building block is defined as a building block that belongs to the seller or buyer and interfaces with another local building block which typically belongs to a trading partner.

    Processes Building Blocks
    Marketing Consult/build up product catalogue
    Publish/extract/analyse information
    Request/give quotation
    Collect/save goods in shopping basket
    Contracting Order/confirm order
    Register confirmation/replenish stock
    Cancel order/accept order cancellation
    Logistics Receive goods/request forwarding of goods
    Settlement Select payment methods
    Credit card payment wallet
    Ecash payment wallet
    Reconcile payment
    Interfacing with Administration VAT reporting
    Notify Customs on export transaction

    A service building block is defined as a building block which belongs to a commercial service. This service is provided by a third party. It is accessed by an access building block.

    The following services building blocks are identified:

    • Payment services offered by acquirers/issuers, e.g. credit card acquiring, ecash acquiring
    • Trusted third parties, e.g. registration, certification, data archiving, directory services.

    Based on the building blocks analysis, the report provides 15 recommendations on policy setting and specific technical areas for action in Electronic Commerce standardization.

    Java Electronic Commerce Framework (JECF)

    JECF is a structured architecture for the development of Electronic Commerce applications in Java. Published by Sun, it aims to provide functionality that reduces the time and effort developers require to build Electronic Commerce applications. JECF is intended to be the foundation for electronic wallets, point of sales terminals, electronic merchant servers and other financial software. Further information is available at http:/java.sun.com.

    JECF defines application responsibilities for merchants and financial institutions. JECF provides services, such as database services, to merchant and financial institution applications. The layers of the framework are depicted below.

    The Merchant Applet Layer uses Java applets as an appropriate way to implement short term customer relationships such as shopping experience. Example of consumer applets are shopping cart applets and content charging applets. Examples of bank applets include loan questionnaire applets. Applets are downloaded from servers to client computers

    The Cassette Layer implements long term customer relationships such as credit cards, home banking and brokerages. Cassettes are downloaded from servers to client computers. Unlike applets, which disappear when users quit the browser, cassettes are retained on the customer's system. Cassette may safely store valuable information such as public key certificates and transaction records. Examples of cassettes include SET certificates and protocols, home banking, etc.

    The Java Commerce Package Layer implements the infrastructure needed by the merchant and the cassette layers. Features at this layer include a user interface, an application model, a data base, and access to strong cryptography.

    The Java Environment Layer is the underlying browser or operating system.

    The Merchant Applet and Cassette Layers are downloaded from the merchant or financial institution into the consumer computer in order to enable the security protocol between the two partners. They can be described as "customised" Electronic Commerce building block for a specific consumer.

    The Java Commerce Package Layer includes common or basic functions allowing commerce relationship. This can be described as generic building blocks which is needed in every consumer's computer.

    The Java environment layer is the platform running the above layers and is not Electronic Commerce specific.

    Object Management Group Electronic Commerce Reference Model

    This architecture is developed by the Object Management Group Electronic Commerce Domain Task Force. The goal of this task force is to define and promote the specification of OMG distributed object technologies for the development and use of Electronic Commerce applications. The architecture is available at http://www.osm.net/ec-dtf/index.html.

    See also the OII Fora List entry on OMG.

    The rationale for the development of an Electronic Commerce Reference Model is based on the basic assumption that there is a need for:

    • Defining a Framework for establishing inter-relationships between domains
    • Identifying Electronic Commerce Domain Facilities
    • Developing a Roadmap for technology adoption.

    Objects representing the most significant needs by the broadest range of user communities are the top priority of the Electronic Commerce Task Force.

    The Electronic Commerce Reference Model is currently under development. The model takes into account currently adopted and emerging OMG Standards.

    Specifically, the Reference Model is based on OMG’s Object Management Architecture, which identifies and characterises a generic set of components, interfaces, and protocols. These include the Object Request Broker (ORB) component that enables client and objects to communicate in a distributed environment, and four categories of object interfaces:

    • Object Services are interfaces for general services that are likely to be used in any program based on distributed objects
    • Common Facilities are interfaces for horizontal end-user-oriented facilities applicable to most application domains
    • Domain Interfaces are domain-specific interfaces for application domains such as Finance, Healthcare, Manufacturing, Telecom, Electronic Commerce, and transportation
    • Application Interfaces are non-standardised application-specific interfaces.

    The Electronic Commerce Reference Model references a set of OMG Common Facilities and Service Objects – the "building blocks" for the Electronic Commerce Application Frameworks. It should however be noted that unlike the EBES/EWOS approach (which defines building blocks in terms of commerce processes and sub-processes), each Common Facility is handled as a real object offering interfaces to other objects.

    These Common facilities are divided into three principal groups:

    • Low level Electronic Commerce services including payment, profile and selection services
    • Commerce facilities supporting contract, service management and related desktop facilities
    • Market infrastructure facilities covering catalogue, brokerage and agency facility.

    Each facility is described in the following table.

    Common Facilities Description


    A selection service supports the selection and configuration of supporting facilities across a set of independent domains involved in an Electronic Commerce transaction. It meets generalized federation requirements introduced under inter-domain commerce (ex: disclosure of information).


    Interactions between a buyer and a seller, and any necessary third parties, for the successful electronic exchange of value for goods or services provided.


    A profile is a data object that is provided by a service provider or consumer to describe a service offered or requested. It is a portable, persistent container for arbitrary data objects . It comprises standardized information and information specific to distinct applications.


    Object framework encompassing both the static contractual perspective of a real-world contract and the dynamic perspective under the context of a common and potentially dynamically changing policy.


    Object framework which supports the separation of declared interfaces between the consumer, the provider and any third-party involved in an EC transaction.

    Intellectual Property Rights

    Provides the support for the management and administration of Intellectual Property Rights, including copyright and ownership.


    A structured object that can be inspected, browsed and transferred through the network.


    Facility to allow users (information consumers and providers) to be more focused in dealing with information about commercial services in the global electronic market. It allows information consumers to focus requests for information towards the pertinent sources of information.


    Facility to allow the establishment of a formal access point and public query interface for a player in an electronic marketplace. This access point returns information about the agency such as: protocol of the interface, name, resources (certificates), ability, policy.


    The object browser and navigator facility introduces an extendible framework for the inspection, presentation and execution of Electronic Commerce entities.

    Secure Electronic Market Place for Europe (SEMPER)

    SEMPER is a European Commission funded R&D project under DG XIII's ACTS programme in the area of secure Electronic Commerce over open networks, especially the Internet.

    The SEMPER consortium comprises some twenty partners from multiple disciplines, including finance, retail, publishing, IT, telecommunications, publishing and academia. Led by the IBM, notable partners are DigiCash, KPN Research and Europay International.

    The objectives of SEMPER are to provide:

    • A detailed description of commercial, legal, social and technical requirements and options for an electronic market place
    • A coherent model and a generic, open architecture of an electronic market place, independent of specific hardware, software and network architectures
    • Specifications, designs, prototype implementations and evaluations for services enabling Electronic Commerce
    • Information to the technical, scientific, standards communities and the general public.

    The project falls into two main parts - a non-technical requirement part which is based on the existing expertise within the consortium, as well as expert surveys performed in different European countries; and a development and trial part which is organised into three phases, each phase corresponding to an enhanced set of services and trials:

    • The first phase concentrates on two topics: the development of a framework and architecture for secure Electronic Commerce, and the provision of fundamental Electronic Commerce services within this framework (i.e. offering, ordering, payment and delivery for information services)
    • The following phases will concentrate on extending the architecture and developing more advanced services (e.g. notary services, attribute certificates or credentials with specific privacy properties, and multimedia specific security services such as protection of intellectual property).

    At the time of writing (September 1997), SEMPER has published draft specifications on Basic Services: Architecture and Design andArchitecture of Payment Gateway, as well as results from the first year of the project (Survey Findings, Trial Requirements, and Legal Framework). These documents are available at http://www.semper.org.

    SEMPER is probably the most ambitious example of architectural concepts and definitions for an Electronic Commerce framework which has been developed with European Union funding. The SEMPER architecture specifies a number layers:

    • Commerce Layers
    • Exchange Layers
    • Transfer Layer
    • Supporting Services Layer.

    For the Supporting and Transfer Services Layer, generic service blocks have been defined:

    For Transfer Layer services

    • Payment
    • Certification
    • Statement

    For Supporting Services Layer

    • Archive
    • Comms
    • Crypto
    • Preferences
    • Access control.

    In addition, the actual implementation also contains a utility block with various utility services for, e.g., converting objects into streams of bytes, logging and debugging.

    The SEMPER service blocks are intended to offer considerable flexibility by hiding complexity or variation behind the block definition. For instance, a variety of payment protocols are envisaged to be supported by the payment service block.

    The key properties of the SEMPER architecture in relation to possible standardization activities are:

    • SEMPER does not attempt to impose solutions in other areas. Such solutions may therefore be realised either completely independently of the existing architecture, or by extension of the SEMPER approach.
    • The architecture has been specified independent of any particular distributed systems architecture, although the implementations and pilot applications are expected to be based on the use of Java.
    • The service blocks which comprise the architecture are intended to meet the requirement of existing and emerging protocols in so far as they are known. While the architecture is intended to be "frozen" later in 1997, it may need to be extended in the future; alternatively, new protocols may need to be retrofited into the SEMPER architecture. On this analysis, the standardisation activity should focus not so much on the service blocks themselves, but the interfaces between them.
    • The SEMPER architecture is based on certain assumptions about the actors in Electronic Commerce and their roles. In view of the proliferation of electronic commerce architectures and solution sets, a common definition of these actors and roles is considered to be desirable.

    Section Contents
    OII Documents
    OII Index
    OII Help

    Policy issues

    (This section is under development.)

    Section Contents
    OII Documents
    OII Index
    OII Help

    Overview of activities and initiatives

    This section provides a listing of some of the key activities and initiatives which directly relate to or impact on Electronic Commerce standardization. They are categorised according to the geographical scope of the originating organisations:

    Entries are listed alphabetically under each of the above headings.


    G7 Information Society Pilot Project "A Global Marketplace for SMEs"

    Objectives and Framework for Action, and other on-line publications

    See http://www.ispo.be/Ecommerce.

    Global Information Infrastructure Commission

    Recommendations for Promoting the Use of Electronic Commerce

    See http://www.gii.org/.

    ISO/IEC JTC 1 Business Team on Electronic Commerce

    A number of Electronic Commerce scenarios are under development

    See http://www.din.de/ni/aktuell/j1btechtml/index.html.


    Working on a range of topics pertaining to Electronic Commerce, including:

    • Guidelines for Cryptography Policy, 1997
    • Report on Consumer Redress in the Global Market - "Chargebacks", October 1996, and follow-on activities
    • Report on Business-to-Consumer Electronic Commerce ("Sacher Report"), August 1997
    • Project on "Technology, Productivity and Job Creation", Second Phase (covering electronic publication, multimedia services, electronic payment), under preparation
    • Activities on Electronic Payment in the context of Tax Policy and Administration, ongoing
    • Agreement on Harmful Content on the Internet, under consideration

    See http://www.oecd.org/dsti/.

    The Open Group

    (See OII Fora List entry on The Open Group)

    Security and Electronic Commerce programme, whose publications include a Draft technical architecture on Public Key Infrastructure, 1997 (See http://www.rdg.opengroup.org/public/tech/security/index.htm.)

    UNCITRAL Working Group on Electronic Commerce

    Model Law on Electronic Commerce, May 1996

    Report on Planning of Future Work on Electronic Commerce: Digital Signatures, Certification Authorities and Related Legal Issues, February 1997

    Uniform Rules on Digital Signature, forthcoming


    Various activities related to the Simplification of Business Processes, EDI and the Internet, Security, etc, under progress

    World-Wide Web Consortium (W3C)

    (See OII Fora List entry on W3C)

    Specification of Joint Electronic Payment Initiative (with CommerceNet), 1996

    Specification of Platform for Internet Content Selection (PICS), 1996

    Specifications on Public Key Infrastructure, (under development)

    Proposal for an Open Profiling Standard, June 1997

    Working draft of Digital Signature Initiative (Dsig) 1.0 Signature labels, June 1997

    Working draft of Platform for Privacy Preferences (P3), 1997-09-29

    Electronic Commerce Interest Group

    Public Policy Interest Group

    See http://www.w3.org/Areas


    CEN Information Society Standardization System (CEN/ISSS)

    Electronic Commerce Technical Steering Group, whose publications include:

    CEN/TC224-ISO/TC68/SC6 Study Group on Electronic Commerce

    Study on card related secure commercial and financial transactions and related payments on open networks, on-going

    Plus other pending projects in Electronic Commerce

    Electronic Commerce Europe

    Launched in April 1997 as an "association of associations" in Electronic Commerce.

    See http://www.ec-europe.de/.

    European Commission

    Among the many publications of the Commission related to different aspects of Electronic Commerce, the most immediately relevant document is European Initiatives in Electronic Commerce, COM(97)157, available at http://www.ispo.cec.be.

    Of particular importance also is the Ministerial Declaration on Global Information Networks from the Ministerial Conference in Bonn, 6-8 July 1997. See http://www.echo.lu/bonn/final.html.

    In addition, the EPHOS (European Procurement Handbook for Open Systems) Module on Electronic Commerce is expected to be shortly available at http://www.nethotel.dk.ephos/.

    High Level Industry Advisory Group on Information Society

    Final Report of Working Group 2 on Standardisation and Electronic Commerce, 31 October 1996

    Discussion Paper (including recommendations on actions), December 1996

    High Level Strategy Group for ICT Standards

    Report No.2: Barriers to Electronic Commerce in support of SMEs, Edition 1.0, November 1996

    MoU on Open Access to Electronic Commerce for European SMEs

    Various MoU Working Groups, covering:

    • Inter-operation Protocols for Transaction Billing, Verification and Confidentiality
    • Protocols for Interoperation of Directories of Small Business Services
    • Protocols Supporting the Exchange of Legally Binding Documents and Signatures
    • Rights and Responsibilities

    United States


    Working Group 4 on User/Content Provider Standards Requirements

    Progressing with various Electronic Commerce issues

    See http://www.ansi.org/iisp/.

    Clinton Administration

    A Framework for Global Electronic Commerce, July 1997

    See http://www.iitf.nist.gov/eleccomm/ecomm.htm.


    Various pilots, projects and publications, including:

    In addition, CommerceNet and Information Technology Association of America has announced a joint industry initiative to advance the Clinton Administration's Electronic Commerce Framework.

    See http://www.commerce.net/.

    Cross-Industry Working Team

    Electronic Commerce in the NII, October 1995

    See http://www.xiwt.org/documents/EComm_doc/ECommTOC2.html.


    Ministry of International Trade and Industry (MITI)

    Towards the Age of the Digital Economy - For Rapid Progress in the Japanese Economy and World Economic Growth in the 21stCentury, Draft, May 1997-09-29

    See http://www.miti.go.jp/intro-e/a228100e.html.

    Section Contents
    OII Documents
    OII Index
    OII Help

    This information set on OII standards is maintained by Martin Bryan of The SGML Centre and Man-Sze Li of IC Focus on behalf ofEuropean Commission DGXIII/E.

    File last updated: September 1997

    Home - Gate - Back - Top - Commerce - Relevant