TRADE Working Group                                          Werner Hans
INTERNET-DRAFT                                    Hans-Bernhard.Beykirch
                                                                     SIZ
                                                          Masaaki Hiroya
                                                      Yoshiaki Kawatsura
                                                                 Hitachi
Expires: September 2000                                       March 2000




 Architecture and Payment API for Internet Open Trading Protocol (IOTP)
 ------------ --- ------- --- --- -------- ---- ------- -------- ------
                <draft-ietf-trade-iotp-v1.0-papi-00.txt>


Status of this Memo

   This document is intended to become an Internet-Draft and will be in
   full conformance with all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   
     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

   Distribution of this document is unlimited. Please send comments to
   the TRADE  working group at <ietf-trade@lists.elistx.com >, which may
   be joined by sending a message with subject "subscribe" to <ietf-
   trade-request@lists.elistx.com>.

   Discussions of the TRADE working group are archived at
   http://www.elistx.com/archives/ietf-trade.



Abstract

   The Trading Architecture proposes an abstract layered model of the
   IOTP based trading environment. Its description sketches the
   essential functional and data modules and their interfaces at each
   trading role's installation. This abstract view deals as a guideline
   for the modules' mapping to actual software modules.

   The second part of this document focuses on the Payment API that


Werner, et al                                                   [Page 1]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   improves the essential interface that relates to payment
   transactions. Such interface exists at the Consumers', the Merchants'
   and the Payment Handlers' installations connecting the actual payment
   software components/legacy systems and the generic IOTP aware front
   end application.



Copyright

   Copyright (C) The Internet Society 2000.









































Werner, et al                                                   [Page 2]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


Table of Contents

      Status of this Memo........................................1
      Abstract...................................................1
      Copyright..................................................2

      Table of Contents..........................................3
      1. Introduction............................................6
      1.1  Intended Readership...................................8
      GENERAL TRADING ARCHITECTURE...............................8
      2. Trading Architecture....................................8
      2.1 Overview...............................................8
      2.1.1 Layers and Components................................9
      2.1.1.1 Consumer Access - End System Layer................10
      2.1.1.2 Network Layer.....................................11
      2.1.1.3 Access Layer......................................11
      2.1.1.4 Refinement Layer - Integration with IOTP..........11
      2.1.1.5...................................................12
      2.1.1.6 Data Layer........................................12
      2.1.2 Implementation Variants.............................12
      2.1.3 Component Distribution..............................12
      2.2 Requirements and Commitments..........................12
      2.2.1 Basic Requirements..................................13
      2.2.1.1 Electronic Commerce Provider (Server).............13
      2.2.2  Security Requirements and Commitments..............13
      2.2.2.1  Overview about the Security Levels...............13
      2.2.3  Security Mechanism.................................14
      2.2.3.1  Transmission Security............................14
      2.2.3.2 Authentication....................................15
      2.2.3.3 Document Security.................................15
      2.2.3.4 Authorization.....................................16
      2.2.4  Protection against Attacks.........................16
      2.2.4.1  Consumer System..................................17
      2.2.4.2  Transmission Line................................17
      2.2.4.3  Provider's Computing Center......................18
      3.  Layers and Functional Components......................18
      3.1  End System Layer.....................................19
      3.1.1 Presentation Software...............................20
      3.1.2  Document Formatting................................20
      3.1.3  Document Security..................................21
      3.1.4  Transport Coupling.................................21
      3.1.5  Maintenance........................................21
      3.2  Network Layer........................................21
      3.3  Access Layer.........................................22
      3.3.1  Transport Coupling.................................23
      3.3.1.1  Network Protocols................................23
      3.3.1.2  Transmission Security............................24
      3.3.1.3  Access Protection................................24
      3.3.1.4  Presentation Control Monitor.....................24
      3.3.1.5  Parameterized Subsystem Distribution.............25


Werner, et al                                                   [Page 3]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


      3.3.1.6  Frame Dialogs....................................25
      3.3.2  Presentation Services..............................26
      3.3.2.1  Native presentation (standard)...................27
      3.3.2.2  Optimization.....................................27
      3.3.2.3  Transport Information............................27
      3.3.2.4  Native Programs..................................28
      3.4  Refinement Layer.....................................28
      3.4.1  Format Conversion..................................29
      3.4.2  Document Security..................................30
      3.4.3  Format Optimization................................30
      4.  Recapitulation........................................30
      4.1  Example Justification................................33
      5.  Progress Example......................................35
      6.  TCP/IP - WWW, Java Implementation Variant.............40
      6.1  Consumer's Sphere....................................42
      6.2  Provider's sphere....................................43
      IOTP Payment API..........................................43
      7.  Payment API...........................................43
      7.1  Introduction.........................................44
      7.2  Assumptions..........................................45
      8.  Message Flows.........................................50
      8.1  Authentication Documentation Exchange................54
      8.2  Brand Compilation....................................55
      8.3  Brand Selection......................................58
      8.4  Successful Payment ..................................61
      8.5  Payment Inquiry......................................65
      8.6  Abnormal Transaction Processing......................67
      8.6.1  Failures and Cancellations.........................67
      8.6.2  Resumption.........................................69
      8.7  IOTP Wallet Initialization...........................69
      8.8  Payment Software Management..........................70
      9.  Mutuality.............................................70
      9.1  Error Codes..........................................73
      9.2  Attributes and Elements..............................82
      10.  Payment API Calls....................................94
      10.1  Brand Compilation Related API Calls.................94
      10.1.1  Find Accepted Payment Brand.......................94
      10.1.2  Find Accepted Payment Protocol....................95
      10.1.3  Get Payment Initialization Data...................97
      10.1.4  Inquire Authentication Challenge..................99
      10.1.5  Authenticate.....................................100
      10.1.6  Check Authentication Response....................101
      10.1.7  Cancel Payment...................................102
      10.2  Brand Selection Related API Calls..................103
      10.2.1  Find Payment Instrument".........................103
      10.2.2  Find Payment Protocol............................105
      10.2.3  Check Payment Possibility........................107
      10.2.4  Quit Payment Instrument..........................109
      10.3  Payment Transaction Related API calls..............110


Werner, et al                                                   [Page 4]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


      10.3.1  Start Payment Consumer...........................110
      10.3.2  Start Payment Payment Handler....................112
      10.3.3  Resume Payment Consumer..........................115
      10.3.4  Resume Payment Payment Handler...................116
      10.3.5  Continue Process ................................117
      10.4  General Inquiry API Calls..........................120
      10.4.1  Inquire Payment Log..............................120
      10.4.3  Payment Instrument Inquiry.......................124
      10.4.4  Inquire Pending Payment..........................126
      10.5  Payment Related Inquiry API Calls..................127
      10.5.1  Check Payment Receipt............................127
      10.5.2  Expand Payment Receipt...........................128
      10.5.3  Inquire Process State............................129
      10.5.4  Start Payment Inquiry............................131
      10.5.5  Inquire Payment Status...........................131
      11.  Called Functions....................................134
      11.1  Call Back Function.................................135
      11.2  Work and Payment Log Database Function.............136
      12. Security Consideration...............................141
      Full Copyright Statement.................................141
      References...............................................141
      Author's Address.........................................142
      Expiration and File Name.................................143



























Werner, et al                                                   [Page 5]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


1. Introduction

   Common network technologies base on standardized and established
   Internet technologies. The Internet technologies provide mechanisms
   and tools for presentation, application development, network
   infrastructure, security, and basic data exchange.

   The Internet Open Trading Protocol (IOTP) [RFC XXXX] is such an
   Internet technology that specifies a generic protocol for Internet
   trading. IOTP founds upon a client server model. It defines six
   different trading roles (Consumer, Merchant, Payment Handler,
   Delivery Handler, Merchant Customer Care Provider, and Payment
   Instrument Customer Care Provider) and nine trading transaction types
   (Deposit, Purchase, Refund, Withdrawal, Value Exchange, Inquiry,
   Payment Instrument Customer Care, Authentication, and Ping). But it
   does not depend on any payment method, e.g., SET, CyberCash/Coin,
   Mondex, or GeldKarte.

   The general IOTP objectives are to o  provide the basic trading
   transactions, o  be an interoperable solution, o  be payment system
   independent, o  be extensible and flexible, o  meet immediate
   business needs, o  be an application level protocol, o  be transport
   level independent, and o  be client / server architecture
   independent.

   Each trading role uses an IOTP aware application. The client, i.e.,
   Consumer, initiates each type of transaction request while the
   server, i.e., other trading roles, responds to the Consumers'
   requests.

   Due to the presence of already installed trading roles' systems with
   their own interfaces (Internet shop, order management, payment,
   billing, and delivery management systems, or financial institute's
   legacy systems), IOTP defines the common external (Internet)
   interface between these systems. Initially, this consideration leads
   to the two-level layered view of the IOTP software for each role,
   consisting of the generic IOTP frontend part providing IOTP based
   gateway services and the trading roles' specific backend systems
   implementing the actual trading transaction types' functionality.
   These software components communicate with each other and might have
   been even provided by different software suppliers.

   As IOTP extends payment schemes to a trading protocol, the IOTP
   application glues different payment software components. However, the
   Consumers' requirements can be lowered to the sole support of
   multiple payment methods. Therefore, the IOTP application splits into
   three main component types:

   o  the IOTP Application Core processes the generic parts of the IOTP
   transaction and connects to the Internet,


Werner, et al                                                   [Page 6]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  the Existing Legacy System resp. Existing Payment Software
   processes the actual transaction type resp. payment transaction,

   o  the IOTP Middleware resp. IOTP Payment Bridge connects the other
   two components. It extends the Existing Legacy System with an
   interface compatible with the one offered by the IOTP Application
   Core. The latter maps the Payment API calls to the payment software's
   specific calls.

   Actually, the trading architecture splits into five logical layers
   that reflect the aspects of external Internet and user interfaces,
   internal generic IOTP message processing, backend preparation of the
   transaction's content, their processing at the actual application
   layer, and the transaction data management.

   The trading architecture being motivated and introduced in Chapters 2
   to 6 elaborates the essential functional and data modules, maps them
   to the five layers, and sketches their (internal) interfaces.
   Generally, some of these interfaces are specified in public (product)
   documents while others are confidential developer's only interfaces.
   However, the Trading Architecture defines the first step towards an
   actual implementation of an IOTP aware application.

   The typical Payment Handlers, i.e., financial institutes or near-
   bank organizations, require an IOTP aware application that easily
   fits into their existing financial infrastructure. The Payment
   Handler may even insist on the reuse of special in-house solutions
   for some subtasks of the IOTP aware application, e.g., reflecting
   their cryptography modules, gateway interfaces, or physical
   environment. Therefore, their IOTP aware application really needs
   both well defined external and internal interfaces.

   However, the significance of such an architecture depends on the
   product's target group. Generally, Payment Handlers have stronger
   products requirements with respect to modularization and clear
   internal interfaces than Consumers. But even the Consumer's IOTP
   application aims at the support of multiple payment methods.
   Particularly, Consumers prefer the flexible use of different seamless
   integrating payment methods within one trading application with
   nearly identical behavior and user interfaces.

   The second part of the document (Chapters 7 to 11) refines one
   specific internal interface to an actual Application Programming
   Interface (API), i.e., Payment API, that bases on the functional
   specification of Baseline IOTP [RFC XXXX]. This API aims at the
   realization of a plug-in mechanism for payment specific software.
   Currently, several payment software components from different
   suppliers exist. Due to the payment method independence of IOTP, the
   IOTP application must deal with and should provide a mostly common
   interface for them. Therefore, this Payment API proposes an interface


Werner, et al                                                   [Page 7]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   between the generic IOTP Application Core and the Existing Payment
   Software. Although, the highest significance of this API is
   recognized at the Consumer, Payment Handlers offering multiple
   transactions will also benefit, because such an API reduces the
   overhead of integration, customization etc. of the IOTP aware
   application.



1.1  Intended Readership

   Software and hardware developers; development analysts, and users of
   payment protocols.



GENERAL TRADING ARCHITECTURE



2. Trading Architecture

   The general architecture suits for a broad range of applications, and
   several abstract interfaces are identified between the architecture
   components. Of course, such an architecture defines only the initial
   starting point for an incremental process of refinements that ends in
   an actual implementation. This incremental process hides superfluous
   details very long and clarifies the roles of the components and their
   interfaces very early.



2.1 Overview

   The Trading Architecture consists of several layers and components
   providing specific functionality. There exist well- defined
   interfaces between the layers that are introduced in this section.

   Implementation variants are derived from this abstract description.
   For electronic commerce on the Internet, the implementation obviously
   bases on HTML, HTTP, and TCP/IP. However, mobiles and set top boxes
   may introduce other techniques.

   The components can be distributed over different platforms, e.g.,
   main server and server stations. The combination of implementation
   variants and component distribution leads to actual scenarios, e.g.,
   TCP/IP, WWW, and Java on a server station at the merchant or
   financial institute. But these actual scenarios are out of the scope
   of this proposal.



Werner, et al                                                   [Page 8]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
        ------------------  Trading Architecture  ---------
        |                   components that may spread    |
        |                   across layers                 |
        V                                                 V
   Implementation variants  <------------>  Component Distribution
   tcp/ip - www, java                                  main server
   other                                            server station
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
       Figure 1: Relationship between Architecture, Implementation
                    Variant, and Component Distribution



2.1.1 Layers and Components

   An electronic commerce application should support different
   implementation variants. Although WWW obtains the main focus, the
   technologies may change in the future. A separation of the
   application according to current and upcoming technologies must be
   prevented.

   The specification of the Trading Architecture starts with the general
   logical partition of the layers.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   End system layer
   o  Web browser or standard software interacting with the user

   network layer
   o  tcp/ip, other

   access layer
   o  Internet IOTP demon
   o  Internet transport information
   o  frame dialog, presentation services
   o  subsystem distribution
   o  monitor for presentation control

   refinement layer
   o  document security
   o  format conversion

   application layer
   o  electronic commerce application
   o  application monitor
   o  middleware

   data layer
   o  data access


Werner, et al                                                   [Page 9]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  integrity
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
         Figure 2: Architecture Layers and Implementation Examples



2.1.1.1 Consumer Access - End System Layer

   The end system uses the World Wide Web for presentation purposes
   supporting graphical mechanisms for interaction, animated
   graphical objects, photos, audio, and video tracks. In this
   moment, these technologies are already implemented in highly
   available web browsers. These software components are bundled
   with newer releases of operating systems for the consumers'
   personal computers, e.g., Microsoft Internet Explorer with
   Microsoft Windows 95/NT, they come for free (Netscape
   Navigator/Communicator), or can be licensed for a nominal license
   fee. In the future, other networks and devices like set-top boxes
   for Pay-TV will be the target of IOTP implementations, too.

   The Internet features an open network infrastructure between the
   consumer and the service provider for electronic commerce. An
   electronic commerce application must be able to generate the
   complete transaction data, to sign it, and to ensure the
   transmission security. Currently, this demands can not be
   fulfilled by the Web-browser, solely. Instead special helper
   applications have to be installed at the consumer's side.

   Actually, the client-sided end system layer consists also of the
   last three server-sided layers (see below) but they have been
   collapsed for simplicity. For short:

   o  Operating system offered network services belong to the access
   layer.
   o  Web browsers' capabilities spread across the access to the data
   layer.
   o  The functionality of helper applications may spread across
   refinement to data layer.
   o  The IOTP wallet mainly belongs to the refinement layer.
   o  The actual payment software, e.g. SET wallet, inclusive its
   helper applications like chip card reader drivers belongs to
   the application/data layer.

   However, the following discussion of these layers assumes their
   location at the server side.







Werner, et al                                                  [Page 10]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


2.1.1.2 Network Layer

   The network layer is operated by network providers and online
   service providers. Not only the network provider may offer these
   services, they can also be offered by merchants, mall providers,
   financial service providers, and even financial institutes.

   This layer aims at the abstraction from particular network
   services like TCP/IP, HTTP, or Pay-TV networks. Application data,
   i.e., IOTP message content and payment specific data, is
   transparently passed to the refinement layer.



2.1.1.3 Access Layer

   This layer subsumes the standard mechanisms for (Inter)net(work)
   access, i.e.,

   o  operating system offered network access services,
   o  peripherals like modem, packet filter, or firewall,
   o  partial capabilities of Web browsers and HTTP servers, e.g.,
   transmission security, visualisation, logging.

   This layer does not offer any trading services and transparently
   carries IOTP formatted data.



2.1.1.4 Refinement Layer - Integration with IOTP

   Standardized protocols promise strong flexibility for the choice
   of application suppliers, prevent the dependence on a particular
   one, and yield compliance and interoperability. Often, the
   server-located systems have quite long life cycles, despite the
   short development cycles of hardware and software.

   These two cycles lead to two concurrent goals. The first goal
   intends long-termed stability and security of investments. The
   second requires the accurate consideration of new developments.

   The IOTP Application Core represents the generic part of an IOTP
   aware trading environment that provides IOTP specific document
   formatting and security mechanisms. It connects to the
   transaction specific backend systems.







Werner, et al                                                  [Page 11]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


2.1.1.5

   The processing of the actual transaction data is performed by the
   Existing Legacy Systems resp. Existing Payment Software being
   reused for IOTP based (Internet) trading. They may even apply
   their own document formatting and security mechanisms on the
   application data being transparently embedded in IOTP messages.



2.1.1.6 Data Layer

   The Existing Legacy Systems provide their specific data
   management systems for data storage, security, or backup.
   However, the internal structure of the Application and Data Layer
   is out of the scope of this document.



2.1.2 Implementation Variants

   The implementation variant defines the concrete realization of
   these layers. Although this proposal focuses on the WWW
   environment, any concrete realization is omitted.



2.1.3 Component Distribution

   Component distribution means that the architecture needs to be
   mapped onto different infrastructures and that different
   realizations become necessary. While this mapping is quite
   trivial on current consumers' personal computers, it is more
   complicated on the server's side. Complexity may even increase on
   the consumer's side with the upcoming of intelligent payment
   periphery, e.g., intelligent chip card reader. E.g., the
   architecture may be implemented at the Payment Handler on a
   single main server or may be distributed between multiple server
   stations.

   The architecture should be considered from two different points
   of view, i.e., from the server's and from the consumer's point of
   view.



2.2 Requirements and Commitments





Werner, et al                                                  [Page 12]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


2.2.1 Basic Requirements

   In addition to the aforementioned IOTP objectives, the user's
   prospective must be considered.



2.2.1.1 Electronic Commerce Provider (Server)

   o  The Trading Architecture must be scaleable.

   o  The implementation must support the 24h/7d service. The online
   dialog system should be always available. Precautions are
   necessary that support changes, e.g., maintenance, during the
   operating hours.


   o  The architecture must provide functions that can be used by
   most of the providers. Therefore, the architecture clearly
   describes its core components and the interface to the provider
   specific services.

      -  The architecture addresses all layers inclusive the
      refinement layer. The application and data layer may be
      realized by the providers. Payment Handlers and big merchants
      may implement these capabilities on behalf of their existing
      installations.

      -  For example, the interface to the Existing Payment Software
      located at the application layer bases on the XML format.



2.2.2  Security Requirements and Commitments

   Security Requirements have strong influences on the design of the
   architecture. I.e., several concrete security mechanisms for the
   transmission and requirements for the operating environments at
   the consumer's and provider's side reflect distinct security
   levels. Baseline IOTP provides integrity protection but future
   versions of IOTP will incorporate more sophisticated mechanisms
   for confidentiality, authenticity, and integrity.



2.2.2.1  Overview about the Security Levels

   Several security levels protect the application data.

        Security Level            Architecture  Method


Werner, et al                                                  [Page 13]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                                  Layer
   {1}  transmission              access layer  e.g. SSL
        (inclusive
         authentication
         provider -> consumer)
   {2}  authentication            end system    local pass phrase
        (consumer -> certificate, layer         verification through
         chip card)                             software or the
                                                consumer's chip card
   {3}  document                  refinement    future versions of
        (inclusive                layer         IOTP of specific
         authentication e.g.                    payment methods
         chip card <-> provider)
   {4}  authorization             application   provider's
                                  layer         application

   The security levels can be classified as follows:

   o  The Transmission Security for Transport Purposes {1} implements
   the secure transmission between two parties (HTTP server and Web
   browser) without any interpretation of the content. E.g., the
   transmission of the Java applets belongs to this class. In addition,
   products, information announcements, and trading offers that may lead
   to an IOTP transaction require transmission security.

   o  The Application Security {2-4} provides the strongest protection
   for the financial and trading transactions. The remaining security
   levels fall into this category.



2.2.3  Security Mechanism



2.2.3.1  Transmission Security

   Socket security components like SSL implement the transmission
   security. Both instances of the access layer at the consumer's and
   provider's side may exchange their data SSL secured. This implies
   that the international versions of the common Web browsers deliver
   only weak security, except the provider is a financial institute.
   This provider needs a special certificate and has to use particular
   HTTP servers. The consumer has to use the newer releases of Web
   browsers. Particular European browser add-ons close the security hole
   outside the USA and Canada and offer world wide strong security with
   full sized symmetric session keys.

   SSL supports both server and consumer authentication. From the
   worldwide prospective, US browser integrated SSL V2 offers both weak


Werner, et al                                                  [Page 14]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   confidentiality and weak integrity while SSL V3 offers weak
   confidentiality but strong integrity. However, the usual RSA key size
   is limited to 512 bits, in contrast to the normal key sizes of SET ,
   CyberCash , eCash ( all 1024), and HBCI (768).

   The server's private authentication key may be stored in a special
   hardware device.

   Server authentication offered by both versions of SSL suffices in
   most cases. It supports the secure transmission of Java applets etc.
   and the verification of its origin by the consumer. And it provides
   the base for HTTP Basic Authentication or (mutual) authentication at
   the application layer.



2.2.3.2 Authentication

   ID / pass phrase pairs or certificates can prove the claimed
   consumer's identity. When using chip cards, these cards should enable
   their transaction sensitive mechanisms only after successful local
   authentication.



2.2.3.3 Document Security

   The security services of the refinement layer process the IOTP level
   document security. This includes:

   o  document integrity
   Digital signatures or message authentication codes permit this.

   o  authentication
   Mutual authentication may happen at startup each time a new
   communication channel is established between two trading roles, i.e.,
   Consumer - Merchant / Payment Handler / Delivery Handler.

   o  confidentiality
   The data stream may be optionally encrypted in addition to the
   transmission protocol. However, Baseline IOTP provides
   confidentiality only by the use of transmission security mechanisms.

   o  validity
   Counters, nonces, or unique transaction identifiers ensure message
   freshness and prevent replay attacks.

   o  defense of attacks
   Failed signatures may be controlled and defended (brute force
   attacks).


Werner, et al                                                  [Page 15]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   A unique crypto application programming interface offers the services
   for document security processing. Beneath the software based
   implementation, this API may offer services for accessing some
   central crypto hardware, too. This hardware stores the crypto keys
   and performs the cryptographic operations. Such a device is expected
   to be implemented by a chip card at the Consumer's side and by tamper
   resistant security modules at the Payment Handler's side. The
   equipment at the Merchant and Customer Care Providers may depend on
   their expected load.

   The refinement layer may require additional data for key management
   purposes, i.e., certificates or private keys.

   The result of this security verification is reported to the
   application layer. Security warnings, e.g., replay attacks detected
   at the refinement layer, may be forwarded to other application
   modules, e.g., card or user management systems.

   However, the refinement layer does not manage any security of
   transparently embedded data like payment scheme specific data. Its
   security needs to be handled by the application layer.



2.2.3.4 Authorization

   The application layer implements the authorization procedures and
   different procedures may be offered by the providers. The following
   information influences the counterparty's verification:

   o  result of the authentication
   derived from the document integrity reported by the refinement layer.

   o  result of the document integrity
   evaluated information reported by the refinement layer.

   o  authorization
      -  user, account, or chip card status Verification of user,
      account, or chip card presence and status.

      -  competence verification counterparty's, mainly consumer's,
      authorization of the requested transaction type at the application
      layer.



2.2.4  Protection against Attacks

   In principle, multiple points of attacks exist that need accurate
   protection:


Werner, et al                                                  [Page 16]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  consumer's system,
   o  providers' systems respective their computing centers, and
   o  transmission line.

   Generally, several providers are involved during each IOTP
   transaction - even during the individual steps - while basically only
   one consumer participates (consumer to business). This scenario may
   be extended for business to business transactions in future versions
   of IOTP.



2.2.4.1  Consumer System

   The protection of the consumer's system, i.e., vulnerable personal
   computer with unsecured applications, is quite difficult. Better
   security is obtained by specialized consumer electronic components
   that integrate chip cards implementing the important security
   procedures in tamper resistant hardware. The following requirements
   need to be satisfied by a PC based system.

   o  On the Internet, the transmission security should be ensured by an
   SSL instance. Very sensible transactions should be secured by an SSL
   implementation with full cryptographic strength.

   o  Additionally, the transaction data may be symmetrically or
   asymmetrically secured by software or chip cards.

   o  Best security is obtained by the use of intelligent chip card
   readers with an integrated keyboard and display. This allows the
   secure input of pass phrases, the safe display of transaction data,
   and the signature outside the personal computer. Viruses and Trojan
   horses are not able to attack the chip card reader.

   o  The environment for the input of the transaction data needs to be
   secured. Current implementations of Web browsers for personal
   computers and workstations have many security holes, e.g., Java
   virtual machine, ActiveX.



2.2.4.2  Transmission Line

   The network providers control the security of the transmission line.
   There is no additional danger, if strong cryptographic mechanisms for
   end to end security are used. All end points are located at the
   consumer's respective provider's sphere.





Werner, et al                                                  [Page 17]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


2.2.4.3  Provider's Computing Center

   The providers' end points for the transmission and document security
   are located at their computing centers. Important secret/private keys
   may be stored in hardware. Separate hardware components should be
   used according to the different quality of both security levels.

   Additional protection against illegal access, e.g., a firewall, is
   necessary. This does not secure the application data but addresses
   system attacks from the public Internet.



3.  Layers and Functional Components

   A flexible architecture requires its partition into multiple logical
   layers. These layers incorporate the functional components. Changes
   at one layer may not necessarily imply changes at other layers. And,
   the introduction of additional implementation variants does not
   necessarily imply changes on all layers. The architecture consists of
   the following layers whereby the communication between the access and
   the refinement layer bases on IOTP:

        Notation           Duties
   1    end system layer   user interface and off-line functionality
                           of the consumer's system (personal
                           computer or other intelligent end device
   2    network layer      communication between consumer and
                           provider
   3    access layer       transport coupling and presentation
                           control
   4    refinement layer   processing of the transaction message

   5    application layer  electronic commerce functionality and
                           control
   6    data layer         data management

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   End system layer
      presentation software
      document formatting, document security, transport coupling
                                |service specific formats
   network layer                v
      network access procedure
      network participant management
      network services          ^
                                | service specific formats
   access layer                 v
      presentation services
      presentation control monitor


Werner, et al                                                  [Page 18]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


      transport coupling        ^
                                | document format IOTP
   refinement layer             v
      document security
      document formatting       ^
                                | content data format
   application layer            v
      electronic commerce application
      application monitor (authorization)
                                | provider specific format
   data layer                   v
      data access
      integrity
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
              Figure 3: Layer Components of the Architecture

   The architecture describes the layers inclusive the refinement layer
   and their interfaces to the specific implementations of the
   provider's applications.



3.1  End System Layer

   The end system layer is localized at the consumer's side. The
   architecture defines the components for electronic commerce. It
   considers the use of standard software and browser based applications
   as well as client based and server based implementation alternatives.

   An (optionally certified) IOTP aware application implements the data
   format parser and the security services. This application may bolt on
   standard software or browser based applications. The implementation
   should reflect the depicted architecture:

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   End system layer
     presentation software
       o  standard software
       o  web browser based
     document security
       o  document authenticity
       o  document encryption
       o  validity
     document formatting
       o  conversion between IOTP and application formats
       o  format syntax checks of the IOTP structure (segments,
     lengts, elements, attributes etc.)
       o  logical compression
     transport coupling
       o  network protocols


Werner, et al                                                  [Page 19]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


       o  transmission security
       o  access protection
     IOTP kernel maintenance
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
        Figure 4: Components and Functions of the End System Layer



3.1.1 Presentation Software

   The presentation software performs the actual electronic commerce
   processing at the consumer's side. It is responsible for the data
   presentation, too. This applies both to personal computers and other
   consumer electronic end devices.

   There are no requirements how to provide this functionality.
   Generally, two classes can be distinguished:

   o  program parts base on intelligent browser extensions like Java
   applets, plug-ins or helper applications.
   o  standard products for electronic commerce.



3.1.2  Document Formatting

   This component includes functions for the generation and analysis of
   IOTP messages as well as mechanisms for initialization and
   termination of IOTP transactions. They correspond to those of the
   provider's refinement layer.

   The IOTP aware application implements these functions in browser
   based applications and standard products. This application has
   further interfaces to the components presentation software, document
   security, transport coupling, and IOTP kernel maintenance. It
   controls their behavior.

   This general concept of the IOTP aware application for browser based
   electronic commerce supports its usage in PC based kiosk system in
   public self service areas, too.

   Note that IOTP defines only one instance of the very general
   refinement layer. The architecture may remain unchanged if another
   protocol or some future IOTP version replaces Baseline IOTP. However,
   the consumer's system generates complete transaction messages and
   transfers them to the provider considering all security aspects.






Werner, et al                                                  [Page 20]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


3.1.3  Document Security

   This component provides (chip card based) document security services
   that correspond to the respective services of the refinement layer.



3.1.4  Transport Coupling

   This component manages communication channels in cooperation with the
   respective components of the access layer at the counterparty. It
   supports socket security mechanisms like SSL and XML message
   processing.



3.1.5  Maintenance

   The end system layer should provide functions for maintenance of the
   IOTP aware application. This may be ordinary software maintenance as
   well as application specific extensions. Also an organizational
   concept including access protection to the application components is
   needed.



3.2  Network Layer

   The network layer of the architecture connects the consumer's system
   with the provider's system. The network provider implements this
   layer and promises its reliability. The offered services base on
   standardized communication protocols.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Network layer
     network access procedure
       o  access procedure and identification
       o  end device characteristics
     network participant management
     network services
       o  Internet
       o  other
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
          Figure 5: Components and Functions of the Network Layer

   The network provider realizes the network access procedure and
   implements the participant management with respect to the consumer's
   identification. The result of this verification may be reported to
   the access layer's component transport coupling together with the
   determined characteristics of the end device.


Werner, et al                                                  [Page 21]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   Currently, Baseline IOTP neglects this option due to the lack of any
   standardized clarification of the reportable data.



3.3  Access Layer

   The access layer defines the entry point to the provider's sphere and
   controls the presentation dialogs with the consumer's end device.
   This layer does no processing on the transaction data exchanged
   between the provider and the consumer. All documents are processed
   transparently.

   Particular applications, so-called native programs, may serve as
   consumer attractors. Consumer attractors are games, advertisements,
   information, and calculation examples and they may be offered by the
   merchant trading role.

   The presentation controls and their dialog steps are realized in so-
   called frame dialogs. The capabilities are defined by concrete
   presentation services, e.g., WWW. Herewith, frame dialogs are
   adjusted to the specific presentation service. In addition to the
   control of the presentation service, the frame dialog controls the
   document transport.

   The presentation control monitor realizes the superior control, i.e.,
   initialization and termination of the channels to the frame dialogs,
   connections to the application subsystems, their distribution,
   supervision, and statistics.

   The access layer consists of the following components and
   subcomponents:

   o  transport coupling
     -  network protocols
     -  transmission security
     -  access protection

   o  presentation control monitor
     -  frame dialogs
     -  presentation services
     -  subsystem distribution

   o  frame dialogs

   o  native programs






Werner, et al                                                  [Page 22]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


3.3.1  Transport Coupling

   The transport coupling provides an interface to the network layer and
   contains the following subcomponents:

   o  network protocols o  tcp/ip, pay tv, mobile

   o  transmission security o  socket protection component

   o  access management o  packet filter o  firewall



3.3.1.1  Network Protocols

   The transport access depends on the actual presentation services and
   their standard mechanisms. Currently, this access is determined by
   the WWW. This coupling of presentation services is called standard
   coupling. In the case of WWW, the socket standard defines the
   coupling for both transmission channels.

   Both the implementation of the access layer and the standard coupling
   should be transparent to the provider's and the consumer's sphere
   because the presentation service, being selected for a particular
   consumer connection, must implement the standard coupling internally.

   The next figure presents an example for standard coupling at the
   access layer:

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Consumer's sphere              WWW/Java resp. IOTP
                                        ^
         Access layer                   |sockets
                                        |
                                      tcp/ip
         (network protocols)            |
                                        |sockets
                                        v
   Provider's sphere              WWW/Java resp. IOTP
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                Figure 6: Access Layer's Standard Coupling

   Note that the access layer usually lacks any conversion services,
   i.e., the selected consumer connection requires the same standard
   coupling at both parties.

   Maybe, some provider operated IOTP aware application may accept
   document formats without an intermediate presentation service. But
   this is not expected for Baseline IOTP over HTTP or native TCP/IP.



Werner, et al                                                  [Page 23]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


3.3.1.2  Transmission Security

   The socket protection component implements the transmission security
   on the public network. On the Internet, SSL may implement this
   service at IOTP message level while the Existing Legacy Systems and
   Existing Payment Software may secure their specific transaction data
   on their own at the application layer in advance to its encapsulation
   in IOTP.



3.3.1.3  Access Protection

   Components are needed that limit the remote access and protect the
   provider's infrastructure against attacks from the public network.
   Firewalls and packet filters do this for TCP/IP based network
   protocols. However these component prevent illegal access to the
   providers' system but they can not protect the data that they
   transparently process.



3.3.1.4  Presentation Control Monitor

   The presentation control monitor provides basic features being
   independent from the underlying system architecture, loosely couples
   the application and the presentation systems, and supports the
   professional operation.

   The presentation control monitor contains the following
   subcomponents:

   o  frame dialogs Each frame dialog relates to and controls the
   respective presentation service. The presentation control monitor
   manages the connections (channels) to the individual frame dialogs.

   The monitor provides the following functionality:

     -  selection of the frame dialogs components and their presentation
     services
     -  initialization, termination and channel supervision for
     transport coupling
     -  requesting and forwarding of transport profiles for control
     purposes of the network layer

   o  parameterized subsystem distribution provides functionality
   complementary to the application monitor:
     -  mapping of the frame dialog's sessions to the application layer
     -  supervision and transport parameterization of the subsystems



Werner, et al                                                  [Page 24]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   Further functions are:

   o  load supervision

   o  statistic and diagnosis functions

   These functions subsume
     -  logging
     System processes must remain transparent to the support personal in
     order to provide consumer support. The monitor must be able to log
     the history of the dialog steps and the progress of IOTP message
     exchanges for each session, hereby delivering the raw data for
     subsequent analyses.  o  statistics and reporting functions Online
     statistics about the maximal and current number of connections and
     the states of the electronic commerce environment are necessary.
     They enable the detection of bottle necks and system adjustments.
     -  error processing
     The monitor must be able to report specific error messages to the
     consumer's system and to the provider's applications. These
     messages can be used by the user help desk for error localization,
     too.
     -  trace function
     The monitor's dialog control should be traceable, i.e., the monitor
     should provide a logging function for its own actions. This trace
     function should be able to trace subsets of connections.



3.3.1.5  Parameterized Subsystem Distribution

   This function complements the subsystem distribution of the
   application monitor. Based on information of the network layer, the
   presentation control monitor initiates the connection to the
   requested application monitor or application subsystem and supervises
   these connections. Both single and multiplexed connections may be
   supported.



3.3.1.6  Frame Dialogs

   The further partition of the frame dialog's functionality yields:

   o  presentation services
   They implement the actual online dialog with the consumer. Native
   presentation methods are used to implement the transaction dependent
   parts of the electronic commerce offer, e.g., determination of
   acceptable payment methods, offer generation, payment, digital data
   delivery. Native presentation methods of the Internet are HTML pages;
   scripts, applets, and pre-installed applications. The main functions


Werner, et al                                                  [Page 25]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   are:

     -  management of provider specific data, individual presentation
     possibilities
     Often, the provider requires a specific look & feel (logos,
     colors). This should be controlled by tables whereby each service
     uses its own table.

     -  dialog control
     The fundamental connection control should base on tables. They
     specify which dialogs need to be activated after a specific user
     input. The frame dialog coincides with a table automaton. These
     tables must be customizable and maintainable. The dialog controller
     must support tracing in order to prevent the presence of a removed
     objects in the table. This log documents the dialog process and can
     be used for review purposes.

   o  document transport
   IOTP realizes the document transport for electronic commerce. The
   provider's Web server or the IOTP aware application represents the
   corresponding implementation. It is based on standard TCP/IP
   protocols with the usage of an intermediate presentation protocol
   (HTTP). The socket protection component may be disabled, if the IOTP
   protocol provides its own document security - this does not apply to
   Baseline IOTP. The frame dialog uses the protocols of the
   presentation service and controls herewith this application. The
   application requests data from the presentation service or responds
   data to it until an IOTP message has been generated or processed.

   Baseline IOTP over the Internet assumes pre-installed consumer
   applications. Although the IOTP application manages the visualization
   and dialog appearance, the provider generates and formats the
   visualized transaction specific data, e.g., payment brand, logo,
   purchase amount, (organizational) descriptions. Furthermore, he has
   to trace the message exchanges in order to synchronize his own
   transaction progress with the consumer's transaction progress.



3.3.2  Presentation Services

   The presentation services base on established, standardized, and
   extensible description services. Therefore, only fundamental
   requirements are noted that need to be fulfilled by these services.

   The established implementations of presentation services of the
   Internet are Web servers.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Presentation Services


Werner, et al                                                  [Page 26]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


     o  native presentation
       -  basic presentation protocols (HTML, ...)
       -  graphical user interface (style guides)
       -  character set conversion (ASCII <-> EBCDIC)
     o  optimization
       -  compression
       -  local object cashing
       -  refresh
     o  transport information
       -  inquiry and parameterization services of the transport
          coupling (security, configuration, performance, quality)
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
      Figure 7: Components and Functions of the presentation services



3.3.2.1  Native presentation (standard)

   The standard presentation protocols apply to the presentation modus,
   i.e., HTML is used on the Internet optionally enriched with Java or
   ActiveX applets, JavaScript or VisualBasic scripts. The IOTP protocol
   contains also some data being visualized during the transaction.
   Considering Baseline IOTP, the preceding browsing and shopping steps
   base on the standard presentation protocol. Afterwards the
   transaction switches to IOTP. The implementation of the user
   interface considers the requirements of the provider.



3.3.2.2  Optimization

   The transmission of the presentation data using the Internet is
   recommended and advantageous due to performance considerations and
   costs. Nevertheless, optimization should be independent from the
   network. Example operations are logical compression, local object
   caching, and slim data transmission.

   The HTTP cache management and the packaging of several Java classes
   in one archive are two Internet specific optimizations.

   Logical compression deals with the omission of empty or superfluous
   data elements.



3.3.2.3  Transport Information

   Presentation services are network independent. But it is pithy and
   necessary to receive information from the network layer or to control
   this layer through parameters. The presentation service may provide


Werner, et al                                                  [Page 27]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   the mechanisms for accessing and forwarding such information.

   The network provider may provide the following information:

   o  network type (TCP/IP, ...)
   o  participant identification
   o  end device identification

   This information could be used for security purposes, statistics,
   configuration, performance and quality of service.



3.3.2.4  Native Programs

   Optionally, the access layer may contain application services. It may
   be more advantageous to implement simple calculations, e.g., ATM
   locators or zip code determinations, immediate in the access layer,
   without the usage of any subsystem, relieving the application
   systems.

   Particularly, scripts and applets offer new perspectives because they
   transmit program parts to the consumer's system and execute them on
   the remote system. This allows the server side supplement of raw data
   and their consumer sided refinement, i.e., processing and
   visualization. This relieves the central systems because the
   consumers' systems perform the main part of the computation. More
   complex applications are possible with remote data base access (JDBC,
   RMI). The potential increases further if complete applications are
   distributed on CDROMs etc. instead of dynamic transmissions of
   network accurate (down-)scaled scripts and applets.



3.4  Refinement Layer

   Ideally, the refinement layer separates the application layer from
   the actual access layer. Mainly, it establishes a stable interface.
   The refinement layer communicates with IOTP formatted messages
   towards the access layer and with application specific formatted
   messages towards the application layer, e.g., providers' existing
   legacy systems. It converts the messages between the respective
   formats.

   The IOTP aware application, i.e., IOTP Application Core, belongs to
   this layer.

   The refinement layer supplies services that can be accessed by the
   application layer:



Werner, et al                                                  [Page 28]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  format conversion: task of the IOTP services
   o  security (document): task of the security and stock data
      services
   o  format optimization: task of the security services

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Refinement layer
     o  document security
       -  document authenticity (authentication, signing, etc.)
       -  stock data management (RSA key management, wrong
          signatures)
     o  document formatting
       -  conversion between IOTP and application format
       -  formal syntax checks
       -  character set conversion (ASCII <-> EBCDIC)
       -  logical compression and decompression
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
           Figure 8: Refinement Layer's Components and Functions



3.4.1  Format Conversion

   The format conversion guarantees the access layer's independence from
   the application and provider specific data formats and yields the
   portability of the presentation control monitor between different
   installations. This is of particular importance for bank or near-bank
   Payment Handlers with their broad range of proprietary existing
   installations.

   The IOTP service performs the following tasks

   o  formal syntax check and semantic analysis of the IOTP message
      (correct protocol building blocks, elements, lengths,
      attributes, matches of descriptive header attributes and
      elements, and dangling cross references)

   o  verification of the document security referencing the security
      services

   o  generation and supervision of IOTP dialog sequences

   >From the provider's prospective it should be considered that the
   received messages may be generated both by the consumers' home
   electronic commerce applications and public self service terminals.

   Furthermore, the format conversion handles character set conversions.
   This conversion depends on the installation platforms.




Werner, et al                                                  [Page 29]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


3.4.2  Document Security

   The secure (confidential, authentic, integer) data exchange between
   the consumer and the provider is one important requirement for
   electronic commerce. The consumer leaves the sphere of the provider
   (merchant, financial institute etc.), in contrast to the traditional
   face-to-face business. Instead, the data is generated in the
   consumers' private environment, by trusted servers, or at public
   terminals and transmitted over the public network. Therefore, the
   document security seems to be worthwhile despite Baseline IOTP's
   focus on message integrity.

   The verification of the document authenticity requires either a stock
   data management for the key and signature management without any
   contribution of the data layer. Alternatively, a certification
   hierarchy may be established. Stock data may be Certificate
   Authority, provider (, and consumer) certificates as well as
   otherwise encoded cryptographic keys. It may include further
   information about the consumer. This data is intended only for key
   management. Any authorization of a transaction is deferred to the
   application layer.

   The refinement layer should support the anonymous access - at least
   for registration purposes - if the provider offers the actual service
   to registered consumers, only.



3.4.3  Format Optimization

   The security services optimize the data format by compression and
   decompression operations.



4.  Recapitulation

   The following discussion focuses on the Consumer and Payment Handler
   and simplifies the provider's IOTP Middleware / Existing Legacy
   System to the IOTP Payment Bridge / Existing Payment Software.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   End System Layer

   Network Layer

   Access Layer
     o  Transport Coupling
       -  access protection: packet filter, firewall
       -  transmission security: SSL, TLS


Werner, et al                                                  [Page 30]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


       -  network protocol: TCP/IP, HTTP, XML
     o  Presentation Service
       -  graphical user interface
       -  HTML
       -  character set conversion

   Refinement Layer                                         IOTP
     o  Document Formatting                              APPLICATION
       -  IOTP level semantical analysis                    CORE
       -  transaction reference analysis
       -  cross reference management
       -  character set conversion
     o  Document security
       -  Hash
       -  canonical form transformation
       -  signature capabilities
     o  Cache Management
       -  idempotency checks
       -  logging capabilities
     o  Transaction Database
       -  storage of IOTP messages, blocks, and elements indexed by
          transids or blockids
       -  transaction status memory
     o  Dispatcher
       -  routing
       -  session management
     o  Transaction Type Processors
       -  IOTP transaction types
       -  user inquiries
       -  policy, configuration data base

   Application Layer                                            IOTP
     o  Device Driver                                   MIDDLEWARE /
       -  chip card, PIN PAD                         PAYMENT BRIDGE
       -  tamper resistent security module      -------------------
     o  Payment Protocol Driver             EXISTING LEGACY SYSTEM /
       -  Secure Electronic Transaction   EXISTING PAYMENT SOFTWARE
       -  Secure Channel Credit and Debit
       -  ...

   Data Layer
     o  Transaction Database
       -  storage of transaction data
       -  transaction status memory
       -  stock data
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                   Figure 9: Architecture Recapitulation

   Figure 14 entails a more compact view of the Trading Architecture.
   Implementations may consider additional middleware or the more


Werner, et al                                                  [Page 31]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   detailed view on the IOTP / Payment Bridge being omitted from the
   following description. This figure names the important functional
   modules of an IOTP application and maps them to the identified
   architecture layers. Example modules are:

   o  TCP/IP stacks,
   o  SSL security packages,
   o  HTTP wrapper,
   o  XML parser / validator and generator,
   o  IOTP semantic analyzer,
   o  security modules for document security,
   o  cache manager,
   o  internal database system,
   o  format converter,
   o  display and dialog management,
   o  session management: Transaction, Message, Element Identifier
      Management,
   o  dispatcher,
   o  transaction specific processing modules,
   o  . . .

   IOTP defines the interface between the access and the refinement
   layer. The HTTP and the XML processors, which parse and validate IOTP
   messages, are assigned to the access layer.

   The transaction database is the central component of the IOTP
   application. It stores the transaction data (IOTP messages,
   components, and blocks) and realizes the persistent memory of the
   internal transaction state automaton. The specific transaction type
   processors interrogate the database for internal state update /
   verification and transaction data. Nevertheless, the IOTP Payment
   Bridge and Existing Payment Software may use their own databases or
   they may refer to this database through call back functions.

   The figure indicates further interfaces between the other layers and
   their internal modules. They have not been fixed yet due to their
   variance between the different roles, systems, vendors, ...
   Furthermore, the figure describes the transaction type processors
   very coarsely. Obviously, the Payment Handler's Payment Bridge
   cooperates with the Existing Legacy Systems. Therefore the
   transaction type processors may indirectly request further
   installation specific communication and application specific
   services, e.g., some CORBA middleware, SNA transport protocol, or
   external transaction approval.








Werner, et al                                                  [Page 32]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


4.1  Example Justification

   TCP/Internet Protocol (TCP/IP):
     TCP/IP is the basic network protocol used for information exchange
     on the Internet with increasing success even in business
     environments. It provides sole transport services and does not
     depend on any application data. The TCP/IP module is assigned to
     the Transport Coupling module of the access layer.

   Secure Socket Layer (SSL), Transport Layer Security (TLS):
     SSL and TLS add sole channel security services to the basically
     open unsecured TCP/IP. Consequently, they encrypt transparently
     application data before transmission and remove the security
     envelope after receipt. Although SSL and TLS build upon TCP/IP they
     offer sole access services.

   Hypertext Transfer Protocol (HTTP) Wrapper:
     >From the application's or IOTP's point of view, HTTP is a generic
     wrapper used for pre-transmission conversion, such that
     transmission could be easily realized by the reuse of current
     software components (Web browsers and HTTP servers). Furthermore,
     HTTP wrapped messages pass firewalls with the highest probability -
     HTTP provides only access services.

   Extensible Markup Language (XML):
     The actual IOTP message content is encoded in XML and the Document
     Type Declaration (DTD) defines the syntax of IOTP messages. The XML
     parser checks received XML messages on syntactical well-formedness
     and IOTP-DTD validity. Even the powerful XML parser remains an
     access utility from the application's point of view.

   The transmission of data uses specific formats and conversions of low
   level data entities. E.g., byte order of characters, character sets.
   Some of these presentations services may be optionally handled by the
   HTTP parser or the XML parser. However, the abstract view assigns
   their subservices to the presentation services.

   Graphical User Interface (GUI):
     Furthermore, these services subsume the dialog service with the
     consumer, e.g., pop-up of notification/alert windows or input forms
     and low level input processing.

   Hypertext Markup Language (HTML):
     The presentation service includes any HTML processor - the HTML
     engine of the Web browser - that visualizes any HTML encoded data.
     It includes also style sheet processors and visualization engines
     for XML. The operating system (MS Windows, ...), the window system
     (X11, ...), or the reused tools prescribe the interface. Any
     further refinement of this interface or the introduction of a
     portable intermediate layer is out of the scope of this document.


Werner, et al                                                  [Page 33]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


     All of the aforementioned capabilities belong to the access layer.
     The next items describe the refinement layer.

   Document Formatting:
     The incoming IOTP messages - nevertheless encoded in XML but now
     verified w.r.t. well-formedness and validity- reach the refinement
     layer. This layer provides modules from IOTP level document
     verification (use of unique transaction id, use of other ids, valid
     cross references, analysis of interior structures, e.g., syntax of
     net locations, descriptions, embedded data). It transforms XML
     encoded IOTP messages to an internal structured representation.
     These functions belong to the architecture component "document
     formatting" because they deal with the internal application
     specific structure of IOTP messages. Vice versa, the document
     formatter enriches the internal representation of IOTP messages and
     encodes them to IOTP specific XML before transmission.

   Document Security:
     Baseline IOTP provides some security mechanisms that build an extra
     architecture component. This increases the flexibility of the
     architecture. E.g., vendors could plug in several security modules
     without affecting the remaining application. Furthermore, Payment
     Handlers may prescribe high security requirements that affect only
     an isolated topic of the architecture and therefore an isolated
     module of the application.

   Cache Management:
     The cache manager implements a hardly application dependent
     mechanism for idempotency checks of  messages. The cache manager
     does not belong to the access layer because IOTP defines the rules
     for idempotency checking.

   Dispatcher:
     The dispatcher is the master module of the IOTP Application Core.
     It receives all events - both from the user and the remote party -
     and determines the respective slaves, i.e., transaction type
     processors. The dispatcher manages session related requests and
     responses. The dispatcher and the transaction type processors
     depend on the IOTP application.

   Transaction Database:
     The transaction database stores both the message content and the
     internal state information.

   Existing Payment Software:
     The Existing Payment Software together with the suitable IOTP
     Payment Bridge define the Application Layer. Their internal
     structure is not described. However, a more elaborated discussion
     would result in a structure comparable with the IOTP Application
     Core.


Werner, et al                                                  [Page 34]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


5.  Progress Example

   This section describes the progress of an IOTP transaction within the
   Trading Architecture step by step and uses an example consumer dialog
   for the brand independent payment with a provider combining the
   Merchant and Payment Handler trading roles. The implementation
   variant "TCP/IP - WWW, Java, SSL" with an online distributed Java
   applet is assumed that implements the IOTP aware application. Secure
   Channel Credit and Debit (SCCD) based payments may be implemented by
   Java applets. SSL implements the secure data transmission. The
   description focuses on the participation of the individual layers and
   clarifies their roles.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Client (Consumer)      IOTP request 1         Server
                     ------------------------->
                         IOTP response 2
                     <-------------------------


                          IOTP request n
                     ------------------------->
                         IOTP response n
                     <-------------------------
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

   End System Layer

      Pre IOTP progress:
      1.  The consumer dials into the Internet using his (arbitrary)
      network provider and establishes the physical Internet connection.
      2.  The consumer uses the pre-installed Web browser for the
      visualization of HTML pages that have been fetched from the
      Internet.
      The consumer interacts only with the component presentation
      software, i.e., the Web browser. The other components of the end
      system layer cooperate with the browser transparently.

   Network Layer
      3.  The network provider identifies the participants and supplies
      the service access points for WWW and Email.
      4.  The network provider may offer his own WWW content. Usually,
      the HTTP protocol is offered on port 80.

   End System Layer
      5.  The consumer connects to some merchant site, browses through
      the merchant's offer, and fills his shopping cart. The initial URL
      may be accessed by user input or links from other pages (home
      page, result page of a Web search engine. Then the consumer
      decides to check out the shopping cart and agrees to the


Werner, et al                                                  [Page 35]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


      subsequent payment.

   Access Layer
      7.  By assumption, the requested page is SSL secured, indicated by
      the protocol HTTPS in its URL. This page is used to initiate the
      secure download of the Java applet.
      8.  The socket protection entity of the transport coupling
      component responds with the encrypted session key material.

   End System Layer
      Remark:
      The browser has been configured with the public key needed for the
      authentication of the page's origin. The key may be configured by
      the consumer, manually (neither safe nor recommended). The key can
      be sent to the consumer by standard mail or it can be downloaded
      from another site. The latter requires another browser built-in
      public certification key.

      8.  The consumer's (and provider's) socket protection components
      exchange the encrypted session key material (certificates and
      encrypted pre-master keys). The browser (or SSL helper
      application) verifies the key material using the configured public
      keys, derives the actual session keys, and accepts or rejects the
      upcoming transmission of the requested page.
      9.  The consumer gets an indication - e.g. icon change - about the
      successful SSL connection. Manually, he may pop up the received
      certificate and verify the authenticity of the server.
      10.  Now the browser initiates the actual request of the page. The
      transport coupling receives the encrypted page. The browser
      decrypts this page using the session key and forwards the
      decrypted page to its visualization engine. The Java applet is
      securely downloaded and activated as part of the page processing.
      Alternatively, a local pre-installed Java applet may be referenced
      and activated. In addition, either the downloaded page contains
      the IOTP based initialization data for the Java applet or the Java
      applet requests this from a special URL.
      11.  The consumer provides some input data, e.g., for payment
      instrument selection, which is driven by the Java applet.
      12.  Finally the consumer agrees to the payment of the selected
      goods with the chosen payment instrument and clicks on the pay now
      button. At this point all user input needs to be verified, e.g.,
      supplement of all required payment data.
      13.  On successful verification, the Java applet forwards the user
      data to its IOTP dialog services.
      14.  The IOTP dialog services generate the IOTP (Payment) request
      message using the IOTP message services.
      15.  The IOTP message is forwarded to the transport coupling,
      which may establish a new SSL secured connection with the Payment
      Handler (cf. 8 & 9) and sends the message to his IOTP aware
      application, using the current network connection and the socket


Werner, et al                                                  [Page 36]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


      API. Note that the Merchant and Payment Handler collapse by
      assumption.

   Access Layer
      16.  The network layer transmits the (encrypted) data.
      17.  The frame dialog ensures the complete and consistent
      transmission between the consumer's end system and the provider's
      computing center. The message may be used to set up some control
      mechanisms.

   Refinement Layer
      18.  The refinement layer performs formal verification. It
      transforms the IOTP formatted message into the application
      specific format, verifies the document formatting, validity, and
      security, and extends the application data with the results.
      19.  The application data is forwarded to the application
      services.

   The following insertion gives an example description of the
   application and data layers. They vary between the trading roles and
   even between providers of the same type. The description does not
   belong to the architecture.

   Application Layer

   The application layer implements the functionality of the actual
   electronic commerce applications which vary between the providers. In
   addition, a parameterized application monitor may be contained in the
   application.

   The application layer contains the following components:

   o  application monitor
   o  electronic commerce application

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Application Layer
     o  application monitor
       -  security (verification, authorization)
         -  verification result of document authenticity
         -  customer authorization
         -  anonymous access
       -  subsystem distribution (parameterized)
     o  electronic commerce applications
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                 Figure 10: Application Layer's Components

   o  Application Monitor
      One component of the application monitor routes the initiated
      application connections to the application subsystems, supervises


Werner, et al                                                  [Page 37]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


      them, and deals with the application specific security and
      authorization. The presentation control monitor of the access
      layer triggers the application monitor.

   o  Subsystem Distribution
      This control function initiates and supervises the application
      connection to the application system (consumer account manager,
      order, payment, or billing system, etc.). It contains the
      following functionality:

      -  parameterized session memory
         stores the current (shopping/payment
         negotiation/payment/delivery) context, e.g., the relationship
         between goods, payments and consumers.

      -  routing of application connections and their supervision
         Partial functions may be realized by different application
         subsystems or they may run on different servers at different
         locations. The component manages the controlled initialization,
         termination, and supervision of application connections derived
         from the information of the initial IOTP request and final IOTP
         response.

      -  statistics and diagnosis
         The tasks are described in the previous section about the
         presentation control monitor. The respective components log the
         actions of the application monitor (logging of application
         progress and application errors)

   o  Application Specific Security

   This function includes the routing of successful authorized dialogs.
   Security modes are:

      -  authorized
         The application services can reference the verification result
         of the document security (signature, authentication). But they
         handle the application specific consumer authorization by
         themselves. This may involve the validity check of the
         consumer's account or of a payment chip card.
      -  without authorization
         There is no user information necessary because the service
         requires no security attribute (guest account). But the
         component may perform some checks on user supplied data, e.g.,
         syntax of email address and validity of the given domain name.

   o  Electronic Commerce Applications

   They comprise the provider specific functionality. The Existing
   Legacy System resp. Existing Payment Software and IOTP Middleware


Werner, et al                                                  [Page 38]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   resp. IOTP Payment Bridge belong to this class.

   Data Layer

   The data layer consists of the following components:

   o  data access
      Routines for database access and data manipulation.

   o  data integrity
      The data integrity contains a transaction monitor and integrity
      verifications.

   o  data administration
      The functions storage, balance, update, and distribution belong to
      the administration class.

   The above progress example is continued:

   Refinement Layer
      20.  The refinement layer reports technical errors to the
      presentation control monitor, e.g., time-outs.
      21.  The refinement layer generates an IOTP response if it has
      received the correct response from the application services. Its
      security services sign (and encrypt) the IOTP response.

   End System Layer
      22.  The applet's IOTP message services request the data
      encryption and signature verification for the response from its
      security services.
      23.  The applet's IOTP dialog services enable IOTP dialogs and
      verify any optional authentication and initialization data.
      24.  The IOTP message services generate the next request (IOTP
      Payment Exchange).

   Access Layer
      25.  The frame dialog receives the message, verifies its relation
      with the current dialog, and forwards the data.

   Refinement Layer, Application Layer, Data Layer
      26.  The process coincides with the processing of the first IOTP
      message.

   Access Layer
      27.  The IOTP aware application sends the response and closes the
      IOTP dialog on payment completion or failure. The physical
      connection remains open.

   End System Layer
      28.  The Java applet processes the transaction response.


Werner, et al                                                  [Page 39]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


      29.  It takes the control and display the final payment status.
      30.  It passes the control back to the browser, redirects it to
      the respective net location, and terminates.



6.  TCP/IP - WWW, Java Implementation Variant

   The WWW variant of the Trading Architecture has specific requirements
   for the implementation that are implied by the open structure and
   established standards and tools of the Internet. The following table
   depicts the non-trivial relationship of these structures with the
   Trading Architecture. The table describes the components, standards,
   and products of the implementation variant.


   Layer        Component        Standard    Product
   End System  Presentation      IOTP        IOTP Wallet, Payment
   Layer       Software                      Extension
                                 XML         IOTP Wallet, e.g., Web
                                             browser extension
                                             (e.g. Java applet)
                                 Java        IOTP Wallet, e.g., Web
                                             browser extension
                                             (e.g. Java applet)
               Document Format   IOTP        IOTP Wallet, Payment
                                             Extension (and
                                             smartcard)
               Document          IOTP        IOTP Wallet, security
               Security          (smartcard) services (of financial
                                             service providers)
                                             inclusive chip card
                                             support
               Transport
               Services
                  Network        TCP/IP      TCP/IP socket support
                  Protocol       Socket      for the Windows & OS/2
                                             family, Macintosh
                                             system, and UNIX
                                             derivatives, e.g.,
                                             Windows WINSOCK.DLL
                                 HTTP        Web browser, IOTP
                                             Wallet
                                 HTML, XML   Web browser, IOTP
                                             Wallet
                                 IOTP        IOTP Wallet
                 Transmission    SSL         browser implemented SSL
                 Security                    functionality, SSL
                                             client solution for
                                             world wide full


Werner, et al                                                  [Page 40]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                                             strength cryptography
   Network       Network         Internet    Internet/Online
   Layer         Services                    service provider
                 Network Access  Requirement Internet/Online
                 Procedure and   of the      service provider
                 User Management Internet
                                 Service
                                 Provider
   Access Layer  Transport
                 Services
                    Network      TCP/IP      TCP/IP support by
                    Protocol                 - packet filter
                                             - web server
                                             - ...
                    Transmission SSL         web server integrated
                    Security                 SSL functionality,
                                             specific SSL server
                                             solutions
                    Access       Firewall
                    Security
                                 Packet      router of firewall
                                 Filter
                                 (exterior)
                                 Application firewall
                                 Level
                                 Gateway
                                 Packet      router of firewall
                                 Filter
                                 (interior)
                 Presentation
                 Control Monitor             web server
                    Subsystem
                    Distribution
                    Frame        HTML, Java  web server
                    Dialog       ActiveX,
                                 JavaScript,
                                 Visual Basic
                    Presentation HTML, XML    web server
                    Native       HTML, XML    web server
                    Presentation
                    Optimization HTTP Cache   web server, http proxy
                    Transport    System       requirements for the
                    Information  Information  web server
                 Native Programs Java         self developed /
                                 JavaScript,  customized programs /
                                 ActiveX,     applets
                                 Visual Basic
   Refinement    Document Format IOTP         IOTP aware application
   Layer
                 Document        IOTP         IOTP aware application


Werner, et al                                                  [Page 41]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                 Security                     security services:
                                              - digital signature
                                              - crypto API for RSA,
                                              - (certification /
                                                 registration
                                                 authority)
       Table 1: Implementation Variant  TCP/IP - WWW, Java, Server
   Station Solution

   The IOTP implementation variant does not recommend any specific Web
   server. Its implementation requires the distinction between the
   consumer's and the merchant's / deliverer's / Payment Handler's
   sphere.



6.1  Consumer's Sphere

   The following discussion distinguishes between two different types of
   end systems.

   A standard application may implement all services on its own. Solely,
   it has to fulfill the requirements of the IOTP protocol.
   Alternatively, it may use the functionality of a so-called IOTP
   kernel, in order to relieve the actual front-end application from the
   complex process of the parsing, analysis, verification, generation,
   and protection of IOTP messages. Parameters supplied by (preceding)
   IOTP messages influence the consumer's system behavior and
   appearance.

   A Web browser extension may also require an IOTP kernel, e.g., in
   order to provide full SSL security outside of USA and Canada. The
   usage of a local IOTP kernel is recommended even if an online loaded
   component - e.g., Java applet - may encode this extension. This
   decreases the size of the application dependent Java applet.
   Parameters supplied by (preceding) IOTP messages may customize such
   an applet, too. Alternatively, a fully customized applet may be
   supplied to the consumer.

   The detailed description of the IOTP kernel is outside of this
   discussion and needs to be formalized in an subsequent document.  The
   specification of the IOTP kernel aims at the subsequent
   implementation. Such an implementation may be distributed as an IOTP
   development kit using the Internet service providers in order to
   enable the rapid development of consumer products. Furthermore, the
   IOTP kernel may incorporate a Crypto API encapsulating the security
   services.





Werner, et al                                                  [Page 42]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


6.2  Provider's sphere

   A powerful server station with a decentralized operating system like
   UNIX may implement the access layer. Such a server station may be
   located at a computing center, at the Internet services provider,
   etc. It runs the following jobs:

   -  Web server
   -  SSL server
   -  IOTP Application Core

   The general cooperation of the IOTP Application Core and the Existing
   Legacy System is outside the scope of this document. However, the
   connection to particular Existing Payment Software is discussed in
   the next chapter. The IOTP Application Core may be a slim IOTP
   monitor (IOTP application level gateway) that forwards the IOTP
   documents to the actual IOTP Application Core located anywhere else
   in the demilitarized zone or interior network.

   Additional components may protect the server station against attacks
   from the Internet. Such products as well as the respective
   (consultation) services are highly available. Therefore, this
   document does not address these traditional network security risks.

   Any gateway in the interior net may convert the traffic between
   TCP/IP and other protocols. Herewith, IOTP documents can be
   transmitted to arbitrary IOTP systems.





IOTP Payment API



7.  Payment API

   The Internet Open Trading Protocol extends pure payment schemes like
   SET, SSL based payments, or CyberCash to a trading protocol, that
   deals with purchase orders, payment receipts, and delivery responses
   but does not replace of any payment method. Instead, it provides a
   wrapper for these payment specific protocols. Consequently, the IOTP
   aware application may reuse Existing Payment Software or may minimize
   the changes to these components. Therefore, the IOTP Application Core
   implements the IOTP transaction platform, IOTP transaction data
   management system, and user interface. But it defers the actual
   payment processing to the Existing Payment Software.




Werner, et al                                                  [Page 43]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


7.1  Introduction

   The following table sketches the four logical steps of many payment
   transactions. The preceding agreement about the goods, payment method
   and purchase amount is omitted.

   Payment State  Party             Behavior
   Mutual         Payment Handler   E.g., generation of
   Authentication                   identification request, solvency
                                    request, and some nonce
                  Consumer          E.g., responses to the requests,
                                    and generation of the own nonce
   Authorization  Payment Handler   Opening of the transaction,
                                    generation of the authorization
                                    request
                  Consumer          Reservation of the Consumer's
                                    e-money
                  Payment Handler   Acceptance or rejection of the
                                    authorization response
   Capture                          generation of the capture
                                    request
                  Consumer          Charge
                  Payment Handler   Acceptance or rejection of the
                                    e-money, closing of the payment
                                    transaction
   Reversal                         On rejection: general of the
                                    reversal data
                  Consumer          Receipt of the refund

   Some payment methods do not distinguish between authorization and
   capture. The optional transaction reversal applies on payment
   rejection / revocation. This model applies also to refunds, deposits,
   withdrawals, electronic cheque, direct debit, and money transfer.

   It seems to be important for the consumers' acceptance, that the same
   IOTP wallet supports different payment methods and the registration
   of new payment methods which might be achieved by a common Payment
   API. Payment Handlers will also benefit from such a Payment API that
   standardizes the connection to their legacy systems, if they offer
   payment services for multiple payment methods.

   The Payment API provides a standard method for exchanging payment
   protocol messages between the parties involved in a payment
   (resolution). The existence of a well defined Payment API enables
   payment software developers to bolt on their components to other
   developer's general IOTP Application Core. The former have to
   implement the IOTP Payment Bridge, too.

   In outline, the Payment API accepts as an input parameter the
   transformed payment protocol message received from the remote party


Werner, et al                                                  [Page 44]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   and returns another payment protocol message to be sent back to the
   remote party. This continues between the two parties until the
   Payment Handler's Payment API signals the payment termination.

   The relationship between the API and a typical software architecture
   is illustrated in the following figure. The relationship between
   these components are arbitrary: One IOTP Application Core may manage
   multiple IOTP Payment Bridges, which may manage multiple Existing
   Payment Software components, which may manage multiple payment
   methods. Finally, each payment method may support multiple payment
   instruments. Vice versa, several IOTP Payment Bridges may share
   Existing Payment Software and even share payment methods.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   IOTP client (consumer)  <--------------->  IOTP server (merchant)
         ^                     Internet             ^
         | IOTP Payment                             | IOTP Payment
         |    API                                   |    API
         v                                          v
   IOTP/Payment Bridge                        IOTP/Payment Bridge
        ^                                           ^
        | Existing Payment APIs, e.g.,              |
        | SET, Mondex, etc.                         |
        v                                           v
   Existing Payment Software               Existing Payment Software
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                 Figure 11: Relationship of the Components

   The next section lists several assumptions about the different
   software components. The next chapter illustrates the payment
   transaction progress and message flow for different kinds of
   transaction behavior. Chapters 9 to 11 contain the detailed
   description of the API calls and Chapter 12 elaborates the call back
   interface.

   When dealing with Merchants' or Delivery Handlers' IOTP aware
   applications, the payment related components are replaced by their
   Existing Legacy Systems and the IOTP Middleware. However, the
   discussion of non-payment interfaces (order management etc.) is
   deferred to future versions of this document.



7.2  Assumptions

   Any Payment API has to suit for a broad range of payment methods both
   software based like Credit Card SET or CyberCoin and chip card based
   like Mondex or GeldKarte. Furthermore, it should suit for mimicries
   of typical and traditional payment methods like money transfer,
   direct debit, deposit, withdrawal, and money exchange, however they


Werner, et al                                                  [Page 45]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   are realized. It should support both payments with explicit consumer
   acknowledge and automatic (micro)payments, which have been consumer
   approved in advance.

   The Payment API considers the following transaction types of Baseline
   IOTP [RFC XXXX]:

   o  Baseline Purchase,
   o  Baseline Refund,
   o  Baseline Value Exchange,
   o  Baseline Withdrawal, and
   o  Baseline (Payment) Inquiry.

   First, the vision of the IOTP aware application's and its main
   components' capabilities are clarified. On the one hand, the Payment
   API should be powerful and flexible such that the IOTP Application
   Core really benefits from it. On the other hand, it should not be
   overloaded with stuff that is not supported by Existing Payment
   Software. Furthermore, the requirements of Consumers and Payment
   Handlers differ extremely on failure resolution and inquiry
   capabilities. Therefore, it is envisioned that the IOTP Application
   Core supports only basic inquiry mechanism while complex and payment
   method specific inquiries are deferred to the actual Existing Payment
   Software. Finally, the complete payment processing inclusive failure
   resolution support is deferred to the Existing Payment Software.

   The IOTP Application Core implements the generic and payment method
   independent part of the IOTP transaction processing and provides the
   suitable user interface. Focusing on the payment, it

   o  manages the registered IOTP Payment Bridges, inclusive their
   registration process,

   o  supports the Consumer's payment instrument selection preceding the
   payment request,

   o  invokes and requests additional payment specific support from the
   selected and registered Existing Payment Software through the IOTP
   Payment Bridge,

   o  initializes and terminates the Existing Payment Software through
   the IOTP Payment Bridge,

   o  requests authentication data from the Consumer,

   o  supervises the online transaction process and traces its progress,

   o  implements any payment transaction progress indicator,

   o  offers generic dialogs to the Existing Payment Software, e.g. pass


Werner, et al                                                  [Page 46]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   phrase input, basic transaction inquiry, balance inquiry, brand
   selection payment acknowledge, payment instrument insertion, payment
   suspension / cancellation,

   o  validates (previously) received payment receipts and the status of
   (terminated) payment transactions,

   o  stores the transaction data and offers basic data base facilities
   and basic inquiry mechanisms for payment transactions,

   o  supports the invocation of the existing software modules in an
   interactive mode for further payment method specific transaction
   post-processing, and

   o  exports call back functions for use by the IOTP Payment Bridge or
   Existing Payment Software for progress indication or database access.

   In addition, the IOTP Application Core

   o  enables the inquiry of pending and completed payment transactions,

   o  manages the IOTP components and IOTP blocks exchanged during the
   transaction which may be referenced and accessed for the processing
   of subsequent messages, e.g., for signature verification. In
   particular, it stores named Packaged Content elements exchanged
   during payments.

   o  associates each IOTP transaction type with payment transaction(s)
   and each payment transaction with multiple payment parameters (IOTP
   Transaction Identifier, Trading Protocol Options, Payment Instrument,
   Offer Response, IOTP Payment Bridge, and Wallet Identifier). The
   latter association can be lowered to the Consumer Payment Identifier,
   IOTP Payment Bridge, and Wallet Identifier when the payment
   transaction has been successfully started.

   o  manages several kinds of identifiers, i.e., transaction, message,
   component, and block identifiers,

   o  provides a message caching mechanism,

   o  neglects failures at lower protocol layers except time-outs
   because they are handled by the appropriate protocol mechanisms,
   e.g., TCP/IP handles transmission errors.

   o  detects time-outs at the protocol and API level reflecting the
   communication with both the remote party and the local periphery,
   e.g., chip card (reader) may raise time-outs.

   o  defers payment specific error resolution to the Existing Payment
   Software. Mostly, they are solved from the IOTP Application Core's


Werner, et al                                                  [Page 47]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   prospective by the extended exchange of Payment Exchange messages.
   The most significant failures arise from sudden unavailability or
   lapses of the local or opposing payment component.

   o  assumes that the IOTP Payment Bridge is a passive component of the
   payment system, i.e., it awaits any input data and generates one
   response to each request. In particular, it does neither recognize
   nor notify time-outs, necessarily.

   However, the IOTP Payment Bridge and Existing Payment Software do not
   have to rely on the IOTP Application Core's capabilities. E.g., they
   may implement several dialogs on their own or they may refuse the
   export of specific payment instruments at brand selection time and
   may defer this selection to the Check Payment Possibility step using
   their own user interface.

   The IOTP Payment Bridge's capabilities deal not only with actual
   payments from the Consumer to the Payment Handler but extend to the
   following:

   o  translation of messages between the formats of the IOTP
   Application Core and the Existing Payment Software. If one IOTP
   payment API call splits into multiple Existing Payment Software
   calls, it has to assemble their output to one IOTP payment API
   response.

   o  Consumer's payment instrument selection by the means of an
   unsecured export of the relationship of payment brands, payment
   protocols, and payment instruments (identifiers). Generally, this
   includes not just the brand (Mondex, GeldKarte, etc.) but also which
   specific instance of the instrument and currency to use (e.g. which
   specific Mondex card and which currency of all those available).
   However, some payment methods may defer the selection of the payment
   instrument to the actual payment carrying-out or they may even lack
   any management of payment instruments. E.g., chip card based payment
   methods may offer - Point of Sale like - implicit selection of the
   payment instrument through simple insertion of the respective chip
   card into the chip card reader or they interrogate the inserted card
   and request an acknowledge (or selection) of the detected payment
   instrument(s).

   o  payment progress checks, e.g., is there enough funds available to
   carry out the purchase,

   o  balance inquiry, e.g. consumers may interrogate their chip card
   based payment instrument or remotely administered account in advance
   of a payment transaction acknowledge,

   o  IOTP Payment Receipt - more precisely its Packaged Content  -
   checks. Furthermore, it may support payment method specific Payment


Werner, et al                                                  [Page 48]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   Receipt checks that are typically exchanged in IOTP Payment Scheme
   Components rather than in IOTP Payment Response Blocks or generated
   by chip cards.

   o  decoding of data contained within a brand or protocol specific
   IOTP Payment Receipt or actual payment method specific Payment
   Receipt into a format which can be displayed to the user or printed,

   o  cancellation of payment, even though it is not complete,

   o  suspension and resumption of payment transactions. One source of
   failure the Existing Payment Software has to deal with is the time-
   out of the network connection. For resolution, the IOTP Application
   Core may try the suspension with a view to later possible resumption.
   Alternatively, the IOTP Application Core may signal the transaction's
   cancellation. However, the existing software can not rely on correct
   suspensions / cancellations, e.g., when it shuts down, it has to
   consider any exceptions and to resolve inconsistencies.

     Another source of failure is lack of funds in which case the IOTP
   Application Core may signal the suspension of the current payment
   transaction. The consumer may download money and may resume the
   previous transaction.

   o  payment transaction status inquiry, so that the inquirer can
   determine the appropriate next step.

   o  inquiry on payment transactions. Particularly, the inquiry of
   transactions with specific transaction states should be supported.
   The IOTP Application Core may inquire and resolve pending
   transactions at startup. E.g., the computer system may crash due to
   power failure.

     The determination details of the inquired transaction data is up to
   the IOTP Payment Bridge. It may evaluate local databases, log files,
   chip cards, or remote account manager.

   o  recording the payment progress and status on a database. E.g.,
   information about pending payments can be used to assist their
   continuation when the next payment protocol message is received.

   o  payment progress indication. This could be used to inform the end
   user of details on what is happening with the payment.

   o  payment method specific authentication methods.

   Existing Payment Software may not provide full support of these
   capabilities. E.g., some payment protocols may not support or even
   prevent the explicit transaction cancellation at arbitrary phases of
   the payment process. Therefore, the IOTP Payment Bridge has to


Werner, et al                                                  [Page 49]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   implement at least skeletons that signal any lack of support back to
   the caller by the use of error codes (see below).  The Existing
   Payment Software's capabilities vary extremely. It

   o  supports the actual online payment transaction,

   o  resolves most types of payment specific failures,

   o  provides hints for out-of-band failure resolution on failed
   immediate resolution,

   o  may implement transaction data management and inquiry mechanisms
   ranging from no transaction recording, last transaction recording,
   chip card deferred transaction recording, simple transaction history
   to very sophisticated implementations with flexible user inquiry
   capabilities. The latter is required by Payment Handlers for easy and
   cost effective failure resolution.

   o  may rely on the generic dialogs of the IOTP Application Core.
   However, particular (business) rules or payment aspects may require
   additional dialog boxes or their dedicated appearance / structure /
   content, may prohibit the unsecured export of payment instruments, or
   may prescribe the pass phrase input under its own control.

   The API must consider both successful and failed payments. On time-
   out failure, each party requires a reliable analysis of the current
   payment transaction status and hints about the possible resolution
   alternatives. Common payment revocation by (e)mail, fax, or voice
   telephone becomes useless if the content of any chip card needs to be
   modified.



8.  Message Flows

   The Payment API calls are distinguished between general and payment
   transaction related inquiry calls, brand selection and payment
   transaction related calls, payment instrument customer care related
   and other calls.


   o Brand Compilation Related API Calls

   "Find Accepted Payment Brand" identifies the accepted payment brands
   for the indicated currency amount.

   "Find Accepted Payment Protocol" identifies the accepted payment
   protocols and returns payment scheme specific packaged content for
   brand selection purposes.



Werner, et al                                                  [Page 50]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   "Get Payment Initialization Data" returns additional payment scheme
   specific packaged content for payment processing by the payment
   handler.

   "Inquire Authentication Challenge" returns the payment scheme
   specific authentication challenge value.

   "Authenticate" forwards any payment scheme specific authentication
   data to the IOTP Payment Bridge for processing.

   "Check Authentication Response" verifies the returned payment scheme
   specific authentication response value.

   "Cancel Payment" terminates the payment transaction immediately. This
   API function is a short cut to some specific "Change Process State"
   call.


   o Brand Selection Related API Calls

   "Find Payment Instrument" identifies which instances of a payment
   instrument of a particular payment brand are available for use in a
   payment.

   "Find Payment Protocol" identifies which payment protocols are
   supported by a specific payment instrument, resp. payment brand.

   "Check Payment Possibility" checks whether a payment instrument is
   able to perform a payment.

   "Quit Payment Instrument" terminates a payment transaction, even
   before the transaction has been initiated towards the Payment Handler
   (short cut for "Change Process State").

   "Authenticate" (cf. Brand Compilation Related API Calls)


   o Payment Transaction Related API Calls

   "Start or Resume Payment Consumer/Payment Handler" initiate or resume
   a payment transaction. There exist specific API calls for the two
   trading roles Consumer and Payment Handler.

   "Continue Process" forwards payment scheme data to the Existing
   Payment Software and returns more payment scheme data for
   transmission to the counterparty.

   "Change Process State" changes the current status of payment
   transactions. Typically, this call is used for successful/less
   termination of suspension.


Werner, et al                                                  [Page 51]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   oGeneral Inquiry API Calls

   "Inquire Payment Log" interrogates the payment log for different
   kinds of payments. The interrogation is adjustable by multiple
   parameters.

   "Remove Payment Log" removes one specific entry from the Payment Log.

   "Payment Instrument Inquiry" retrieves the properties of Payment
   Instruments.

   "Inquire Pending Payment" reports whether the IOTP Payment Bridge has
   pending transactions.


   o Payment Transaction Related Inquiry API Calls

   "Check Payment Receipt" checks the validity of IOTP Payment Receipts,
   returned by an "Inquire Process State" API call. It is used to check
   that the payment receipt is consistent and/or matches the respective
   payment transaction. Typically, it is used by the Consumer during the
   final processing of payment transactions. However, this check might
   be advantageous both for Consumers and Payment Handlers on failure
   resolution.

   "Expand Payment Receipt" expands IOTP Payment Receipt Packaged
   Contents and payment specific payment receipts into a form which can
   be used for display or printing purposes.

   "Inquire Process State" responds with the payment status and the IOTP
   Payment Receipt Component. Normally, it is called by the Payment
   Handler for final processing of the payment transaction.

   "Start Payment Inquiry" prepares the remote inquiry of the payment
   transaction status and responds with payment scheme specific data
   that might be needed by the Payment Handler for the Consumer
   initiated inquiry processing.

   "Inquire Payment Status" is called on Consumer initiated inquiry
   requests by the Payment Handler. It provides the payment scheme
   specific content of the Inquiry Response Block.

   "Continue Process" and Change Process State" (cf. Payment Transaction
   Related API Calls)


   o Other API Calls

   "Manage Payment Software" enables the immediate activation of the
   Existing Payment Software. Further user input is under control of the


Werner, et al                                                  [Page 52]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   Existing Payment Software.

   "Access Data Base" provide a general data base interface to the IOTP
   Payment Bridge. They can rely on the IOTP Application Core
   capabilities for reliable data management.

   "Call Back" Function provides a general interface for visualization
   of transaction progress by the IOTP Application Core.

   The following table shows which API functions must (+), should (#),
   or might (?) be implemented by which Trading Roles.

   API function                  Consumer  Payment Handler  Merchant
   Find Accepted Payment Brand                                 +
   Find Accepted Payment Protocol                              +
   Find Payment Instrument          +
   Find Payment Protocol            +
   Get Payment Initialization Data                             +
   Cancel Payment                                              #
   Check Payment Possibility        +
   Quit Payment Instrument          #
   Start Payment Consumer           +
   Start Payment Payment Handler                  +
   Continue Process                 +             +
   Inquire Process State            +             +
   Change Process State             +             +            ?
   Check Payment Receipt            +             ?
   Inquire Authentication Challenge                            #
   Remove Payment Log               #             #            #
   Authenticate                     +
   Check Authentication Response                               #
   Resume Payment Consumer          +
   Resume Payment Payment Handler                 +
   Expand Payment Receipt           #             ?
   Inquire Payment Log              #             #
   Payment Instrument Inquiry       ?
   Inquire Pending Payment          #             #
   Start Payment Inquiry            ?
   Inquire Payment Status                         ?
   Manage Payment Software          #             o            ?
   Access Database                  #             #            #
         Table 2: Mapping between API Functions and Trading Roles

   The next sections sketch the relationships and the dependencies of
   the API calls. They provide the informal description of the progress
   alternatives and describe the communication and synchronization
   between the general IOTP Application Core and the payment scheme
   specific modules.




Werner, et al                                                  [Page 53]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


8.1  Authentication Documentation Exchange

   This section describes how the functions in this document are used
   together to process authentication.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Authenticator   Inquire Authentication Challenge(Alg1*)   -> IPB
                   Inq. Auth. Challenge Response(Alg1,Ch1)   <- IPB
                   . . .
                   Inquire Authentication Challenge(Algn*)   -> IPB
                   Inq. Auth. Challenge Response(Algn,Chn)   <- IPB
                   Create and transmit Authentication Request Block
   Authenticatee   Authenticate(Alg1, Ch1)                   -> IPB
                   AuthenticateResponse(...)                 <- IPB
                   . . .
                   Authenticate(Algm, Chm)                   -> IPB
                   AuthenticateResponse(Res)                 <- IPB
                   Create and transmit Authentication Response Block
   Authenticator   Check Authentication Response(Algm,Chm,Res)->IPB
                   Check Auth. Resp. Response()               <-IPB
                   Create and transmit Authentication Status Block
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                  Figure 12 Authentication Message Flows

   1.  (Authenticator Process) The IOTP Payment Bridge (IPB) is asked
   for one or multiple authentication challenge values ("Inquire
   Authentication Challenge"). Each value is encapsulated in an
   Authentication Request Component which forms the final Authentication
   Request Block. If the authenticator intends to submit a choice of
   authentication algorithms to the authenticatee, it has to issue
   several API call to the IOTP Payment Bridge.

     Note that the interface is limited to the response of one algorithm
   per call. If the IOTP Application Core provides a choice algorithm,
   this choice should be reduced successively by the returned algorithm.
   The IOTP Payment Bridge notifies the IOTP Application Core with each
   newly registered Payment Instrument about the supported
   authentication algorithms by their names.

   2.  The Authenticatee's IOTP Application Core checks whether the IOTP
   transaction type actually supports the authentication process. If
   Authentication Request Components have been provided, they are
   checked in some order. The IOTP Application Core analyzes the
   algorithms' names, the transaction context, and optionally user
   preferences in order to determine the system components which are
   capable to process the authentication request items. Such system
   components might be the IOTP Application itself or some of the
   registered IOTP Payment Bridges. These system components might be
   requested for the responses to the supplied challenges, sequentially.
   The search stops with the first successful response.


Werner, et al                                                  [Page 54]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


     Alternatively, the IOTP Application might ask for a user selection.
   This might be appropriate, if two or more authentication algorithms
   are received that require explicit user interaction, like PIN or chip
   card insertion.

     The Authenticatee's organizational data is requested by
   Authentication Request Blocks without any content element. On
   failure, the authentication request may be retried, or the whole
   transaction might be suspended or cancelled.

   3.  (Authenticator Process) The IOTP Application Core checks the
   presence of the Authentication Response Component in the
   Authentication Response Block and forwards its content to the
   "selected" IOTP Payment Bridge for verification ("Check
   Authentication Response"). Otherwise, the presence of the
   Authenticatee's organisational data is checked. Any verification must
   succeed in order to continue the transaction.



8.2  Brand Compilation

   An example of how the functions in this document are used together so
   that the Merchant can compile the Brand List Component, generate the
   Payment Component, and adjust the Order Component with payment scheme
   specific packaged content.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Merchant      For each registered IOTP Payment Bridge
                 |  Find Accepted Payment Brand()             -> IPB
                 |  Find Accepted Payment Brand Response (B*) <- IPB
                 |  Find Accepted Payment Protocol(B1)        -> IPB
                 |  Find Accepted Payment Protocol Res.(P1*)  <- IPB
                 |  . . .
                 |  Find Accepted Payment Protocol(Bn)        -> IPB
                 |  Find Accepted Payment Protocol Res.(Pn*)  <- IPB
                 Create one Brand List Component, ideally sharing
                   common Brand, Protocol Amount, Currency Amount,
                   and Pay Protocol Elements
                 Create Trading Protocol Options Block
                 On brand independent transactions
                 |  Create Brand Selection Component, implicitly
                 |  Get Payment Initialization Data()        -> IPB
                 |  Get Payment Initialization Data Res.()   <- IPB
                 |  Optionally
                 |  |  Inquire Process State()               -> IPB
                 |  |  Inquire Process State Response(State) <- IPB
                 |  Create Offer Response Block
                 Transmit newly created Block(s)
   Consumer      Consumer selects Brand/Currency from those


Werner, et al                                                  [Page 55]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                   that will work and generates Brand Selection
                   Component - at least implicitly
                 On brand dependent transaction
                 |  Transmit Brand Selection Component
   Merchant      On brand dependent transaction
                 |  Get Payment Initialization Data()        -> IPB
                 |  Get Payment Initialization Data Res.()   <- IPB
                 |  Optionally
                 |  |  Inquire Process State()               -> IPB
                 |  |  Inquire Process State Response(State) <- IPB
                 |  Create Offer Response Block
                 |  Transmit newly created Block
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                 Figure 13 Brand Compilation Message Flows

   1.  The Merchant's commerce server controls the shopping dialog with
   its own mechanisms until the Consumer checks out the shopping cart
   and indicates the payment intention. The notion shopping subsumes any
   non-IOTP based visit of the Merchant Trading Role's (which subsumes
   Financial Institutes) web site in order to negotiate the content of
   the IOTP Order Component. The subsequent processing switches to the
   IOTP based form by the activation of the Merchant's IOTP aware
   application.

   2.  The IOTP Application Core inquires the IOTP level trading
   parameters (Consumer's shopping identifier, payment direction,
   initial currency amounts, discount rates, Merchant's and Delivery
   Handler's Net Locations, Non-Payment Handler's Organisational Data,
   initial order information, ....).

   3.  The registered IOTP Payment Bridges are inquired by the IOTP
   Application Core about the accepted payment brands ("Find Accepted
   Payment Brand"). Their responses provide most of the attribute values
   for the compilation of the Brand List Component's Brand Elements. The
   IOTP Application Core might optionally match the returned payment
   brands with Merchant's general preferences.

     The IOTP Application Core must provide any wallet identifiers, if
   they are required by the IOTP Payment Bridges which signal their need
   by specific error codes (see below). Any signaled error that could
   not immediately solved by the IOTP Application Core should be logged
   - this applies also to the subsequent API calls of this section. In
   this case, the IOTP Application Core creates an IOTP Error Block
   (hard error), transmits it to the Consumer, and terminates the
   current transaction.

   4.  The IOTP Application Core interrogates the IOTP Payment Bridges
   for each accepted payment brand about the supported payment protocols
   ("Find Accepted Payment Protocol"). These responses provide the
   remaining attribute values of the Brand Elements as well as all


Werner, et al                                                  [Page 56]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   attribute values for the compilation of the Brand List Component's
   Protocol Amount and Pay Protocol Elements. Furthermore, the
   organisational data about the Payment Handler is returned. The IOTP
   Application Core might optionally match the returned payment brands
   with Merchant's general preferences.

     Note that this complex process might be optimized by any pre-
   compilation of Brand Lists. At startup the IOTP Application Core
   might

      o  perform multiple dummy inquiries on the registered IOTP
         Payment Bridges,

      o  exclude some IOTP Payment Bridges from subsequent inquiries,

      o  analyze the relationships between the items, and

      o  create patterns of the Brand Lists.

     For this purpose it is assumed that the items either vary on each
   inquiry or are static.

   5.  The steps 3 and 4 are repeated during IOTP Value Exchange
   transactions - these steps are omitted in the previous figure.

   6.  The IOTP Application Core compiles the Brand List Component(s)
   and the IOTP Trading Protocol Options Block. It is recommended that
   "equal" items returned by IOTP Payment Bridge function calls are
   shared due to the extensive linking capabilities within the Brand
   List Component. However, the compilation must consider several
   aspects in order to prevent conflicts - sharing detection might be
   textual matching:

      o  Packaged Content Elements contained in the Brand List Component
      (and subsequently generated Payment and Order Components) might be
      payment scheme specific and might depend on each other.

      o  Transaction/Brand/Protocol/Currency Amount (in)dependent data
      might share the same Packaged Content.

      o  The Consumer's IOTP Application Core transparently passes the
      packaged contents to the IOTP Payment Bridges which might not be
      able to handle payment scheme data of other payment schemes
      accurately.

     The details about the rules and mechanisms, how this could be
   accomplished is out of the scope of this document. With other words,
   this document does not define further restrictions to the IOTP
   specification.



Werner, et al                                                  [Page 57]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   7.  The IOTP Application Core determines whether the IOTP message can
   be enriched with an Offer Response Block. This is valid under the
   following conditions:

      o  All payment alternatives share the attribute values and
      contents of the subsequently generated Payment and Order
      Component.

      o  The subsequently generated data does not depend on any
      BrandSelXInfo Elements that might be reported by the consumer
      within the TPO Selection Block in the brand dependent variant.

     If both conditions are fulfilled, the IOTP Application Core might
   request the remaining payment scheme specific payment initialization
   data from the IOTP Payment Bridge ("Get Payment Initialization Data")
   and compile the Offer Response Block. Optionally, the IOTP
   Application Core might request the current process state of the IOTP
   Payment Bridge and use the returned status to infer the order status
   which is added to the Offer Response Block. Alternatively, IOTP
   Application should determine the order status on its own.

     As in step 6, the details about the rules and mechanisms, how this
   could be accomplished is out of the scope of this document.

   8.  The IOTP Application Core compiles the IOTP TPO message adding
   all compiled blocks and transmits the message to the Consumer. The
   IOTP Application Core terminates if an Offer Response Block has been
   created.

   9.  The Consumer performs the Brand Selection Steps (see below) and
   responds with a TPO Selection Block if no Offer Response Block has
   been received. Otherwise, the following step is skipped.

   10.  On brand dependent transactions, the IOTP Application Core
   requests the remaining payment scheme specific payment initialization
   data from the IOTP Payment Bridge ("Get Payment Initialization
   Data"), compiles the Offer Response Block, transmits it to the
   Consumer, and terminates. Like Step 7, the IOTP Application Core
   might access the current process state of the IOTP Payment Bridge for
   the compilation of the order status.

   Any error during this process raises an IOTP Error Block.



8.3  Brand Selection

   This section describes the steps that happen mainly after the
   Merchant's Brand Compilation (in a brand independent transaction).
   However, these steps might partially interlace the previous process


Werner, et al                                                  [Page 58]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   (in a brand dependent transaction). An example of how the functions
   in this document are used together so that the Consumer can determine
   which Brand/Currency to use is illustrated in the figure below.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Merchant      Merchant generates Brand List(s) containing
                   Brands, Payment Protocols and Currency Amounts
                 On brand independent transactions
                 |  Merchant generates Offer Response Block
   Consumer      For each accepted Payment Brand
                 |  Find Payment Instrument(B,C)              -> IPB
                 |  Find Payment Instrument Response (PI*)    <- IPB
                 For each returned Payment Instrument/Brand
                 |  Find Payment Protocol(B,PI,C)             -> IPB
                 |  Find Payment Protocol Response(P*)        <- IPB
                 Consumer selects Brand/Currency/Payment Instrument
                   from those that will work and generates Brand
                   Selection Component
                 For the Selection
                 |  Get Payment Initialization Data(B,C,PI,P) -> IPB
                 |  Get Payment Initialization Data Response()<- IPB
                 On brand dependent transaction
                 |  Generate and transmit TPO Selection Block
   Merchant      On brand dependent transaction
                 |  Merchant checks Brand Selection and generates
                 |  and transmits Offer Response Block
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                  Figure 14 Brand Selection Message Flows

   Note that the figure and the following description show one of two
   variants of the inquiry of valid payment instruments. Alternatively,
   the IOTP Application Core might enrich the "Find Payment Instrument"
   input parameter list with the payment protocols that are accepted by
   the Merchant. In this case all calls to "Find Payment Protocol"
   become superfluous and might be skipped. However, the IOTP
   Application Core must call "Find Payment Instrument" for every valid
   combination of payment brands, payment protocols, and IOTP Payment
   Bridges.

   1.  The Merchant's commerce server controls the shopping dialog with
   its own mechanisms until the Consumer checks out the shopping cart
   and indicates the payment intention. The subsequent processing
   switches to the IOTP based form by the activation of the Merchant's
   IOTP aware application.

   2.  The IOTP Application Core compiles the Trading Protocol Options
   Block which contains the Brand List Component(s) enumerating
   Merchant's accepted payment brands and payment protocols and
   initiates the Brand Selection process.



Werner, et al                                                  [Page 59]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   3.  This first IOTP message activates the Consumer's IOTP aware
   application, e.g., the Web browser invokes a helper application
   (e.g., Java applet or external application). The Consumer's IOTP
   Application Core

   o  infers the accepted payment brands, payment protocols, payment
   direction, currencies, payment amounts, any descriptions etc., and
   their relationships from the IOTP message,

      o  determines the registered IOTP Payment Bridges,
      o  inquires general payment brand support and the known payment
      instruments from each registered IOTP Payment Bridge for each
      accepted payment brand and currency ("Find Payment Instrument").
      However, some IOTP Payment Bridges may refuse payment instrument
      distinction.
      o  inquires payment protocol support from each registered IOTP
      Payment Bridge that has acknowledged any of the accepted payment
      brands ("Find Payment Protocol"). The payment protocol support may
      differ between payment instruments if the IOTP Payment Bridge
      supports payment instrument distinction.

     The IOTP Application Core must provide wallet identifiers, if they
   are required by the IOTP Payment Bridges which signal their need by
   specific error codes (see below). These API calls are used to infer
   the payment alternatives at the startup of any payment transaction
   (without user unfriendly explicit user interaction).

     It is recommended that the IOTP Application Core manages wallet
   identifiers. But for security reasons, it should manage pass phrases
   in plain text only in runtime memory. Developers of IOTP Payment
   Bridges and payment software modules should provide a thin and fast
   implementation - without lengthy initialization processes- for this
   initial inquiry step.

   4.  The IOTP Application Core

      o  intersects the Consumer's payment capabilities with the
      Merchant's accepted payment brands and currencies,
      o  displays the valid payment instruments and payment instrument
      independent payment brands (brand and protocol) together with
      their purchase parameters (payment direction, currency, amount),
      and
      o  requests the Consumer's choice or derives it automatically from
      the configured preferences.

     The management / resolution of unavailable IOTP Payment Bridges
   during the previous inquiry process is up to the IOTP Application
   Core. It may skip these IOTP Payment Bridges or may allow user
   supported resolution. It may also offer the registration of new
   payment instruments.


Werner, et al                                                  [Page 60]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   5.  The Consumer's payment instrument / brand selection ties one IOTP
   Payment Bridge with the subsequent payment transaction. The IOTP
   Application Core interrogates this IOTP Payment Bridge, whether the
   payment can proceed with success ("Check Payment Possibility"). At
   this step, the IOTP Payment Bridge may issue several signals, e.g.,

      o  payment can proceed immediately,
      o  required peripheral inclusive some required physical payment
      instrument (chip card) is unavailable,
      o  remote party is not available,
      o  wallet identifier or pass phrase is required,
      o  expired payment instrument (or certificate), insufficient
      funds, and
      o  physical payment instrument unreadable.

     In any case except the first one, the user should be notified and
   offered accurate alternatives. Most probably, the user might be
   requested

      o  to resolve the problem, e.g. insertion of another payment
      instrument, verification of periphery,
      o  to skip this check and to proceed (assuming its success),
      o  to cancel the whole transaction, or
      o  to suspend the transaction, e.g., initiating a nested
      transaction.

     If the payment software implements payment instrument selection on
   its own, it may request the Consumer's choice at this step.

     If the check succeeds, it returns several Brand Selection Info
   Elements.

   6.  The steps 2 to 5 are repeated and possibly interlaced for the
   selection of the second payment instrument during IOTP Value Exchange
   transactions - this is neglected in the figure above.

   7.  The IOTP Brand Selection Component is generated and enriched with
   the Brand Selection Info elements. This component is transmitted to
   the Merchant inside a TPO Selection Block if the received IOTP
   message lacks the Offer Response Block. The Merchant will then
   respond with an Offer Response Block (following the aforementioned
   compilation rules).



8.4  Successful Payment

   An example of how the functions in this document are used together to
   effect a successful payment is illustrated in the figure below.
   Technically, two payments happen during IOTP Value Exchange


Werner, et al                                                  [Page 61]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   transactions.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Consumer        Start Payment Consumer(Amount,[PS0]...)    -> IPB
                   Start Payment Cons. Res.([PS1], CS=Cont.)  <- IPB
                   Create and transmit Payment Request Block
   Payment Handler Start Payment Pay. Handler(Amount, [PS1])  -> IPB
                   Start Payment PH Response(PS2, CS=Cont.)   <- IPB
                   Create and transmit Payment Exchange Block
   Consumer        Continue Process(PS2)                      -> IPB
                   Continue Process Response(PS3, CS=Cont.)   <- IPB
            ... CONTINUE SWAPPING PAYMENT EXCHANGES UNTIL ...
   Payment Handler Continue Process Response([PSn], CS=End)   <- IPB
                   Inquire Process State()                    -> IPB
                   Inquire Proc. State Resp.(State, Receipt)  <- IPB
                   Create and transmit Payment Response Block
                   Terminate transaction, actively
                   |  Change Process State(State)             -> IPB
                   |  Change PS Response(State=CompletedOK)   <- IPB
   Consumer        On receipt of final payment scheme data
                   |  Continue Process(PSn)                   -> IPB
                   |  Continue Process Response(CS=End)       <- IPB
                   Check Payment Receipt(Receipt)             -> IPB
                   Check Payment Receipt Response()           <- IPB
                   Change Process State(State)                -> IPB
                   Change PS Response(State=CompletedOk)      <- IPB
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                  Figure 15 Example Payment Message Flows

   1.  After Brand Selection and receipt of the IOTP Offer Response
   Block, the Consumer has to agree to the payment transaction's
   continuation. The agreement may be explicit per transaction or may
   base on configured preferences or pre-authorizations for specific
   payment limits. The Consumer may also decide to suspend or cancel the
   continuation of the IOTP transaction. However, this suspension has to
   be managed by the IOTP Application Core on its own because no payment
   transaction has been actually opened. No IOTP messages are sent to
   the counterparty if the payment stops.

     It is assumed, that generally the following payment process
   continues with minimal user (Consumer and Payment Handler)
   interaction and that it is controlled by the IOTP Application Core
   and IOTP Payment Bridge.

   2.  In order to open the actual payment transaction, the IOTP
   Application Core issues the "Start Payment Consumer" request towards
   the IOTP Payment Bridge. This request carries the whole
   initialization data of the payment transaction being referred to by
   the IOTP Payment Bridge for subsequent consistency
     checks:


Werner, et al                                                  [Page 62]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


      o  payment brand and its description from the selected Brand
      Element of the Brand List Component,
      o  payment instrument from preceding inquiry step,
      o  further payment parameters (currency, amount, direction,
      expiration) from the selected Currency Amount element, Brand List
      Component, and Payment Component of the IOTP Offer Response Block,
      o  payment protocol from the selected Pay Protocol Element,
      o  order details contained in the Order Component which might be
      payment scheme specific,
      o  payment scheme specific data inclusive payment protocol
      descriptions from the Protocol Amount Element, and Pay Protocol
      Element, and
      o  payment scheme specific data inclusive payment protocol
      descriptions, in which the name attribute includes the prefix as
      "Payment:" from the Trading Role Data Component.

     Generally, this request repeats most checks of the "Check Payment
   Possibility" request due to lack of dependencies between both
   requests, e.g. availability check of periphery, pass phrase
   supplement. There might be a significant delay between both API
   requests. The function may return further payment scheme specific
   data being considered as payment specific initialization data for the
   Payment Handler's IOTP Payment Bridge. If the payment software
   implements payment instrument selection on its own, it may request
   the Consumer's choice at this step.

     The IOTP Payment Bridge reports lack of capability quite similar to
   the "Check Payment Possibility" request to the IOTP Application Core.
   The Consumer may decide to resolve the problem, to suspend, or to
   cancel the transaction, but he must not skip this API request. The
   IOTP Application Core might reissue the API request on user
   indication.

     Developers of payment modules may decide to omit payment instrument
   related checks like expiration date or refunds sufficiency, if they
   are part of the specific payment protocol.

     If the IOTP Payment Bridge requests wallet identifiers or pass
   phrases anywhere during the payment process, they should be requested
   by this API call, too. The IOTP Application Core should store these
   values. The IOTP Payment Bridge may also store these values and
   dispense with their supplement on subsequent payment related API
   calls. The IOTP Application Core may issue the following API calls
   without these values, but it has to supply them on IOTP Payment
   Bridge request and to reissue the API call. It is recommended that
   the IOTP Application Core stores plain text pass phrases only in
   runtime memory and that IOTP Payment Bridges renew their requests for
   pass phrases after "Change Process State" API calls.

     The IOTP Application Core generates the IOTP Payment Request Block,


Werner, et al                                                  [Page 63]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   inserts any returned payment scheme data, and submits it to the
   Payment Handler's system.

   3.  The Payment Handler's IOTP Application Core opens the payment
   transaction using the "Start Payment Payment Handler" API call. The
   payment brand, its description, payment protocol, payment specific
   data, payment direction, currency and payment amount are determined
   quite similar to the Consumer's IOTP Application Core. Furthermore,
   the content of the Payment Scheme Data component and the Brand
   Selection Info Elements are passed to the API function.

     On success, the Payment Handler's IOTP Payment Bridge responds with
   payment scheme data. On failures, it has to resolve any problems on
   its own or to give up aborting the payment transaction because the
   Payment Handler operates a non- interactive server application.
   However, the Consumer may restart the whole payment transaction. But
   the payment log file should reflect any trials of a payments.

     In any case, the Payment Handler informs the Consumer about the
   current Process State using the IOTP Payment Response or IOTP Error
   Block.

     The "Start Payment Payment Handler" call might return the
   Continuation Status "End" which leads to the continuation with Step
   7.

   4.  The IOTP Application Core verifies the presence of the Payment
   Exchange Block in the IOTP message and passes the contained payment
   scheme specific data to the active IOTP Payment Bridge ("Continue
   Process") which returns the next Payment Scheme Component.

     The Payment Scheme Component is encapsulated in a Payment Exchange
   Block and transmitted to the Payment Handler.

   5.  The Payment Handler's IOTP Application Core verifies the presence
   of the Payment Exchange Block and passes the contained payment scheme
   specific data to the active IOTP Payment Bridge ("Continue Process")
   which returns the next Payment Scheme Component for encapsulation and
   transmission to the Consumer.

   6.  The payment process continues with IOTP Payment Exchange Block
   exchanges, carrying the specific payment scheme data. Each party
   submits the embedded payment scheme data transparently to the active
   IOTP Payment Bridge by the Continue Process API call, wraps the
   returned payment scheme data into an IOTP Payment Exchange Block, and
   transmits it to the counterparty.

     However, the processing of the payment scheme data may fail for
   several reasons signaled by specific error codes which are
   transformed to IOTP Payment Response Blocks (generated by Payment


Werner, et al                                                  [Page 64]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   Handler) or IOTP Error Blocks (both parties may generate them) and
   transmitted to the counterparty.

   7.  Eventually, the Payment Handler's IOTP Payment Bridge recognizes
   the termination of the payment transaction and reports this by the
   continuation status "End". Then the IOTP Application Core issues the
   "Inquire Process State" API call and verifies whether an IOTP Payment
   Receipt Component has been returned. The IOTP Application Core wraps
   the payment receipt, the status response, and the optional payment
   scheme data in an IOTP Payment Response Block and transmits this
   block to the Consumer.

     However, these API calls may fail or any API response might be
   incomplete (lack of payment receipt). Then the Consumer has to be
   notified about the failed processing by an IOTP Error Block.

     Finally, the Payment Handler terminates the payment transaction
   with the "Change Process State" API call without awaiting any
   response from the Consumer. Further failures are not reported to the
   Consumer.

     It might be possible that the Consumer's IOTP Payment Bridge has
   returned the previous payment scheme data with the continuation
   status "End". In this case, the Payment Handler must not supply any
   further payment scheme data, because it will be rejected by the
   Consumer's IOTP Payment Bridge. Note that the genuine continuation
   status is not exchanged between the Consumer and the Payment Handler.

   8.  The Consumer passes the optional payment scheme data and the
   payment receipt to the appropriate IOTP Payment Bridge by "Continue
   Process" and "Check Payment Receipt" API calls. Finally, the
   transaction is terminated with the "Change Process State" API call
   which verifies the reported payment status with the local one and
   signals any inconsistencies. Inconsistencies and the status text
   should be displayed to the Consumer.

     At this point, payment transactions have been closed by the Payment
   Handler. Therefore, failures have to be resolved locally or outside
   the payment transaction.



8.5  Payment Inquiry

   In Baseline IOTP, Payment inquiries are initiated by the Consumer in
   order to verify the current payment progress and process state at the
   remote Payment Handler. The next figure shows the message flow of a
   Consumer initiated payment inquiry.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*


Werner, et al                                                  [Page 65]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   Consumer        Start Payment Inquiry()                    -> IPB
                   Start Payment Inquiry Response([PS1])      <- IPB
                   Create and transmit Inquiry Request Trading Block
   Payment Handler Inquire Payment Status([PS1])              -> IPB
                   Inquire Payment Status Res.(State, [PS2])  -> IPB
                   Create and transmit Inquiry Response Trading
                     Block
   Consumer        If Payment Scheme Data present
                   |  Continue Process(PS2)                   -> IPB
                   |  Continue Process Response(CS=End)       <- IPB
                   Change Process State(State)                -> IPB
                   Change Process State Response(State')      <- IPB
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                  Figure 16 Remote Process State Inquiry

   1.  The Consumer might initiate a payment inquiry once the payment
   transaction has been opened by the IOTP Application Core, i.e., any
   time after the initial submission of the IOTP Payment Request Block.
   The IOTP Application Core requests any additional specific payment
   scheme data from the respective IOTP Payment Bridge using the "Start
   Payment Inquiry" API request. Erroneous API responses should be
   reported to the Consumer and valid alternatives (typically retry and
   cancellation) should be presented by the IOTP Application Core.

     Generally, this request performs the complete initialization, e.g.
   availability check of periphery or pass phrase supplement. The IOTP
   Payment Bridge reports lack of capability quite similar to the "Check
   Payment Possibility" request to the IOTP Application Core.

     If the IOTP Payment Bridge requests wallet identifiers or pass
   phrases anywhere during the inquiry process, they should be requested
   by this API call, too. The IOTP Application Core should store these
   values. The IOTP Payment Bridge may also store these values and
   dispense with their supplement on subsequent inquiry related API
   calls. The IOTP Application Core may issue the following API calls
   without these values, but it has to supply them on IOTP Payment
   Bridge request and to reissue the API call. For security reasons, the
   IOTP Application Core should store plain text pass phrases only in
   runtime memory and the IOTP Payment Bridges should renew their
   requests for pass phrases after any "Change Process State" API call.

     The IOTP Application Core encapsulates any Payment Scheme Component
   in an IOTP Inquiry Request Block and submits it to the Payment
   Handler.

   2.  The Payment Handler analyses the Inquire Request Block, maps the
   Transaction Identifier to payment related attributes (Brand, Consumer
   and Payment Handler Payment Identifiers), and forwards the request to
   the appropriate IOTP Payment Bridge ("Inquire Payment Status"). The
   IOTP Application Core transforms the response to an Inquiry Response


Werner, et al                                                  [Page 66]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   Block and transmits it to the Consumer.

   3.  On receipt of the respective IOTP Inquiry Response Block the
   Consumer's IOTP Application Core submits any encapsulated payment
   scheme specific data to the IOTP Payment Bridge for verification
   ("Continue Process").

   4.  The IOTP Application Core passes the reported payment status
   (except textual descriptions) to the IOTP Payment Bridge ("Change
   Process State") for verification purposes and payment status change.
   The IOTP Payment Bridge reports any inconsistencies as well as the
   final payment status to the IOTP Application Core. Any additional
   information that may be of interest for the Consumer has to be
   displayed by the IOTP Payment Bridge or Existing Payment Software on
   their own.



8.6  Abnormal Transaction Processing



8.6.1  Failures and Cancellations

   The IOTP specification distinguishes between several classes of
   failures:

   o  Business and technical errors
   o  Error depth on transport, message and block level
   o  Transient errors, warnings, and hard errors.

   Any (Payment) API has to deal with the receipt of failure
   notifications from and failure responses to the IOTP Application
   Core. The interface between the IOTP Application Core and the IOTP
   Payment Bridge is mostly inherited from the genuine protocol. I.e.,
   business errors are reported by status components in normal response
   blocks while technical errors are signaled by error components in
   dedicated error blocks.

   Cancellations are specific business errors might be initiated by each
   trading party.

   In preference to slim interfaces, the payment API introduces one
   additional error flag for business error indication - errors can be
   returned by every API function. On receipt of this flag, the IOTP
   Application Core has to infer the details of the business error using
   the API function "Inquire Process State".

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Any Party       Issue some API request                     -> IPB


Werner, et al                                                  [Page 67]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                   Error Response(Error Code)                 <- IPB
                   On "Business Error" response
                   |  Inquire Process State()                 -> IPB
                   |  Inquire P.S. Resp.(State, Receipt)      <- IPB
                   Determine Local Behavior
                   If Status Change needed
                   |  Change Process State (State)            -> IPB
                   |  Change Process State Response(State')   <- IPB
                   If Counterparty notification required
                   |  Create Error or Cancel Block (, add to next
                      message, ) and transmit it to counterparty
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                     Figure 17 Error Response from IPB

   The specific Completion Codes "ConsCancelled", "MerchCancelled", and
   "PaymCancelled" - returned by "Inquire Process State" - determine
   that the Cancel Block has to be created instead of an Error Block.
   The rules for the determination of the behavior of the IOTP
   Application Core, particularly the response to the counterparty is
   given in the IOTP specification.

   Vice versa, failures, cancellations, and even success's are always
   reported to the IOTP Payment Bridge by the API function "Change
   Process State". This API function is used both for status change and
   consistency checking. Any suspicion of inconsistency should be
   reported by the IOTP Payment Bridge for display by the IOTP
   Application Core.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Any Party       Error Block or Cancel Block Received
                   If Status Change required
                   |  Change Process State (State)            -> IPB
                   |  Change Process State Response(State')   <- IPB
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                    Figure 18 Error Notification to IPB

   The processing of payment transactions might temporarily be hampered
   by intermediate failures without significant influence to the IOTP
   layer. Internal failures might be resolved within the genuine payment
   scheme. However, final failures or cancellations have to be reported
   at the IOTP layer.

   Finally, communication time-out and heavily faulty communication
   channels may disable the transaction. Any components may implement
   time-out recognition and use the aforementioned API mechanisms for
   the notification of any status change. However, time-outs do not only
   appear on communication with the remote party. Even local components,
   like chip card readers or IOTP Payment Bridges, may raise time-outs
   that need to be resolved. The Consumer's IOTP Application Core should
   notify the Consumer about the resolution alternatives, i.e., retry,


Werner, et al                                                  [Page 68]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   suspension, and cancellation.



8.6.2  Resumption

   Payment transaction resumption may apply at different steps of a
   payment transaction:

   o  Due to different time-out values the payment transaction may not
   have been suspended by the counterparty. Therefore, the API callee
   has to deal with pending and suspended payment transactions.

   o  IOTP Payment Exchange and IOTP Payment Request Blocks may be
   received by the Payment Handler on resumption. Additionally, the
   payment transaction may not have been created at the Payment Handler.
   In that case, the "Resume Payment Payment Handler" API function
   responds with a hard error indicating the required "Start Payment
   Payment Handler" API call.

   o  The IOTP Application Core may defer any payment tracing
   responsibilities to the IOTP Payment Bridge and may not be able to
   distinguish between the continuation and resumption of payment
   transactions. Either, the IOTP Payment Bridge API functions "Start
   Payment Payment Handler" and "Continue Process" implement both cases
   or they signal the required explicit payment resumption by error code
   responses ("Business Error"). Further analysis of the current payment
   state ("Inquire Process State") should return the value Suspended.

   If the Consumer does not reconnect within an acceptable amount of
   time, the Payment Handler's system may perform local failure
   resolution in order to close the transaction and to retain resources
   for other transactions ("Change Process State"). If the Consumer
   reconnect afterwards, a Payment Response or Error Block could be
   generated.

   It is expected, that Payment Handlers implement the main control of
   the payment transaction. Therefore, the Payment Handler's
   responsibility for driving the payment transaction to a consistent
   status is very high.



8.7  IOTP Wallet Initialization

   At startup or on explicit user request the IOTP Application Core
   should check its IOTP Payment Bridges' internal status by searching
   for pending payment transactions.

   1.  The IOTP Application Core interrogates the registered IOTP


Werner, et al                                                  [Page 69]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   Payment Bridges about pending payment transactions. The IOTP
   Application Core may store indicators for pending transactions and
   use them for driving any subsequent inquiry ("Inquire Pending
   Payment").

   2.  If one IOTP Payment Bridge reports the presence of pending
   transactions, the IOTP Application Core has to inquire more
   information about each pending transaction ("Inquire Payment Log").
   This inquiry API call may be pass phrase protected which has to be
   requested from the Consumer.

   3.  The IOTP Application Core may try to suspend ("Change Process
   State") or resume ("Resume Payment Consumer") the pending transaction
   (on user request). The IOTP Payment Bridge may deny any processing of
   new payment transactions until the pending transactions have been
   processed. These denials are signaled by the error code "Business
   Error".



8.8  Payment Software Management

   The IOTP Application Core provides only a simple and generic
   interface for the registration of new payment methods / instruments
   ("Manage Payment Software"). It receives the initial user request and
   defers the actual registration to the corresponding IOTP Payment
   Bridge. Other IOTP Application Core specific registration procedures
   deal with the registration of new IOTP Payment Bridges and payment
   brands.  The registration of a new payment instrument may even be
   useful in the initial step of a payment transaction, when the
   Merchant transmits new brand identifiers to the Consumer. The IOTP
   Application Core has to renew any inquiry of payment instruments - at
   least partially, if registration happens afterwards.  The IOTP
   Application Core may also activate the Existing Payment Software for
   further payment instrument and wallet administration.



9.  Mutuality

   The input and output arguments are annotated using the Extensible
   Markup Language (XML) notation. The called API function responds with
   a generic wrapper, that provides error codes and error descriptions.
   It is anticipated that this description reflects the logical
   structure of the API parameter. It may be used to derive
   implementation language specific API definitions.

   XML definition:

   <!ELEMENT IotpPaymentApiResponse (ErrorResponse?, (


Werner, et al                                                  [Page 70]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


     FindAcceptedPaymentBrandResponse |
     FindAcceptedPaymentProtocolResponse |
     GetPaymentInitializationDataResponse |
     CancelPaymentResponse |
     FindPaymentInstrumentResponse |
     FindPaymentProtocolResponse |
     CheckPaymentPossiblityResponse |
     QuitPaymentInstrumentResponse |
     StartPaymentConsumerResponse |
     StartPaymentPaymentHandlerResponse |
     ResumePaymentConsumerResponse |
     ResumePaymentPaymentHandlerResponse |
     ContinueProcessResponse |
     InquireProcessStateResponse |
     ChangeProcessStateResponse |
     PassErrorCodeResponse |
     InquireAuthChallengeResponse |
     AuthenticateResponse |
     CheckAuthResponsenResponse |
     CheckPaymentReceiptResponse |
     ExpandPaymentReceiptResponse |
     InquirePaymentLogResponse |
     RemovePaymentLogResponse |
     PaymentInstrumentInquiryResponse |
     InquirePendingPaymentResponse |
     ManagePaymentSoftwareResponse |
     StartPaymentInquiryResponse |
     InquirePaymentStatusResponse |
     CallBackResponse |
     AccessDatabaseResponse )?)>
   <!ATTLIST IotpPaymentApiResponse
     xml:lang  NMTOKEN  #REQUIRED
     ContentSoftwareID  CDATA  #IMPLIED >

   <!ELEMENT ErrorResponse (PaySchemePackagedContent*) >
   <!ATTLIST ErrorResponse
     xml:lang  NMTOKEN  #IMPLIED
     ErrorCode  NMTOKEN  #REQUIRED
     ErrorDesc  CDATA  #REQUIRED
     Severity  (Warning |
      TransientError |
      HardError)  #REQUIRED
     MinRetrySecs  CDATA  #IMPLIED
     Names  NMTOKENS  #IMPLIED >

   Most of the attribute items are intended for immediate insertion in
   the IOTP Error Block. The values of the Name attribute have to
   transformed into Error Location Elements of the Error Component (cf.
   IOTP Specification).



Werner, et al                                                  [Page 71]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   Attributes:

   xml:lang           Defines the language used by the Error
                      Description attribute (cf. IOTP
                      Specification).

   ContentSoftwareId  This contains information which identifies the
                      software which generated the IOTP Message. Its
                      purpose is to help resolve interoperability
                      problems that might occur as a result of
                      incompatibilities between messages produced by
                      different software. It is a single text string
                      in the language defined by "xml:lang". It must
                      contain, as a minimum

                      o  the name of the software manufacturer,
                      o  the name of the software,
                      o  the version of the software, and
                      o  the build of the software.

   ErrorCode          Contains an error code which indicates the
                      nature of the error in the message in error.
                      Valid values for the Error Code are given in
                      the following section. This mnemonic enables
                      the automatic failure resolution of the IOTP
                      Application Core which analyzes the error code
                      value in order to determine the continuation
                      alternatives.

   ErrorDesc          An optional textual description of the current
                      error in the language identified by
                      "xml:lang". It is intended for user display
                      and provides detailed explanations about the
                      failure and its (out-of-band) resolution
                      alternatives.

   Severity           Indicates the severity of the error. Valid
                      values are:

                      o  Warning. This indicates that although there
                      is a message in error the IOTP Transaction
                      can still continue.

                      o  TransientError. This indicates that the
                      error in the message in error may be
                      recovered if the message in error  that is
                      referred to by the "Names" attribute is
                      resent.

                      o  HardError. This indicates that there is an


Werner, et al                                                  [Page 72]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                      unrecoverable error in the message in error
                      and the IOTP Transaction must stop.

   MinRetrySecs       This attribute should be present if Severity
                      is set to "TransientError". It is the minimum
                      number of whole seconds which the IOTP aware
                      application which received the message
                      reporting the error should wait before re-
                      sending the message in error identified by the
                      "Names" attribute.

                      If Severity is not set to
                      "TransientError" then the value of this
                      attribute is ignored.

   Names              This attribute indicates the name(s) of the
                      attribute or element to which the error code
                      refers.

   Content:

   PaySchemePackagedContent  cf. Table 5



9.1  Error Codes

   The following table contains the valid values for the ErrorCode
   attribute of the Error Response. The first sentence of the
   description contains the default text that can be used to describe
   the error when displayed or otherwise reported. Individual
   implementations may translate this into alternative languages at
   their discretion. However, not every error code may apply to every
   API call. An Error Code must not be more than 14 characters long. The
   Error Codes have been taken from the IOTP Specification and extended
   by some additional codes which are highlighted by a preceding
   asterisk.

   Generally, if the corrupt values have been user supplied, the IOTP
   Application Core might prompt for their correction. If the renewal
   fails or if the IOTP Application Core skips any renewals and some
   notification has to be send to the counter-party, the error code is
   encapsulated within an IOTP Error Block. However, the IOTP server
   application reports business errors by the Status Component of the
   respective Response Block.

   References which are enumerated in the Names attribute have to be
   transformed to Error Location Elements. The IOTP Application Core
   must consider the elements' origin in the received IOTP message.
   Particularly, references to packaged content elements have to be


Werner, et al                                                  [Page 73]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   transformed to references of the surrounding XML element. The same
   rule applies to any reported attribute. Then, the AttName attribute
   has to be set in the Error Location element, too.

   The following table mentions any modification from this general
   processing for particular error values. Furthermore, it contains
   hints for developers of IOTP Application Core software components
   about the processing of error codes. Conversely, developers of IOTP
   Payment Bridges get impressions about the expected behavior of the
   IOTP Application Core. The IOTP Payment API assumes that the IOTP
   Application Core implements the dialog boxes needed for error
   resolution. But it does not assume, that the IOTP Payment Bridge
   actually relies on them. Instead, the IOTP Payment Bridge may try
   resolution on its own, implement specific dialog boxes, and signal
   only final failures.

   Note: This abstract document assumes that the API parameters are
   exchanged in XML encoding. Therefore, several error values might
   disappear in lower level language specific derivations.

   Error Value        Error Description

   Reserved           Reserved. This error is reserved by the
                      vendor/developer of the software. Contact
                      the vendor/developer of the software for
                      more information (see the SoftwareId
                      attribute of the Message Id element in the
                      Transaction Reference Block [RFC XXXX]).

                      The Names attribute might refer some
                      attributes or elements of the input
                      parameter list.

   XmlNotWellFrmd     XML not well formed. The XML document is not
                      well formed. See [XML] for the meaning of
                      "well formed".

                      The Names attribute might refer to some
                      attributes and elements of the input
                      parameter list.

   XmlNotValid        XML not valid. The XML document is well
                      formed but the document is not valid. See
                      [XML] for the meaning of "valid".
                      Specifically:

                      o  the XML document does not comply with the
                      constraints defined in the IOTP document
                      type declaration, and
                      o  the XML document does not comply with the


Werner, et al                                                  [Page 74]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                      constraints defined in the document type
                      declaration of any additional [XML
                      Namespace] that are declared.

                      The Names attribute might refer some
                      attributes and elements of the input
                      parameter list.

   (*)ElNotValid      Element not valid. Invalid element in terms
                      of prescribed syntactical characteristics.
                      The Names attribute refers to the
                      corresponding element tags.

                      The IOTP Application Core has to replace the
                      error code with "XmlNotValid" before
                      transmission to the counterparty.

   ElUnexpected       Unexpected element. Although the XML
                      document is well formed and valid, an
                      element is present that is not expected in
                      the particular context according to the
                      rules and constraints contained in this
                      specification.

                      The Names attribute refers to the
                      corresponding element tags. The IOTP
                      Application Core has to replace the error
                      code with "EncapProtErr" or
                      "ElContIllegal" before transmission to the
                      counterparty, if the Names attribute refers
                      to inner elements without a Block or
                      Component Identifier.

   ElNotSupp          Element not supported. Although the document
                      is well formed and valid, an element is
                      present that

                      o  is consistent with the rules and
                      constraints contained in this
                      specification, but
                      o  is not supported by the IOTP Aware
                      Application which is processing the IOTP
                      Message.

                      The Names attribute refers to the
                      corresponding element tags. The IOTP
                      Application Core has to replace the error
                      code with "EncapProtErr" or
                      "ElContIllegal" before transmission to the
                      counterparty, if the Names attribute refers


Werner, et al                                                  [Page 75]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                      to inner elements without a Block or
                      Component Identifier.

   ElMissing          Element missing. Although the document is
                      well formed and valid, an element is missing
                      that should have been present if the rules
                      and constraints contained in this
                      specification are followed.

                      The Names attribute refers to the
                      corresponding element tags. The IOTP
                      Application Core has to replace the error
                      code with "EncapProtErr" or
                      "ElContIllegal" before transmission to the
                      counterparty, if the Names attribute refers
                      to inner elements without a Block or
                      Component Identifier.

   ElContIllegal      Element content illegal. Although the
                      document is well formed and valid, the
                      element contains values which do not conform
                      the rules and constraints contained in this
                      specification. The Names attribute refers to
                      the corresponding element tags.

                      The IOTP Application Core has to replace the
                      error code with "EncapProtErr" or
                      "ElContIllegal" before transmission to the
                      counterparty, if the Names attribute refers
                      to inner elements without a Block or
                      Component Identifier.

   EncapProtErr       Encapsulated protocol error. Although the
                      document is well formed and valid, the
                      Packaged Content of an element contains data
                      from an encapsulated protocol which contains
                      errors.

                      The Names attribute refers to the
                      corresponding element tags.

   AttUnexpected      Unexpected attribute. Although the XML
                      document is well formed and valid, the
                      presence of the attribute is not expected in
                      the particular context according to the
                      rules and constraints contained in this
                      specification.

                      The Names attribute refers to the
                      corresponding attribute tags.


Werner, et al                                                  [Page 76]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   (*)AttNotValid     Attribute not valid. Invalid attribute value
                      in terms of prescribed syntactical
                      characteristics. The Names attribute refers
                      to the corresponding attribute tags.

                      The IOTP Application Core has to replace the
                      error code with "XmlNotValid" before
                      transmission to the counterparty.

   AttNotSupp         Attribute not supported. Although the XML
                      document is well formed and valid, and the
                      presence of the attribute in an element is
                      consistent with the rules and constraints
                      contained in this specification, it is not
                      supported by the IOTP Aware Application
                      which is processing the IOTP Message.

                      The Names attribute refers to the
                      corresponding attribute tags.

                      Furthermore, the inquiry API function
                      ("Inquire Payment Log") might report lack of
                      selection criteria. If a selector has been
                      user supplied, the IOTP Application Core may
                      offer a dialog for its adjustment. However,
                      errors generated in this case, are never
                      passed to the counterparty's IOTP
                      Application Core.

   AttMissing         Attribute missing. Although the document is
                      well formed and valid, an attribute is
                      missing that should have been present if the
                      rules and constraints contained in this
                      specification are followed. The Names
                      attribute refers to the corresponding
                      attribute tags.

                      If the attribute is required by the IOTP
                      Document Type Declaration (#REQUIRED) the
                      hints for non valid attributes should be
                      adopted, otherwise these for illegal
                      attribute values.

   AttValIllegal      Attribute value illegal. The attribute
                      contains a value which does not conform to
                      the rules and constraints contained in this
                      specification.

                      The Names attribute refers to the
                      corresponding attribute tags - valid values


Werner, et al                                                  [Page 77]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                      are:

                      BrandId: illegal/unknown Brand Identifier -
                      If the brand is not recognized/known by any
                      IOTP Payment Bridge, the IOTP Application
                      Core may offer the registration of a new
                      Payment Instrument.

                      PaymentInstrumentId:   illegal/unknown
                      Payment Instrument Identifier - This
                      indicates a serious communication problem if
                      the attribute value has been reported by the
                      same "wallet" on a previous inquiry
                      requests. The IOTP Application Core has to
                      replace the error code with
                      "TransportError" before transmission to the
                      counterparty.

                      WalletId: illegal/unknown Wallet Identifier
                      - It is assumed that the wallet identifier
                      is checked before the pass phrase. On
                      invalid wallet identifiers, the IOTP
                      Application Core may open the dialog in
                      order to request the correct wallet
                      identifier. In addition, any pass phrase may
                      be supplied by the user. The dialog should
                      indicate the respective payment brand(s).
                      The IOTP Application Core has to replace the
                      error code with "TransportError" before
                      transmission to the counterparty.

                      Passphrase:   illegal/unknown Pass Phrase -
                      The IOTP Application Core may open the
                      dialog in order to request the correct pass
                      phrase. If the pass phrase is wallet
                      identifier specific the dialog should
                      display the wallet identifier. The IOTP
                      Application Core has to replace the error
                      code with "TransportError" before
                      transmission to the counterparty.

                      Action:  illegal / unknown / unsupported
                      Action

                      PropertyTypeList:  lists contains illegal /
                      unknown / unsupported Property Types - The
                      IOTP Application Core tries only the local
                      resolution but does never transmit any IOTP
                      Error Block to the counterparty.



Werner, et al                                                  [Page 78]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                      CurrCode: illegal/unknown/unsupported
                      Currency Code

                      CurrCodeType: illegal/unknown/unsupported
                      Currency Code Type

                      Amount: illegal/unknown/unsupported Payment
                      Amount

                      PayDirection: illegal/unknown/unsupported
                      Payment Direction

                      ProtocolId:   illegal/unknown/unsupported
                      Protocol Identifier

                      OkFrom: illegal/unknown/unsupported OkFrom
                      Timestamp

                      OkTo:   illegal/unknown/unsupported OkTo
                      Timestamp

                      ConsumerPayId: illegal/unknown Consumer
                      Payment Identifier

                      PaymentHandlerPayId: illegal/unknown Payment
                      Handler Payment Identifier

   AttValNotRecog     Attribute Value Not Recognized. The
                      attribute contains a value which the IOTP
                      Aware Application generating the message
                      reporting the error could not recognize.

                      The Names attribute refers to the
                      corresponding attribute tags.

   MsgTooLarge        Message too large. The message is too large
                      to be processed by the IOTP Payment Bridge
                      (resp. IOTP Application Core).

   ElTooLarge         Element too large. The element is too large
                      to be processed by the IOTP Payment Bridge
                      (resp. IOTP Application Core).

                      The Names attribute refers to the
                      corresponding attribute tags.

   ValueTooSmall      Value too small or early. The value of all
                      or part of an element content or an
                      attribute, although valid, is too small.



Werner, et al                                                  [Page 79]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                      The Name attribute refers to the
                      corresponding attribute or element name.

   ValueTooLarge      Value too large or in the future. The value
                      of all or part of an element content or an
                      attribute, although valid, is too large.

                      The Name attribute refers to the
                      corresponding attribute or element name.

   ElInconsistent     Element Inconsistent. Although the document
                      is well formed and valid, according to the
                      rules and constraints contained in this
                      specification:

                      o  the content of an element is inconsistent
                      with the content of other elements or
                      their attributes, or
                      o  the value of an attribute is inconsistent
                      with the value of one or more other
                      attributes.

                      The error description may contain further
                      explanations.

                      The Names attribute refers to the
                      inconsistent attribute or element tags.

   TransportError     Transport Error. The connection to some
                      periphery or the counterparty could not be
                      established, is erroneous, or has been lost.

                      The error description may contain further
                      narrative explanations, e.g., "chip card
                      does not respond", "remote account manager
                      unreachable", "Internet connection to xyz
                      lost", "no Internet connection available",
                      "no modem connected", or "serial port to
                      modem used by another application". This
                      text should be shown to the end user. If
                      timeout has occurred at the Consumer this
                      text should be shown and the Consumer may
                      decide how to proceed - alternatives are
                      retry, payment transaction suspension, and
                      cancellation.

   MsgBeingProc       Message Being Processed. This error code is
                      only used with a Severity of Transient
                      Error. It indicates that the previous
                      message, which may be an exchange message or


Werner, et al                                                  [Page 80]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                      a request message, is being processed.

   SystemBusy         System Busy. This error code is only used
                      with a Severity of Transient Error. It
                      indicates that the IOTP Payment Bridge or
                      Existing Payment Software that received the
                      API request is currently too busy to handle
                      it.


   UnknownError       Unknown Error. Indicates that the
                      transaction cannot complete for some reason
                      that is not covered explicitly by any of the
                      other errors. The Error description
                      attribute should be used to indicate the
                      nature of the problem.

                      The Names attribute might refer to some
                      attribute or element tags.

   (*)SyntaxError     Syntax Error. An (unknown) syntax error has
                      occurred.

                      The Names attribute might refer to some
                      attribute or element tags.

                      The IOTP Application Core has to replace the
                      error code with "XmlNotValid" or
                      "UnknownError" before transmission to the
                      counterparty.

   (*)ReqRefused      Request refused. The API request is
                      (currently) refused by the IOTP Payment
                      Bridge. The error description may provide
                      further explanations, e.g., "wallet / chip
                      card reader is unavailable or locked by
                      another payment transaction", "payment
                      gateway is overloaded", "unknown chip card
                      reader", or "unrecognized chip card
                      inserted, change chip card".

                      The Consumer's IOTP Application Core may
                      visualize the error description and ask the
                      Consumer about the continuation -
                      alternatives are retry, payment transaction
                      suspension, and cancellation. Denials due to
                      invalid Process States should be signaled by
                      "BusinessError". Typically, this kind of
                      error is not passed to the counterparty's
                      IOTP Application Core. Otherwise, it maps to


Werner, et al                                                  [Page 81]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                      "TransportError" or "UnknownError".

   (*)ReqNotSupp      Request not supported. The API
                      function(ality) has not been implemented in
                      the IOTP Payment Bridge. Typically, this
                      kind of error is not passed to the
                      counterparty's IOTP Application Core.
                      Otherwise, it maps to "TransportError" or
                      "UnknownError".

   (*)BusError        Business Error. The API request has been
                      rejected because some payment transaction
                      has an illegal payment status.

                      The Names attribute may contain references
                      to payment transactions using the party's
                      Payment Identifier - it defaults to the
                      current transaction or might contain the
                      current payment transaction party's Payment
                      Identifier. Particularly, this error code is
                      used to signal any raise of payment business
                      layer failures.

                      The IOTP Application Core must inquire the
                      IOTP Payment Bridge about the actual Process
                      State which actually encodes the business
                      error ("Inquire Process State" or "Inquire
                      Payment Log"). This  error code is never
                      passed to the counterparty's IOTP
                      Application Core.

                        Table 3: Common Error Codes

   The IOTP Payment Bridge may also use the error description in order
   to notify the Consumer about further necessary steps for failure
   resolution, e.g., "sorry, your payment transaction failed.
   Unfortunately, you have been charged, please contact your issuer."



9.2  Attributes and Elements

   The following table explains the XML attributes in alphabetical order
   - any parenthesized number behind the attribute tag recommends the
   maximal length of the attribute value in characters:

   Attribute           Description

   Amount    (11)      Indicates the payment amount to be paid in
   AmountFrom(11)      whole and fractional units of the currency.


Werner, et al                                                  [Page 82]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   AmountTo  (11)      For example $245.35 would be expressed
                       "245.35". Note that values smaller than the
                       smallest denomination are allowed. For
                       example one tenth of a cent would be
                       "0.001".

   AuthenticationId    An identifier specified by the
                       authenticator which, if returned by the
                       organization that receives the
                       authentication request, will enable the
                       authenticator to identify which
                       authentication is being referred to.

   BrandId  (128)      This contains a unique identifier for the
                       brand (or promotional brand). It is used to
                       match against a list of Payment Instruments
                       which the Consumer holds to determine
                       whether or not the Consumer can pay with the
                       Brand.

                       Values of BrandId are managed under
                       procedure being described in the IOTP
                       protocol specification.

   BrandLogoNetLocn    The net location which can be used to
                       download the logo for the organization (cf.
                       IOTP Specification).

                       The content of this attribute must conform
                       to [RFC1738].

   BrandName           This contains the name of the brand, for
                       example "MasterCard Credit". This is the
                       description of the Brand which is displayed
                       to the consumer in the Consumer's language
                       defined by "xml:lang". For example it might
                       be "American Airlines Advantage Visa". Note
                       that this attribute is not used for matching
                       against the payment instruments held by the
                       Consumer.

   BrandNarrative      This optional attribute is designed to be
                       used by the Merchant to indicate some
                       special conditions or benefit which would
                       apply if the Consumer selected that brand.
                       For example "5% discount", "free shipping
                       and handling", "free breakage insurance for
                       1 year", "double air miles apply", etc.

   CallBackFunction    A function which is called whenever there is


Werner, et al                                                  [Page 83]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                       a change of Process State or payment
                       progress, e.g. for display updates. However,
                       the IOTP Payment Bridge may use its own
                       mechanisms and dialog boxes.

   CallBackLanguageLis A list of language codes which contain, in
   t                   order of preference, the languages in which
                       the text passed to the Call Back function
                       will be encoded.

   CompletionCode (14) Indicates the nature of the payment failure.
                       It is required if ProcessState is set to
                       "Failed" otherwise it is ignored. Valid
                       values as well as recovery options are given
                       in the IOTP specification.

                       The IOTP Payment Bridge may also use the
                       Status Description to notify the Consumer
                       about further necessary steps in order to
                       resolve some kind of business failures,
                       e.g.,

                       o  "sorry, your payment transaction failed.
                       Unfortunately, you have been charged,
                       please contact your issuer."
                       o  "insufficient capacity left (on your card)
                       for refund",
                       o  "payment failed/chip card error/internal
                       error, please contact your payment
                       instrument's issuer"

   ConsumerDesc        A narrative description of the Consumer.

   ConsumerPayId (14)  An identifier specified by the Consumer
                       which, if returned by the Payment Handler in
                       another Payment Scheme Component or by other
                       means, will enable the Consumer to identify
                       which payment is being referred to. Its
                       value uniquely identifies the payment
                       transaction on the Consumer's system. It is
                       provided by the IOTP Payment Bridge on
                       initialization of the payment transaction.
                       It may equal to the Payment Handler Payment
                       Identifiers but need not necessarily be so.


                       It is recommended that uniqueness extends to
                       multiple payment instruments, payment
                       brands, payment protocols, wallet
                       identifiers, and even multiple IOTP Payment


Werner, et al                                                  [Page 84]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                       Bridges, if they (might) share the support
                       of specific payment brands.

   ContStatus          During payment progress, this status value
                       indicates whether the payment needs to be
                       continued with further IOTP Payment Scheme
                       Component exchanges with the remote party.
                       "End" indicates that the reported payment
                       scheme data is the last data to be exchanged
                       with the counterparty.

   ContentSoftwareId   This contains information which identifies
                       the software which generated the element.
                       Its purpose is to help resolve
                       interoperability problems that might occur
                       as a result of incompatibilities between
                       messages produced by different software. It
                       must contain, as a minimum:

                       o  the name of the software manufacturer,
                       o  the name of the software,
                       o  the version of the software, and
                       o  the build of the software.

   CurrCodeType  (14)  Indicates the domain of the CurrCode. Its
                       value defaults to ISO4217-A.

   CurrCode  (14)      A code which identifies the currency to be
                       used in the payment. The domain of valid
                       currency codes is defined by "CurrCodeType"

   DataBaseFunction    This callback functions may be called by the
                       IOTP Payment Bridge resp. Existing Payment
                       Software whenever data about transactions
                       needs to be stored or retrieved. However,
                       the IOTP Payment Bridge may use its own
                       mechanisms.

   MerchantPayId  (14) An private identifier specified by the
                       Merchant which will enable the Merchant to
                       identify which payment is being referred to.
                       It is a pure private item and is never sent
                       to any other party. It is provided by the
                       IOTP Payment Bridge on payment preparation
                       during brand compilation.

                       Cf. To "ConsumerPayId" for note about
                       uniqueness.

   MerchantOrgId  (64) A private item that might refer to some


Werner, et al                                                  [Page 85]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                       specific shop in a multi shop environment.
                       This item is optional and might enrich the
                       Wallet Identifier which itself can be used
                       for the same purpose.

   Name                Distinguishes between multiple occurrences
                       of Packaged Content Elements at the same
                       point in IOTP. For example:

                       <ABCD>
                         <PackagedContent Name='FirstPiece'>
                           snroasdfnas934k
                         </PackagedContent>
                         <PackagedContent Name='SecondPiece'>
                           dvdsjnl5poidsdsflkjnw45
                         </PackagedContent>
                       </ABCD>

                       The "Name" attribute may be omitted, for
                       example if there is only one Packaged
                       Content element.

   NumberofPayments    The numerical attribute is used to limit the
                       items in inquiry responses.

   OkFrom  (30)        The date and time in UTC Format range
   OkTo  (30)          indicated by the merchant in which the
                       Payment Handler may accept the payment.

   Passphrase  (32)    Payment wallets may use pass phrase
                       protection for transaction data and payment
                       instruments' data. However, it is assumed
                       that there exists a public and customizable
                       payment instrument identifier such that
                       these identifiers together with their
                       relationship to payment brands, payment
                       protocols, payment directions, and currency
                       amounts can be inquired by the IOTP
                       application without any pass phrase
                       knowledge.

   PayDirection        Indicates the direction in which the
                       payment for which a Brand is being selected
                       is to be made. Its values may be:

                       o  Debit: The sender of the Payment Request
                       Block (e.g. the Consumer) to which this
                       Brand List relates will make the payment
                       to the Payment Handler, or
                       o  Credit: The sender of the Payment Request


Werner, et al                                                  [Page 86]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                       Block to which this Brand List relates
                       will receive a payment from the Payment
                       Handler.

   PayInstName         This contains the user-defined name of the
                       payment instrument. There exist no
                       (technical) constraints like uniqueness. The
                       "xml:lang" attribute denotes the language
                       encoding of its value.

   PaymentHandlerDesc  A narrative description of the Payment
                       Handler.

   PaymentHandlerPayId An identifier specified by the Payment
     (14)              Handler which, if returned by the Consumer
                       in another Payment Scheme Component, or by
                       other means, will enable the Payment Handler
                       to identify which payment is being referred
                       to. It is required whenever it is known. Its
                       value uniquely identifies the payment
                       transaction on the Payment Handler's system.
                       It is provided by the IOTP Payment Bridge on
                       initialization of the payment transaction.
                       It may equal to the Consumer Payment
                       Identifiers but need not necessarily be so.

                       Cf. To "ConsumerPayId" for note about
                       uniqueness.

   PaymentInstrumentId An identifier for a specific payment
     (32)              instrument, e.g. "credit card", "Mondex card
                       for English Pounds". This identifier is
                       fully customizable. It is assumed, that it
                       does not contain confidential information or
                       even an indication to it. The payment
                       instrument identifier is unique within each
                       payment brand. It is displayed to the
                       Consumer during brand selection.

   PayReceiptNameRefs  Optionally contains a list of the values of
                       the Name attributes of Packaged Content
                       elements that together make up the receipt.
                       The Packaged Content elements are container
                       either within:

                       o  Payment Scheme Data components exchanged
                       between the Payment Handler and the
                       Consumer roles during the Payment, and/or
                       o  the Payment Receipt component itself.



Werner, et al                                                  [Page 87]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                       Each payment scheme defines in its
                       supplement the Names of the Packaged Content
                       elements that must be listed in this
                       attribute.

   PayReqNetLocn       The Net Location indicating where an
                       unsecured Payment Request message should be
                       sent if this protocol choice is used.

                       The content of this attribute depends on the
                       Transport Mechanism (such must conform to
                       [RFC1738].

   PercentComplete (3) A number between 0 and 100 which indicates
                       the progress of the payment transaction. The
                       values range between 0 and 99 for pending
                       and suspended transactions.

   ProcessState        Contains a Process State Code which
                       indicates the current state of the business
                       success or failure of the processing of the
                       payment transactions. Valid values are:

                       o  NotYetStarted. The Payment Request Block
                       has been received but processing of the
                       Payment Request has not yet started

                       o  InProgress. The payment transaction is
                       pending. The processing of the Payment
                       Request Block and any subsequent Payment
                       Exchange Blocks has started but it is not
                       yet complete.

                       o  Suspended: The payment transaction has
                       been suspended and can be resumed.

                         This process state is mapped to
                       "InProgress", if it is passed to the
                       counterparty's IOTP Application Core.

                       o  CompletedOk. Processing of the Payment
                       Request Block and any following Payment
                       Exchange Blocks has completed
                       successfully.

                       o  Failed. The payment has finally failed for
                       some reason.

                       o  ProcessError. This value is only exchanged
                       when the Status Component is being used in


Werner, et al                                                  [Page 88]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                       connection with an Inquiry Request Trading
                       Block. It indicates there was a Technical
                       Error in the Request Block which is being
                       processed or some internal processing
                       error. Each party's IOTP Payment Bridge
                       uses this value in order to notify the
                       IOTP Application Core about the presence
                       of technical errors.

   PropertyType  (14)  The property type defines codes used for
                       interrogation of specific properties about a
                       payment instrument. They are unique for each
                       payment brand. The predefined property "all"
                       is used on general inquiries. However, these
                       property types are not used during normal
                       payment processing. E.g., they may apply to
                       payment brand specific transactions or out-
                       of-band failure resolution.

   PropertyDesc        The property description carries the
                       respective human readable property (value)'s
                       description.

   PropertyValue       The actual property value intends automatic
                       post processing.

   ProtocolBrandId (64)This is an identifier to be used with a
                       particular payment protocol. For example,
                       SET and EMV have their own well defined, yet
                       different, values for the Brand identifier
                       to be used with each protocol. One Brand
                       Identifier maps to at most one Protocol
                       Brand Identifier.

   ProtocolId  (64)    An identifier for a specific payment
                       protocol and version, e.g. "SETv1.0",
                       "ecash". Valid values are defined by
                       supplements to the IOTP specification and
                       they are unique within each payment brand.

   ProtocolIds         A sequence of Protocol Identifiers

   ProtocolName        A narrative description of the payment
                       protocol and its version in the language
                       identified by "xml:lang". For example
                       "Secure Electronic Transaction Version 1.0".
                       Its purpose is to help provide information
                       on the payment protocol being used if
                       problems arise.



Werner, et al                                                  [Page 89]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   ResponseCode        This attribute encodes a binary flag with
                       the value "Yes" and "No".

   SecPayReqNetLocn    The Net Location indicating where a secured
                       Payment Request message should be sent if
                       this protocol choice is used.

                       A secured payment involves the use of a
                       secure channel such as [SSL] in order to
                       communicate with the Payment Handler.

                       The content of this attribute must conform
                       to [RFC1738].

   ReceiverOrgId       The Organization Identification which
                       receives the payment bridge processing
                       Trading Role Data PackagedContent.

   StatusDesc  (256)   An optional textual description of the
                       current process state in the language
                       identified by "xml:lang" that should be
                       displayed to the Consumer. The usage of this
                       attribute is defined in the payment
                       supplement for the payment method being
                       used. Particularly, it provides hints for
                       out-of-band failure resolution. Its length
                       is limited to 256 characters.

   StyleSheetNetLocn   This contains the net location to a style
                       sheet with visualisation rules for XML
                       encoded data.

   TimeStamp  (30)     The date and time in UTC Format when the
   TimeStampFrom (30)  payment transaction has been started.
   TimeStampTo (30)

   WalletId  (32)      Many existing payment wallet software are
                       multiple wallet capable. The Wallet
                       Identifier selects the actual wallet. It is
                       assumed, that the wallet identifier is a
                       public item, that might be stored by the
                       IOTP Application Core.

   xml:lang            Defines the language used by the Process
                       State Description attribute (cf. IOTP
                       Specification)

                            Table 4: Attributes

   The following table explains the XML elements in alphabetical


Werner, et al                                                  [Page 90]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   order:

   Element             Description

   Algorithm           This contains information which describes
                       an Algorithm that may be used to generate
                       the Authentication response. The
                       algorithm that may be used is identified
                       by the Name attribute (cf. IOTP
                       Specification).

   AuthReqPackagedContent   The Authentication Request Packaged
                       Content originates from a Authentication
                       (Data/Response) Component's content
                       whereby the outermost element tags are
                       prefixed with "AuthReq". Its declaration
                       coincides with the Packaged Content's
                       declaration (cf. IOTP Specification). It
                       encapsulates the authentication challenge
                       value. The content of this information is
                       defined in the supplement for a payment
                       protocol.

   AuthResPackagedContent   The Authentication Response Packaged
                       Content originates from a Authentication
                       (Data/Response) Component's content
                       whereby the outermost element tags are
                       prefixed with "AuthRes". Its declaration
                       coincides with the Packaged Content's
                       declaration (cf. IOTP Specification). It
                       encapsulates the authentication response
                       value. The content of this information is
                       defined in the supplement for a payment
                       protocol.

   BrandPackagedContent     Container for further payment brand
                       description. Its content originates from
                       a Brand Element content whose outermost
                       element tags are prefixed with "Brand".
                       Its declaration coincides with the
                       Packaged Content's declaration (cf. IOTP
                       Specification).

   BrandSelBrandInfoPacka This contains any additional data that
   gedContent          may be required by a particular payment
                       brand. It forms the content of the Brand
                       Selection Brand Info Element.

   BrandSelProtocolAmount This contains any additional data that
   InfoPackagedContent may be required by a particular payment


Werner, et al                                                  [Page 91]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                       brand in the format. It forms the content
                       of the Brand Selection Protocol Amount
                       Info Element.

   BrandSelCurrencyAmount This contains any additional data that
   InfoPackagedContent payment brand and currency specific in
                       the format. It forms the content of the
                       Brand Selection Currency Amount Info
                       Element.

   ChallengePackagedConte Container for authentication challenge
   nt                  data. Its content originates from a
                       Authentication Data Component's Packaged
                       Content element whose outermost element
                       tags are prefixed with "Challenge". Its
                       declaration coincides with the Packaged
                       Content's declaration (cf. IOTP
                       Specification).

   MerchantData        Any merchant related data that might be
                       used by the IOTP Payment Bridge for
                       different purposes, e.g., it might
                       contain access keys to some mall keys.
                       Its declaration coincides with the
                       Packaged Content's declaration (cf. IOTP
                       Specification).

   PackagedContent     Generic Container for non-IOTP data (cf.
                       IOTP Specification).

   PayReceiptPackagedCont   Its content originates from a Payment
   ent                 Receipt Component's Packaged Content
                       whose outermost element tags are prefixed
                       with "PayReceipt". Its declaration
                       coincides with the Packaged Content's
                       declaration (cf. IOTP Specification).

   PaySchemePackagedConte The PayScheme Packaged Content originates
   nt                  from a Payment Scheme Component's content
                       whereby the outermost element tags are
                       prefixed with "PayScheme". Its
                       declaration coincides with the Packaged
                       Content's declaration (cf. IOTP
                       Specification). It carries the payment
                       specific data. The content of this
                       information is defined in the supplement
                       for a payment protocol.

   ProtocolAmountPackaged  The Protocol Amount Packaged Content
   Content             originates from a Protocol Amount


Werner, et al                                                  [Page 92]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                       Element's content whereby the outermost
                       element tags are prefixed with "Amount".
                       Its declaration coincides with the
                       Packaged Content's declaration (cf. IOTP
                       Specification). It contains information
                       about the protocol which is used by the
                       payment protocol. The content of this
                       information is defined in the supplement
                       for a payment protocol.

   ProtocolBrandPackagedC   The Protocol Brand Packaged Content
   ontent              originates from a Protocol Brand
                       Element's content whereby the outermost
                       element tags are prefixed with
                       "ProtocolBrand". Its declaration
                       coincides with the Packaged Content's
                       declaration (cf. IOTP Specification). It
                       contains information about the brand
                       which might be used by the payment
                       protocol. The content of this information
                       is defined in the supplement for a
                       payment protocol.

   ResponsePackagedConten   Container for authentication response
   t                   data. Its content originates from a
                       Authentication Response Component's
                       Packaged Content whose outermost element
                       tags are prefixed with "Response". Its
                       declaration coincides with the Packaged
                       Content's declaration (cf. IOTP
                       Specification).

   TradingRoleDataPackage   The TradingRoleData Packaged Content
   dContent            originates from a TradingRoleData
                       Component's content whereby the outermost
                       element tags are prefixed with
                       "TradingRoleData". Its declaration
                       coincides with the Packaged Content's
                       declaration (cf. IOTP Specification). It
                       contains information from Merchant to
                       Payment Handler via Consumer about the
                       protocol which is used by the payment.
                       The content of this information is
                       defined in the supplement for a payment
                       protocol. The Name attribute in this
                       packaged contents  must include prefix as
                       "Payment:" to indicate that the payment
                       bridge processes this, for example
                       "Payment:SET-OD"



Werner, et al                                                  [Page 93]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                             Table 5: Elements



10.  Payment API Calls



10.1  Brand Compilation Related API Calls



10.1.1  Find Accepted Payment Brand

   This function determines which payment brands could be accepted by
   the Payment Handler on behalf of the Merchant.

   Input Parameters

   o  Payment Direction - provided by the IOTP Application Core
   o  Currency Code and Currency - provided by the IOTP Application
      Core
   o  Payment Amount - provided by the IOTP Application Core
   o  Merchant Payment Identifier - Merchant's unique private
      reference to the payment transaction
   o  Merchant Organisation Identifier - used for distinction between
      multiple merchants that share the some IOTP merchant system
   o  Wallet Identifier - managed by the IOTP Application Core
   o  Merchant Data - specific data used by the IOTP Payment Bridge
      which is managed in the IOTP Application Core.

   XML definition:

   <!ELEMENT FindAcceptedPaymentBrand (MerchantData*) >
   <!ATTLIST FindAcceptedPaymentBrand
     PayDirection  (Debit|Credit)  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     MerchantPayId  CDATA  #REQUIRED
     MerchantOrgId  CDATA  #IMPLIED
     WalletID  CDATA  #IMPLIED >

   Output Parameters

   o  Payment Brand Identifier - for insertion in the Brand List
      Component's Brand Element
   o  Payment Brand Name and language annotation - for insertion in
      the Brand List Component's Brand Element
   o  Payment Brand Logo Net Location - for insertion in the Brand


Werner, et al                                                  [Page 94]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


      List Component's Brand Element
   o  Payment Brand Narrative Description - for insertion in the
      Brand List Component's Brand Element
   o  (Brand) Packaged Content - further payment brand description
      for insertion in the Brand List Component's Brand Element

   The Existing Payment Software returns an empty list of brand items,
   if it does not support any payment brand/payment protocol combination
   for the given payment parameters.

   XML definition:

   <!ELEMENT FindAcceptedPaymentBrandResponse (BrandItem*) >
   <!ATTLIST FindAcceptedPaymentBrandResponse >
   <!ELEMENT BrandItem (BrandPackagedContent*) >
   <!ATTLIST BrandItem
     BrandId  CDATA  #REQUIRED
     xml:lang  NMTOKEN  #IMPLIED
     BrandName  CDATA  #REQUIRED
     BrandLogoNetLocn  CDATA  #REQUIRED
     BrandNarrative  CDATA  #IMPLIED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.1.2  Find Accepted Payment Protocol

   Determines which instances of payment protocols are accepted by the
   Payment Handler on behalf of the Merchant.

   Input Parameters

   o  Brand Identifier - returned by "Find Accepted Payment Brand"
   o  Payment Direction
   o  Currency Code and Currency
   o  Payment Amount
   o  Merchant Payment Identifier - Merchant's unique private
      reference to the payment transaction
   o  Merchant Organisation Identifier - used for distinction between
      multiple merchants that share the some IOTP merchant system
   o  Wallet Identifier - managed by the IOTP Application Core
   o  (Brand) Packaged Content - further payment brand description;
      returned by "Find Accepted Payment Brand"
   o  Merchant Data - specific data used by the IOTP Payment Bridge
      which is managed in the IOTP Application Core.

   XML definition:



Werner, et al                                                  [Page 95]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   <!ELEMENT FindAcceptedPaymentProtocol (BrandPackagedContent*,
   MerchantData*) >
   <!ATTLIST FindAcceptedPaymentProtocol
     BrandId  CDATA  #REQUIRED
     PayDirection  (Debit|Credit)  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     MerchantPayId  CDATA  #REQUIRED
     MerchantOrgId  CDATA  #IMPLIED
     WalletID  CDATA  #IMPLIED >

   Output Parameters

   o  Merchant Organisation Identifier - used for distinction between
      multiple merchants that share the some IOTP merchant system
   o  Refined Currency Code and Currency - for insertion in the Brand
      List Component's Currency Amount Element
   o  Refined Payment Amount - for insertion in the Brand List
      Component's Currency Amount Element
   o  Payment Protocol Identifier - for insertion in the Brand List
      Component's Pay Protocol Element
   o  Protocol Brand Identifier - for insertion in the Protocol Brand
      Element of the Brand List Component's Brand Element
   o  Payment Protocol Name and language annotation- for insertion in
      the Brand List Component's Pay Protocol Element
   o  Payment Request Net Location - for insertion in the Brand List
      Component's Pay Protocol Element
   o  Secured Payment Request Net Location - for insertion in the
      Brand List Component's Pay Protocol Element
   o  (Protocol Brand) Packaged Content - for insertion in the
      Protocol Brand Element of the Brand List Component's Brand
      Element
   o  (Protocol Amount) Packaged Content - for insertion in the Brand
      List Component's Protocol Amount Element
   o  (Protocol) Packaged Content - for insertion in the Brand List
      Component's Pay Protocol Element

   XML definition:

   <!ELEMENT FindAcceptedPaymentProtocolResponse (ProtocolItem+) >
   <!ATTLIST FindAcceptedPaymentProtocolResponse >
   <!ELEMENT ProtocolItem (ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*) >
   <!ATTLIST ProtocolItem
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     ProtocolId  CDATA  #REQUIRED


Werner, et al                                                  [Page 96]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


     ProtocolBrandId  CDATA  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     ProtocolName  CDATA  #REQUIRED
     PayReqNetLocn  CDATA  #IMPLIED
     SecPayReqNetLocn  CDATA  #IMPLIED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.1.3  Get Payment Initialization Data

   This API function provides the remaining initialization data being
   required by the Consumer's or Payment Handler's Existing Payment
   Software. This function might be called both for "brand dependent"
   and "brand independent" transaction types.

   Input Parameters

   o  Brand Identifier - returned by "Find Accepted Payment Brand"
   o  Merchant Payment Identifier - Merchant's unique private
      reference to the payment transaction
   o  Payment Direction
   o  Currency Code and Currency - from the Brand List Component's
      Currency Amount Element
   o  Payment Amount - from the Brand List Component's Currency
      Amount Element
   o  Payment Protocol Identifier - from the Brand List Component's
      Pay Protocol Element
   o  Protocol Brand Identifier - from the Protocol Brand Element
      which relates to the selected Brand Element, if any
   o  (TradingRoleData) Receiver Organization Identifier
   o  OkFrom, OkTo - identical to the entries of the Order Component
   o  Merchant Organisation Identifier - used for distinction between
      multiple merchants that share the some IOTP merchant system
   o  Wallet Identifier and/or Pass Phrase
   o  (Brand) Packaged Content - further payment brand description,
      from the Brand List Component's Brand Element
   o  (Protocol Amount) Packaged Content - further payment protocol
      description, from the Brand List Component's Protocol Amount
      Element
   o  (Protocol) Packaged Content - further payment protocol
      description, from the Brand List Component's Pay Protocol
      Element
   o  (Protocol Brand) Packaged Content - further brand information,
      from the Protocol Brand Element of the Brand List Component
      which relates to the selected Brand Element, if any
   o  (Order) Packaged Content - further order description, from the
      Order Element


Werner, et al                                                  [Page 97]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  three Brand Selection Info Packaged Content elements - copied
      from the Brand Selection Component on brand dependent purchases
   o  Brand - additional data about the payment brand
   o  Protocol Amount - additional data about the payment protocol
   o  Currency Amount - additional payment brand and currency
      specific data
   o  Merchant Data - specific data used by the IOTP Payment Bridge
      which is managed in the IOTP Application Core.

   XML definition:

   <!ELEMENT GetPaymentInitializationData (BrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*,
   ProtocolBrandPackagedContent*,
   OrderPackagedContent*,
   BrandSelBrandInfoPackagedContent*,
   BrandSelProtocolAmountInfoPackagedContent*,
   BrandSelCurrencyAmountInfoPackagedContent*,
   MerchantData*) >
   <!ATTLIST GetPaymentInitializationData
     BrandId  CDATA  #REQUIRED
     MerchantPayId  CDATA  #REQUIRED
     PayDirection  (Debit|Credit)  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     ProtocolId  CDATA  #REQUIRED
     ProtocolBrandId  CDATA  #IMPLIED
     ReceiverOrgId  CDATA  #IMPLIED
     OkFrom  CDATA  #REQUIRED
     OkTo  CDATA  #REQUIRED
     MerchantOrgId  CDATA  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  OkFrom, OkTo - for insertion in the Payment Component
   o  (TradingRoleData) Packaged Content - further payment protocol
      description; the Name Attribute of the packaged contents must
      include "Payment:" as the prefix, for example "Payment:SET-OD".
   o  (Order) Packaged Content - defaults to the supplied order
      packaged data on omission

   The Merchant might

   o  overwrite the previously returned Merchant Payment Identifier
      with a new value,
   o  return just now the Merchant Payment Identifier, or


Werner, et al                                                  [Page 98]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  may skip the generation of any Merchant Payment Identifier.

   XML definition:

   <!ELEMENT GetPaymentInitializationDataResponse
   (OrderPackagedContent*,
   TradingRoleDataPackagedContent*) >
   <!ATTLIST GetPaymentInitializationDataResponse
     OkFrom  CDATA  #REQUIRED
     OkTo  CDATA  #REQUIRED>

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.1.4  Inquire Authentication Challenge

   This API function inquires any payment protocol specific
   authentication challenge value from the IOTP Payment Bridge. In
   Baseline IOTP this API function is called by the Merchant or
   Financial Institution, typically. The IOTP Application Core may
   propose a choice of algorithms to the IOTP Payment Bridge. However,
   the IOTP Payment Bridge may ignore the proposal and select some other
   algorithm. The inquiry is assumed to be stateless. E.g., the IOTP
   Application Core may check the returned algorithm and stop
   transaction processing without notifying the IOTP Payment Bridge.

   The IOTP Application Core may submit several API calls to the IOTP
   Payment Bridge to build up the Authentication Request Block. Any
   choice of algorithms should be reduced by the accepted algorithms
   from earlier API responses.

   Input Parameters

   o  Authentication Identifier - the authenticator may provide its
      payment identifier, i.e., Payment Handler or Merchant Payment
      Identifier.
   o  Wallet Identifier and/or Pass Phrase
   o  set of pre-selected algorithms for authentication

   XML definition:

   <!ELEMENT InquireAuthChallenge (Algorithm*) >
   <!ATTLIST InquireAuthChallenge
     AuthenticationId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters


Werner, et al                                                  [Page 99]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  list of Authentication Challenge Packaged Contents - for
      insertion into the IOTP Authentication Request Component
   o  Algorithm Element - for insertion into the IOTP Authentication
      Request Component

   XML definition:

   <!ELEMENT InquireAuthChallengeResponse (AuthReqPackagedContent*,
   Algorithm) >
   <!ATTLIST InquireAuthChallengeResponse >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.1.5  Authenticate

   The Consumer's IOTP Application Core defers payment protocol specific
   authentication processing and the current challenge value to the
   active IOTP Payment Bridge. Alternative authentication algorithms
   might be tried sequentially or offered to the user for selection.

   Note that the IOTP Application Core has to consider both the current
   context and the algorithm in order to determine the responsible IOTP
   Payment Bridge.

   Failed authentication is reported by the Business Error Code which
   might trigger the inquiry of the details ("Inquire Process State").

   Input Parameters

   o  Authentication Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  Authentication Challenge Packaged Content - copied from the
      IOTP Authentication Request Component
   o  Algorithm Element - copied from the IOTP Authentication Request
      Component

   XML definition:

   <!ELEMENT Authenticate (AuthReqPackagedContent*, Algorithm) >
   <!ATTLIST Authenticate
     AuthenticationId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Authentication Response Packaged Content - for insertion into


Werner, et al                                                 [Page 100]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


      the IOTP Authentication Response Component

   XML definition:

   <!ELEMENT AuthenticateResponse (AuthResPackagedContent*) >
   <!ATTLIST AuthenticateResponse >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.1.6  Check Authentication Response

   This API function verifies the Consumer's payment protocol specific
   authentication response. In Baseline IOTP this API function is called
   by the Merchant or the Financial Institution. This API call happens
   only if the counterparty has responded with an Authentication
   Response Component within the Authentication Response Block.

   Due to the authentication's statelessness, all parameters are
   returned to the IOTP Payment Bridge. Authentication failure is
   reported by a Process State different from "CompletedOK".

   Input Parameters

   o  Authentication Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  Authentication Challenge Packaged Content - generated by the
      Inquire Authentication Challenge (1st content element)
   o  Algorithm Element
   o  Authentication Response Packaged Content - copied from the
      Authentication Response Component (2nd content element)

   XML definition:

   <!ELEMENT CheckAuthResponse (AuthReqPackagedContent*, Algorithm,
   AuthResPackagedContent*) >
   <!ATTLIST CheckAuthResponse
     AuthenticationId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Current Process (Authentication) State
   o  Completion Code
   o  Status Description and its language annotation

   XML definition:


Werner, et al                                                 [Page 101]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   <!ELEMENT CheckAuthResponseResponse EMPTY >
   <!ATTLIST CheckAuthResponseResponse
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)#REQUIRED
     CompletionCode  NMTOKEN  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     StatusDesc  CDATA  #IMPLIED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.1.7  Cancel Payment

   This API function is used by the merchant to notify the local IOTP
   Payment Bridge resp. the payment modules about the immediate
   termination of a payment transaction during the compilation of a
   brand list.

   All the involved components may execute shut down operations on
   internal components and data structures.

   This call might happen anytime during the Brand List Compilation
   process, i.e., before the Offer Response Block has been send to the
   Consumer. Normally, no response code is returned.

   Input Parameters

   o  Merchant Payment Identifier - Merchant's unique reference to
      the current payment transaction
   o  intended Payment Status
   o  intended Completion Code
   o  Wallet Identifier and/or Pass Phrase

   XML definition:

   <!ELEMENT CancelPayment EMPTY >
   <!ATTLIST CancelPayment
     MerchantPayId  CDATA  #REQUIRED
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #REQUIRED


Werner, et al                                                 [Page 102]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


     CompletionCode  NMTOKEN  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   XML definition:

   <!ELEMENT CancelPaymentResponse EMPTY >
   <!ATTLIST CancelPaymentResponse >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

   Essentially, this API function implements a short cut to the API
   function "Change Process State" (see below) with specific input
   parameters and skips the returned attribute values, i.e. any call of
   the form

   <CancelPayment
     MerchantPayId=mmm
     ProcessState=sss
     CompletionCode=ccc
     WalletID=www
     Passphrase=ppp>

   mimics the call

   <ChangeProcessState
     PaymentHandlerPayId=mmm
     ProcessState=sss
     CompletionCode=ccc
     ProcessType=Payment
     Wallet=www
     Passphrase=ppp>.

   Note that the Merchant Payment Identifier is mapped to the Payment
   Handler Payment Identifier. This is valid because the Payment Handler
   has not been involved, so far.



10.2  Brand Selection Related API Calls



10.2.1  Find Payment Instrument"

   This API function determines which instances of a Payment Brand,
   e.g., two Mondex cards, are present. The same physical card may even


Werner, et al                                                 [Page 103]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   represent multiple payment instruments.

   Essentially, the function supports two kinds of payment instrument
   inquiries. Either, the Protocol Identifier and the optional Brand
   Protocol Identifier might be specified on the input parameter list,
   or they might be unspecified. In the former case, the IOTP
   Application Core should also provide any necessary Protocol (Amount)
   Packaged Contents. By this the IOTP Application Core might check for
   valid Payment Instruments for each of the alternatives that have been
   offered by the Merchant.

   In the latter case, the API function returns the superset of
   potentially supported payment instruments (for some Payment
   Protocol). For each of this Payment Instrument, the valid Payment
   Protocols have to be inquired by the API function "Find Payment
   Protocol" and matched by the IOTP Application Core against the
   Payment Protocols that has been reported by the Merchant.

   Input Parameters

   o  Brand Identifier - copied from the Brand List Component's Brand
      Element
   o  payment Protocol Identifier and associated Protocol Brand
      Identifier
   o  Payment Direction - copied from the Brand List Component
   o  Currency Code and Currency - copied from the Currency Amount
      Element
   o  Payment Amount - copied from the Currency Amount Element
   o  Consumer Payment Identifier - Consumer's unique reference to
      the current payment transaction
   o  Wallet Identifier - managed by the IOTP Application Core
   o  (Brand) Packaged Content - further payment brand description;
      copied from the Brand List Component's Brand Element
   o  (Protocol Brand) Packaged Content - further brand information,
      from the Protocol Brand Element of the Brand List Component
      which relates to the selected Brand Element, if any
   o  (Protocol Amount) Packaged Content - further payment protocol
      description, copied from the Brand List Component's Protocol
      Amount Element
   o  Element (Protocol) Packaged Content - further payment protocol
      description, copied from the Brand List Component's Pay
      Protocol Element

   XML definition:

   <!ELEMENT FindPaymentInstrument (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolPackagedContent*,
   ProtocolAmountPackagedContent*) >
   <!ATTLIST FindPaymentInstrument


Werner, et al                                                 [Page 104]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


     BrandId  CDATA  #REQUIRED
     ProtocolId  CDATA  #IMPLIED
     ProtocolBrandId  CDATA  #IMPLIED
     PayDirection  (Debit|Credit)  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     ConsumerPayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED >

   Output Parameters

   o  The known Payment Instrument Identifiers, these are internal
      values
   o  The user-defined names of the payment instrument and their
      language encoding

   The Existing Payment Software responds with an empty list of
   identifiers, either if it does not distinguish between different
   payment instruments or if there are no registered payment instruments
   available despite brand support for at least one (unspecified)
   payment protocol. In the latter case, the IOTP Payment Bridge has to
   request the registration of a suitable payment instrument at a
   subsequent step of the payment process.

   XML definition:

   <!ELEMENT FindPaymentInstrumentResponse (PayInstrument*) >
   <!ATTLIST FindPaymentInstrumentResponse >
   <!ELEMENT PayInstrument EMPTY >
   <!ATTLIST PayInstrument
     Id  CDATA  #REQUIRED
     xml:lang  NMTOKEN  #IMPLIED
     PayInstName  CDATA  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.2.2  Find Payment Protocol

   Determines which instances of payment protocols are supported by a
   particular payment instrument. On omission of the payment instrument,
   the IOTP Payment Bridge responds with the superset of payment
   protocols, supported by all known payment instruments.

   Input Parameters

   o  Brand Identifier - copied from the Brand List Component's Brand


Werner, et al                                                 [Page 105]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


      Element
   o  Payment Instrument Identifier - derived from the Find Payment
      Instrument responses
   o  Payment Direction - copied from the Brand List Component
   o  Currency Code and Currency - copied from the Currency Amount
      Element
   o  Payment Amount - copied from the Currency Amount Element
   o  Consumer Payment Identifier - Consumer's unique reference to
      the current payment transaction
   o  Wallet Identifier - managed by the IOTP Application Core
   o  (Brand) Packaged Content - further payment brand description;
      copied from the Brand List Component's Brand Element
   o  (Protocol Brand) Packaged Content - further brand information,
      from the Protocol Brand Element of the Brand List Component
      which relates to the selected Brand Element, if any
   o  (Protocol Amount) Packaged Content - further payment protocol
      description, copied from the Brand List Component's Protocol
      Amount Element
   o  (Protocol) Packaged Content - further payment protocol
      description, copied from the Brand List Component's Pay
      Protocol Element

   XML definition:

   <!ELEMENT FindPaymentProtocol (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*) >
   <!ATTLIST FindPaymentProtocol
     BrandId  CDATA  #REQUIRED
     PaymentInstrumentId  CDATA  #IMPLIED
     PayDirection  (Debit|Credit)  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     ConsumerPayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED >

   Output Parameters

   o  The supported payment protocol identifiers and associated
      protocol brand identifiers

   XML definition:

   <!ELEMENT FindPaymentProtocolResponse (ProtocolIds*) >
   <!ATTLIST FindPaymentProtocolResponse >
   <!ELEMENT ProtocolIds EMPTY>
   <!ATTLIST ProtocolIds
     ProtocolId  CDATA  #REQUIRED


Werner, et al                                                 [Page 106]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


     ProtocolBrandId  CDATA  #IMPLIED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.2.3  Check Payment Possibility

   This API function checks whether a payment (both debit and credit)
   can go ahead. It can be used, for example, to check

   o  if there are sufficient funds available in a particular
      currency for an electronic cash payment brand,
   o  whether there is sufficient value space left on the payment
      instrument for payment refund,
   o  whether required system resources are available and properly
      configured, e.g., serial ports or baud rate,
   o  whether environment requirements are fulfilled, e.g., chip card
      reader presence or Internet connection.

   In addition, it may be used to remind the Consumer to register a
   suitable payment instrument if an IOTP Payment Bridge has been
   selected that contains no valid payment instrument.

   If the payment method bases on external components, e.g., magnetic
   stripe or chip cards, and the check accesses the medium, the existing
   payment method should not mutually exclusive lock system resources,
   e.g., serial port or modem, that may also be required by other
   Existing Payment Software, e.g., multiple payment software components
   may share the same card reader. If this happens for API internal
   request processing, the function has to unlock these components on
   return. Otherwise, the payment may not proceed if the Consumer
   cancels immediately and decides to use another payment instrument. In
   this event the previous IOTP Payment Bridge is not notified about the
   change.

   This call happens immediately after the Consumer's payment instrument
   selection. For example, if the payment instrument is a chip card,
   that is not inserted in the chip card reader, the Consumer may be
   prompted for its insertion. However, the Consumer should be able to
   hit some 'skip' button, if the payment check is part of the actual
   payment protocol, too. Finally, the IOTP Payment Bridge may provide
   only a subset of these capabilities or may even directly generate a
   successful response without any checks. Alternatively, the callee
   might respond with the ReqNotSupport error code.

   Input Parameters

   o  Brand Identifier - user selection


Werner, et al                                                 [Page 107]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  Payment Instrument Identifier - user selection
   o  Currency Code and Currency Code Type - copied from the selected
      Currency Amount Element
   o  Payment Amount - copied from the selected Currency Amount
      Element
   o  Payment Direction - copied from the selected Trading Protocol
      Option Block
   o  Protocol Identifier - copied from the selected Pay Protocol
      Element
   o  Protocol Brand Identifier - copied from the selected Protocol
      Brand Element of the Brand List Component which relates to the
      selected Brand Element, if any
   o  Consumer Payment Identifier - Consumer's unique reference to
      the current payment transaction
   o  Wallet Identifier and/or Pass Phrase
   o  (Brand) Packaged Content - copied from the selected Brand
      Element
   o  (Protocol Amount) Packaged Content - copied from the selected
      Protocol Amount Element
   o  (Protocol) Packaged Content - copied from the selected Pay
      Protocol Element
   o  (Protocol Brand) Packaged Content - copied from the selected
      Protocol Brand Element of the Brand List Component which
      relates to the selected Brand Element, if any

   XML definition:

   <!ELEMENT CheckPaymentPossibility (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*>
   <!ATTLIST CheckPaymentPossibility
     BrandId  CDATA  #REQUIRED
     PaymentInstrumentId  CDATA  #IMPLIED
     PayDirection  (Debit|Credit)  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     ProtocolId  CDATA  #REQUIRED
     ProtocolBrandId  CDATA  #REQUIRED
     ConsumerPayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  three Brand Selection Info Packaged Content elements - for
      insertion into the Brand Selection component
   o  Brand - additional data about the payment brand
   o  Protocol Amount - additional data about the payment protocol


Werner, et al                                                 [Page 108]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  Currency Amount - additional payment brand and currency
      specific data

   XML definition:

   <!ELEMENT CheckPaymentPossibilityResponse
   (BrandSelBrandInfoPackagedContent*,
   BrandSelProtocolAmountInfoPackagedContent*,
   BrandSelCurrencyAmountInfoPackagedContent*) >
   <!ATTLIST CheckPaymentPossibilityResponse >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.2.4  Quit Payment Instrument

   This API function is used by the card holder to notify the local IOTP
   Payment Bridge resp. the payment modules about the immediate
   termination of a payment transaction during the selection of a
   Payment Instrument.

   All the involved components may execute shut down operations on
   internal components and data structures.

   This call might happen anytime during the Payment Instrument
   Selection process, i.e., before the "Start Payment Consumer" call has
   been issued. Normally, no response code is returned.

   Input Parameters

   o  Consumer Payment Identifier - Consumer's unique reference to
      the current payment transaction
   o  Wallet Identifier and/or Pass Phrase

   XML definition:

   <!ELEMENT QuitPaymentInstrument EMPTY >
   <!ATTLIST QuitPaymentInstrument
     ConsumerPayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   XML definition:

   <!ELEMENT QuitPaymentInstrumentResponse EMPTY >
   <!ATTLIST QuitPaymentInstrumentResponse >


Werner, et al                                                 [Page 109]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

   Essentially, this API function implements a short cut to the API
   function "Change Process State" (see below) with specific input
   parameters and skips the returned attribute values, i.e. any call of
   the form

   <QuitPaymentInstrument
     ConsumerPayId=ccc
     WalletID=www
     Passphrase=ppp>

   mimics the call

   <ChangeProcessState
     ConsumerPayId=ccc
     ProcessState=ProcessError
     ProcessType=Payment
     Wallet=www
     Passphrase=ppp>.



10.3  Payment Transaction Related API calls

   These Payment API calls may be made either by the Consumer's or
   Payment Handler's IOTP Application Core.



10.3.1  Start Payment Consumer

   Initiates a payment at the Consumer side. The IOTP Payment Bridge and
   the Existing Payment Software perform all necessary initialization
   and preparation for payment transaction processing. This includes the
   reservation of external periphery. E.g., the Consumer's chip card
   reader needs to be protected against access from other software
   components, the insertion of the chip card may be requested, the
   Internet connection may be re-established, or the Payment Handler may
   open a mutual exclusive session to the security hardware.

   The IOTP Payment Bridge monitors the payment progress and stores the
   current payment states such that resumption - even after power
   failures - remains possible. The resumption API call provides only a
   subset of the input parameters of the start payment call and refers
   to the payment transaction through the individual party's payment
   identifier.

   The IOTP Payment Bridge may remain accessible for payment processing


Werner, et al                                                 [Page 110]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   without any further supplement of wallet identifiers and pass phrases
   until the transaction's payment status changes to some status
   different from 'InProgress'. Nevertheless, the IOTP Application Core
   has to remember both attribute values for further API call issuance
   and might be requested to supply this information on subsequent API
   calls. But it is recommended that the IOTP Application Core forgets
   these values after any payment transaction status change (Change
   Process State) and removes at least their plain text representations.

   Input Parameters

   o  Brand Identifier - copied from the selected Brand Element
   o  Payment Instrument Identifier - the user selection
   o  Currency Code and Currency - copied from the selected Currency
      Amount Element
   o  Payment Amount - copied from the selected Currency Amount
      Element
   o  Payment Direction - copied from the Brand List Component
   o  Protocol Identifier - copied from the selected Payment Protocol
      Element
   o  Protocol Brand Identifier - copied from the Brand Protocol
      Element of the Brand List Component which relates to the
      selected Brand Element, if any
   o  OkFrom, OkTo - copied from the Payment Component
   o  Consumer Payment Identifier - Consumer's unique reference to
      the current payment transaction
   o  Wallet Identifier and/or Pass Phrase
   o  Call Back Function - used for end user notification/logging
      purposes
   o  Call Back Language List. This list is required if the Call Back
      Function is set
   o  Database Function - the IOTP Payment bridge may refer to this
      API function for data management purposes
   o  (Brand) Packaged Content - further payment brand description;
      copied from the selected Brand Element's content
   o  (Protocol Brand) Packaged Content - further information; copied
      from the Protocol Brand Element of the Brand List Component
      which relates to the selected Brand Element, if any
   o  (Protocol Amount) Packaged Content - further payment protocol
      description; copied from the selected Protocol Amount Element's
      content
   o  (Protocol) Packaged Content - further payment protocol
      description; copied from the selected Pay Protocol Element's
      ncontent
   o  (Order) Packaged Content - further order description, copied
      from the Order Component

   XML definition:

   <!ELEMENT StartPaymentConsumer (BrandPackagedContent*,


Werner, et al                                                 [Page 111]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*,
   OrderPackagedContent*) >
   <!ATTLIST StartPaymentConsumer
     BrandId  CDATA  #REQUIRED
     PaymentInstrumentId  CDATA  #IMPLIED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     PayDirection  (Debit|Credit)  #REQUIRED
     ProtocolId  CDATA  #REQUIRED
     ProtocolBrandId  CDATA  #IMPLIED
     OkFrom  CDATA  #REQUIRED
     OkTo  CDATA  #REQUIRED
     ConsumerPayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED
     CallBackFunction  CDATA  #IMPLIED
     CallBackLanguageList  NMTOKENS  #IMPLIED
     DatabaseFunction  CDATA  #IMPLIED >

   Output Parameters

   o  Time Stamp
   o  Continuation Status
   o  (Payment Scheme) Packaged Content - for insertion into the
      Payment Scheme Component of the IOTP Payment Request Block

   The IOTP Application Core is allowed to reissue this request several
   times on failed analyses of the response.

   XML definition:

   <!ELEMENT StartPaymentConsumerResponse
   (PaySchemePackagedContent*) >
   <!ATTLIST StartPaymentConsumerResponse
     TimeStamp  CDATA  #IMPLIED
     ContStatus  (End|Continue)  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.3.2  Start Payment Payment Handler

   Initiates a payment at the Payment Handler's side. Similar to the
   Consumer's system, the IOTP Payment Bridge and the Existing Payment
   Software perform all necessary initialization and preparation for


Werner, et al                                                 [Page 112]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   payment transaction processing.

   The IOTP Payment Bridge may remain accessible for payment processing
   without any further supplement of wallet/till identifiers and pass
   phrases until the transaction's payment status changes to some status
   different from 'InProgress'. Nevertheless, the IOTP Application Core
   has to remember both attribute values for further API call issuances
   and might be requested to supply this information on subsequent API
   calls. But it is recommended, that the IOTP Application Core forgets
   these values after any payment transaction status change (Change
   Process State) and removes at least their plain text representations.

   Input Parameters

   o  Brand Identifier  - copied from the Consumer selected Brand
      Element
   o  Consumer Payment Identifier - copied from the Payment Scheme
      Component
   o  Currency Code and Currency - copied from the Consumer selected
      Currency Amount Element
   o  Payment Amount - copied from the Consumer selected Currency
      Amount Element
   o  Payment Direction - copied from the Brand List Component
   o  Protocol Identifier  - copied from the Consumer selected
      Payment Protocol Element
   o  Protocol Brand Identifier - copied from the Brand Protocol
      Element of the Brand List Component which relates to the
      Consumer selected Brand Element, if any
   o  OkFrom, OkTo - copied from the Payment Component
   o  Payment Handler Payment Identifier - Payment Handler's unique
      reference to the current payment transaction
   o  Merchant Organisation Identifier -  copied from the Merchant's
      Organisation Element
   o  Wallet Identifier - renaming to till identifier neglected -
      and/or Pass Phrase
   o  Call Back Function - used for end user notification/logging
      purposes
   o  Call Back Language List. This list is required if the call back
      function is set
   o  Database Function - the IOTP Payment bridge may refer to this
      API function for data management purposes
   o  (Brand) Packaged Content - further payment brand description;
      copied from the Consumer selected Brand Element's content
   o  (Protocol Brand) Packaged Content - further information; copied
      from the Protocol Brand Element of the Brand List Component
      which relates to the Consumer selected Brand Element, if any.
   o  (Protocol Amount) Packaged Content - further payment protocol
      description; copied from the Consumer selected Protocol Amount
      Element's content
   o  (Protocol) Packaged Content - further payment protocol


Werner, et al                                                 [Page 113]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


      description; copied from the Consumer selected Pay Protocol
      Element's content
   o  (TradingRoleData) Packaged Content - further payment protocol
      description; the Name Attribute of the packaged contents must
      include "Payment:" as the prefix, for example "Payment:SET-OD".
   o  Three Brand Selection Info Packaged Content Elements - copied
      from the Brand Selection Component
   o  Brand - additional data about the payment brand
   o  Protocol Amount - additional data about the payment protocol
   o  Currency Amount - additional payment brand and currency
      specific data
   o  (Payment Scheme) Packaged Content.

   XML definition:

   <!ELEMENT StartPaymentPaymentHandler (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*,
   BrandSelBrandInfoPackagedContent*,
   BrandSelProtocolAmountInfoPackagedContent*,
   BrandSelCurrencyAmountInfoPackagedContent*,
   TradingRoleDataPackagedContent*,
   PaySchemePackagedContent*) >
   <!ATTLIST StartPaymentPaymentHandler
     BrandId  CDATA  #REQUIRED
     ConsumerPayId  CDATA  #IMPLIED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     PayDirection  (Debit|Credit)  #REQUIRED
     ProtocolId  CDATA  #REQUIRED
     ProtocolBrandId  CDATA  #IMPLIED
     OkFrom  CDATA  #REQUIRED
     OkTo  CDATA  #REQUIRED
     PaymentHandlerPayId  CDATA  #REQUIRED
     MerchantOrdId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED
     CallBackFunction  CDATA  #IMPLIED
     CallBackLanguageList  NMTOKENS  #IMPLIED
     DatabaseFunction  CDATA  #IMPLIED >

   Output Parameters

   o  Time Stamp
   o  Continuation Status
   o  (Payment Scheme) Packaged Content - for insertion into the
      Payment Scheme Component of the IOTP Payment Exchange Block



Werner, et al                                                 [Page 114]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   The response message must contain payment schema data if the
   continuation status signals "Continue". The IOTP Application Core is
   allowed to reissue this request several times on failed analyses of
   the response.

   XML definition:

   <!ELEMENT StartPaymentPaymentHandlerResponse
   (PaySchemePackagedContent*) >
   <!ATTLIST StartPaymentPaymentHandlerResponse
     TimeStamp  CDATA  #IMPLIED
     ContStatus  (End|Continue)  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.3.3  Resume Payment Consumer

   This API function resumes a previously suspended payment at the
   Consumer side. Resumption includes the internal inquiry of the
   payment transaction data, e.g., payment amount, protocol identifier,
   and the whole initialization as it has been applied on the Start
   Payment Consumer API request.

   The IOTP Payment Bridge may remain accessible for payment processing
   without any further supplement of wallet identifiers and pass phrases
   until the transaction's payment status changes to some status
   different from 'InProgress'.

   It is up to the IOTP Application Core to decide whether a Payment
   Request Block or a Payment Exchange Block needs to be generated. One
   indicator might be the receipt of a previous Payment Exchange Block
   from the Payment Handler, e.g., the knowledge of the Payment Handler
   Payment Identifier.

   Input Parameters

   o  Consumer Payment Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  Database Function - the IOTP Payment bridge may refer to this
      API function for data management purposes, particularly, to
      inquire the remaining payment parameters and the current
      payment state

   XML definition:

   <!ELEMENT ResumePaymentConsumer EMPTY >
   <!ATTLIST ResumePaymentConsumer


Werner, et al                                                 [Page 115]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


     ConsumerPayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED
     DatabaseFunction  CDATA  #IMPLIED >

   Output Parameters

   o  Continuation Status
   o  (Payment Scheme) Packaged Content - for insertion in the
      Payment Scheme Component of the next IOTP message (Payment
      Exchange or Request Block).

   The IOTP Application Core is allowed to reissue this request several
   times on failed analyses of the response. However, the IOTP Payment
   Bridge might reject the resumption request by using the "AttNotSupp"
   Error Code "naming" the Consumer Payment Identifier attribute. Then
   the Consumer has to apply normal error processing to the current
   (sub-)transaction and to issue a new Payment Request Block to the
   Payment Handler.

   XML definition:

   <!ELEMENT ResumePaymentConsumerResponse
   (PaySchemePackagedContent*) >
   <!ATTLIST ResumePaymentConsumerResponse
     PaymentHandlerPayId  CDATA  #IMPLIED
     ContStatus  (End|Continue)  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.3.4  Resume Payment Payment Handler

   This API function resumes a payment at the Payment Handler side.

   The IOTP Payment Bridge may remain accessible for payment processing
   without any further supplement of wallet/till identifiers and pass
   phrases until the transaction's payment status changes to some status
   different from 'InProgress'.

   Input Parameters

   o  Consumer Payment Identifier, Payment Handler Payment Identifier
   o  Wallet Identifier - renaming to till identifier neglected - and
      Pass Phrase
   o  Database Function - the IOTP Payment bridge may refer to this
      API function for data management purposes, particularly, to
      inquire the remaining payment parameters and the current


Werner, et al                                                 [Page 116]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


      payment state
   o  (Payment Scheme) Packaged Content - copied from the Payment
      Scheme Component of the received IOTP message (Payment Exchange
      or Request Block).

   XML definition:

   <!ELEMENT ResumePaymentPaymentHandler
   (PaySchemePackagedContent*) >
   <!ATTLIST ResumePaymentPaymentHandler
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED
     DatabaseFunction  CDATA  #IMPLIED >

   Output Parameters

   o  Continuation Status
   o  (Payment Scheme) Packaged Content - for insertion in the
      Payment Scheme Component of the next Payment Exchange Block.

   The response message contains payment schema data if the continuation
   status signals "Continue". The IOTP Application Core is allowed to
   reissue this request several times on failed analyses of the
   response. However, the IOTP Payment Bridge might reject the
   resumption request by using the "AttNotSupp" Error Code "naming" the
   Consumer Payment Identifier attribute. Then the Payment Handler has
   to apply normal error processing to the transaction.

   XML definition:

   <!ELEMENT ResumePaymentPaymentHandlerResponse
   (PaySchemePackagedContent*) >
   <!ATTLIST ResumePaymentPaymentHandlerResponse
     PaymentHandlerPayId  CDATA  #REQUIRED
     ContStatus  (End|Continue)  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.3.5  Continue Process

   This API function passes one specific IOTP Payment Scheme Component,
   i.e., the encapsulated Packaged Content elements, received from the
   counterparty (e.g. Consumer) to the IOTP Payment Bridge and responds
   with the next IOTP Payment Scheme Component for submission to the
   counterparty.


Werner, et al                                                 [Page 117]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   Input Parameters

   o  Consumer Payment Identifier, Payment Handler Payment Identifier
   o  Process (Transaction) Type which distinguishes between Payments
      and Inquiries.
   o  Wallet Identifier and/or Pass Phrase
   o  (Payment Scheme) Packaged Content - copied from the Payment
      Scheme Component of the received Payment Exchange Block or from
      the Error Block.

   Each party should set all know Payment Identifiers. At least, each
   party must set the own Payment Identifier.

   XML definition:

   <!ELEMENT ContinueProcess (PaySchemePackagedContent+) >
   <!ATTLIST ContinueProcess
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     ProcessType  (Payment | Inquiry) 'Payment'
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Continuation Status
   o  (Payment Scheme) Packaged Content - for insertion in the
      Payment Scheme Component of the next Payment Exchange Block or
      final Payment Response Block

   The response message contains payment schema data if the continuation
   status signals "Continue". The IOTP Payment Bridge must signal "End",
   if the payment scheme data was received within an IOTP Error Block
   containing an Error Component with severity HardError.

   XML definition:

   <!ELEMENT ContinueProcessResponse (PaySchemePackagedContent*) >
   <!ATTLIST ContinueProcessResponse
     ContStatus  (End|Continue)  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

   10.3.6  Change Process State

   The IOTP Application Core changes the current payment status by this
   request. The IOTP Payment Bridge may be notified about business level
   normal termination, cancellation, suspension, and processing errors.
   Notification happens by requesting the intended process state. The


Werner, et al                                                 [Page 118]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   IOTP Payment Bridge processes the status change and reports the
   result. The IOTP Application Core has to analyze any returned process
   status in order to check whether the IOTP Payment Bridge has agreed
   or declined the status switch. E.g., the Process State "CompleteOk"
   may lead to the Payment Status "Failed" if the payment transaction
   has already failed. Alternatively, the function may issue an Error
   Response ("BusinessError") if the intended and current payment status
   are incompatible.

   Transaction Suspension is notified by the newly introduced Process
   State "Suspended". The other attribute values have been borrowed from
   the IOTP specification.

   This API function might be called by the Consumer, Merchant, or
   Payment Handler for each payment transaction anytime after the
   issuance of "CheckPaymentPossibility" to the IOTP Payment Bridge by
   the Consumer, the issuance of "GetPaymentInitializationData" by the
   Merchant, or the issuance of "StartPaymentPaymentHandler" by the
   Payment Handler.

   The Process States "Failed" and "ProcessError" are final in the sense
   that they can not be changed on subsequent calls. However, the API
   function should not return with an error code if such an incompatible
   call has been issued. Instead it should report the old unchanged
   Process State.

   Input Parameters

   o  Consumer Payment Identifier, Payment Handler Payment Identifier
      - any known identifier should be supplied. Merchant should map
      their payment identifier to Payment Handler Payment Identifier
   o  intended Payment Status
   o  intended Completion Code
   o  Process (Transaction) Type which distinguishes between Payments
      and Inquiries.
   o  Wallet Identifier and/or Pass Phrase

   XML definition:

   <!ELEMENT ChangeProcessState EMPTY >
   <!ATTLIST ChangeProcessState
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #REQUIRED
     CompletionCode  NMTOKEN  #IMPLIED


Werner, et al                                                 [Page 119]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


     ProcessType  (Payment | Inquiry) 'Payment'
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Process State and Percent Complete
   o  Completion Code
   o  Status Description and its language annotation

   XML definition:

   <!ELEMENT ChangeProcessStateResponse EMPTY >
   <!ATTLIST ChangeProcessStateResponse
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #REQUIRED
     PercentComplete  CDATA  #IMPLIED
     CompletionCode  NMTOKEN  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     StatusDesc  CDATA  #IMPLIED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.4  General Inquiry API Calls

   The following calls are not necessarily assigned to a payment
   transaction and may be issued at any time. There are no dependencies
   on any other calls.



10.4.1  Inquire Payment Log

   This API call may be used to browse the completed payment transaction
   as well as to determine the set of pending or suspended transactions
   that are awaiting their completion or resumption.

   It is up to the IOTP Payment Bridge and the Existing Payment Software
   whether they support such inquiries. Therefore, it is recommended
   that the IOTP Application Core implements the required data base
   capabilities and provides the inquiry mechanisms on its own. However,
   the IOTP Application Core might use this API function to extend its
   own knowledge base about the transactions.


Werner, et al                                                 [Page 120]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   Input Parameters

   o  Brand Identifier - omission defaults to any
   o  Payment Instrument Identifier - omission defaults to any
   o  Consumer Payment Identifier, Payment Handler Payment Identifier
      - omission defaults to any
   o  Process State - omission defaults to any
   o  Completion Code - omission defaults to any
   o  Payment Direction - omission defaults to any
   o  Time Stamp From - omission defaults to 1900-01-
      01T00:00:00.000Z+0
   o  Time Stamp To - omission defaults to 9999-12-31T23:59:59.999Z+0
   o  Currency Code Type - omission defaults to any
   o  Currency Code - omission defaults to any
   o  Amount From - omission defaults to 0
   o  Amount To - omission defaults to unlimited
   o  Ok From - omission defaults to 1900-01-01T00:00:00.000Z+0
   o  Ok To - omission defaults to 9999-12-31T23:59:59.999Z+0
   o  Protocol Identifier - omission defaults to any
   o  Maximal Number of transaction to report - omission defaults to
      unlimited
   o  Wallet Identifier and/or Pass Phrase

   All input arguments are used to define restrictions for the inquiry
   of the payment log. The OkFrom and OkTo attributes are used to
   inquire payment transactions with a non-empty intersection with the
   payment's validity time range which was supplied by the IOTP Payment
   Component.

   However, there exists some risk of user unfriendliness: The user
   initiates the inquiries by the IOTP Application Core which defers the
   inquiries to the IOTP Payment Bridges. Then the IOTP Application Core
   might be requested for appropriate wallet identifiers and pass
   phrases.

   XML definition:

   <!ELEMENT InquirePaymentLog EMPTY >
   <!ATTLIST InquirePaymentLog
     BrandId  CDATA  #IMPLIED
     PaymentInstrumentId  CDATA  #IMPLIED
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #IMPLIED
     CompletionCode  NMTOKEN  #IMPLIED


Werner, et al                                                 [Page 121]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


     PayDirection  (Debit|Credit)  #IMPLIED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #IMPLIED
     AmountFrom  CDATA  #IMPLIED
     AmountTo  CDATA  #IMPLIED
     ProtocolId  CDATA  #IMPLIED
     OkFrom  CDATA  #IMPLIED
     OkTo  CDATA  #IMPLIED
     TimeStampFrom  CDATA  #IMPLIED
     TimeStampTo  CDATA  #IMPLIED
     NumberofPayments  CDATA  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  List of inquired payments. Information for each payment
      transaction is provided on:
   o  Brand Identifier
   o  Payment Instrument Identifier
   o  Consumer Payment Identifier, Payment Handler Payment
      Identifier
   o  Currency Code and Currency Code Type
   o  Payment Amount
   o  Payment Direction
   o  Time Stamp
   o  Process State and Percent Complete
   o  Completion Code
   o  Status Description and its language annotation
   o  Protocol Identifier
   o  Protocol Brand Identifier
   o  OkFrom, OkTo - payment expiration dates
   o  (Brand) Packaged Content Content - further payment brand
      description
   o  (Protocol Brand) Packaged Content Content - further payment
      brand description
   o  (Protocol Amount) Packaged Content Content - further payment
      protocol description
   o  (Pay Protocol) Packaged Content Content - further payment
      protocol description

   XML definition:

   <!ELEMENT InquirePaymentLogResponse(PaymentItem*) >
   <!ATTLIST InquirePaymentLogResponse >
   <!ELEMENT PaymentItem (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*) >
   <!ATTLIST PaymentItem


Werner, et al                                                 [Page 122]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


     BrandId  CDATA  #REQUIRED
     PaymentInstrumentId  CDATA  #IMPLIED
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #REQUIRED
     PercentComplete  CDATA  #IMPLIED
     CompletionCode  NMTOKEN  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     StatusDesc  CDATA  #IMPLIED
     PayDirection  (Debit|Credit)  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     ProtocolId  CDATA  #REQUIRED
     TimeStamp  CDATA  #IMPLIED
     OkFrom  CDATA  #REQUIRED
     OkTo  CDATA  #REQUIRED >

   Generally, the IOTP Payment Bridge should respond as many attributes
   as possible.

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

   10.4.2  Remove Payment Log

   This API function is used by the individual parties to remove
   specific entries from the Payment Log file. The IOTP application core
   notifies the IOTP Payment Bridge resp. the payment modules that a
   particular transaction record is not needed any more and should be
   removed.

   Input Parameters

   o  Consumer Payment Identifier, Payment Handler Payment Identifier
      - known identifier should be provided
   o  Wallet Identifier and/or Pass Phrase

   XML definition:

   <!ELEMENT RemovePaymentLog EMPTY >
   <!ATTLIST RemovePaymentLog
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     WalletID  CDATA  #IMPLIED


Werner, et al                                                 [Page 123]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   XML definition:

   <!ELEMENT RemovePaymentLogResponse EMPTY >
   <!ATTLIST RemovePaymentLogResponse >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

   Note that the Merchant Payment Identifier is mapped to the Payment
   Handler Payment Identifier. This is valid because the Payment Handler
   has not been involved, so far.



10.4.3  Payment Instrument Inquiry

   The Payment Instrument Inquiry API function retrieves the properties
   of the Payment Instrument. The Payment Instrument Identifier could be
   omitted if this identifier is derived by other means, e.g., by
   analysis of the currently inserted chip card. If the Payment
   instrument could not uniquely determined, the IOTP Payment Bridge may
   provide suitable dialogs for user input.

   This API function might be used during problem resolution with the
   Customer Care Provider of the issuer of the payment instrument, in
   order to inquire payment instrument specific values.

   Input parameters

   o  Brand Identifier
   o  Payment Instrument Identifier
   o  Protocol Identifier
   o  Protocol Brand Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  Property Type List - sequence of values whose language is
      identified by xml:lang
   o  (Brand) PackagedContent Content - further payment brand
      description
   o  (Protocol Brand) PackagedContent Content - further payment
      brand information
   o  (Protocol Amount) PackagedContent Content - further payment
      protocol description
   o  (Pay Protocol) PackagedContent Content - further payment
      protocol description

   The codes in the property type list are of two types:


Werner, et al                                                 [Page 124]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  generic codes which apply to all payment methods but might be
      unavailable
   o  Payment Brand specific codes.

   Generic codes for the Property Type List are:

   Property Type         Meaning
   Balance               Current balance
   Limit                 Maximum balance
   PaymentLimit          Maximum payment transaction limit
   Expiration            Expiration date
   Identifier            Issuer assigned identifier of the payment
                         instrument. Usually, it does not match with
                         the API's payment instrument identifier.
   LogEntries            Number of stored payment transaction
                         entries. The entries are numbered from 0
                         (the most recent) to some non-negative
                         value for the oldest entry.
   PayAmountn            Payment Amount of the n-th recorded payment
                         transaction, n may negative
   PayPartyn             Remote party of the n-th payment recorded
                         transaction, n may negative
   PayTimen              Time of the n-th payment recorded
                         transaction, n may negative

   XML definition:

   <!ELEMENT PaymentInstrumentInquiry (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*) >
   <!ATTLIST PaymentInstrumentInquiry
     BrandId  CDATA  #REQUIRED
     PaymentInstrumentId  CDATA  #IMPLIED
     ProtocolId  CDATA  #REQUIRED
     ProtocolBrandId  CDATA  #IMPLIED
     PropertyTypeList  NMTOKENS  #REQUIRED
     xml:lang  NMTOKEN  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output parameters

   o  a list of zero or more unavailable property values whose
      language are identified by xml:lang.
   o  a list of zero or more sets of "Properties Types", "Property
      Values" and "Property Descriptions"

   XML definition:



Werner, et al                                                 [Page 125]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   <!ELEMENT PaymentInstrumentInquiryResponse
   (PaymentInstrumentProperty*) >
   <!ATTLIST PaymentInstrumentInquiryResponse
     xml:lang  NMTOKEN  #REQUIRED
     UnavailablePropertyList NMTOKENS  #IMPLIED >

   <!ELEMENT PaymentInstrumentProperty EMPTY >
   <!ATTLIST PaymentInstrumentProperty
     PropertyType  NMTOKEN  #REQUIRED
     PropertyValue  CDATA  #REQUIRED
     PropertyDesc  CDATA  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.4.4  Inquire Pending Payment

   This API call reports the presence of pending payment transactions.
   It does not respond further transaction details. Note that the IOTP
   Payment Bridge has to respond without the supplement of any pass
   phrase.

   Input Parameters

   o  Wallet Identifier

   XML definition:

   <!ELEMENT InquirePendingPayment EMPTY >
   <!ATTLIST InquirePendingPayment
     WalletId  CDATA  #IMPLIED >

   Output Parameters

   o  Response Code encodes the presence of pending payment
      transactions.

   XML definition:

   <!ELEMENT InquirePendingPaymentResponse EMPTY >
   <!ATTLIST InquirePendingPaymentResponse
     ResponseCode  (Yes|No)  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.





Werner, et al                                                 [Page 126]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


10.5  Payment Related Inquiry API Calls



10.5.1  Check Payment Receipt

   This function is used by the Consumer and might be used by the
   Payment Handler to check the consistency, validity, and integrity of
   an IOTP Payment Receipt whereby the receipt might consists of
   attributes of the Payment Receipt Components and additional Packaged
   Content elements of the same component or of previous Payment Scheme
   Components. The IOTP Application Core has to check the
   PayReceiptNameRefs attribute of the Payment Receipt Component and to
   supply ALL Packaged Content Elements which are referred to.

   Such a verification might include internal consistency check of the
   receipt as well as consistency checks with the whole transaction.

   Input Parameters

   o  Consumer Payment Identifier, Payment Handler Payment Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  Payment Receipt Name References
   o  (Payment Receipt and Payment Scheme) Packaged Content -
      originates from the Payment Receipt Component and previous
      Payment Request/Exchange/Response Components

   XML definition:

   <!ELEMENT CheckPaymentReceipt (PackagedContent*) >
   <!ATTLIST CheckPaymentReceipt
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     PayReceiptNameRefs  NMTOKENS  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   XML definition:

   <!ELEMENT CheckPaymentReceiptResponse EMPTY >
   <!ATTLIST CheckPaymentReceiptResponse >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.






Werner, et al                                                 [Page 127]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


10.5.2  Expand Payment Receipt

   This expands IOTP Payment Receipt Components into a form which may be
   used for display or printing purposes. "Check Payment Receipt" should
   be used first if there is any question of the payment receipt
   containing errors. This function may also access the payment specific
   payment receipt and expand its content. The IOTP Application Core has
   to check the PayReceiptNameRefs attribute of the Payment Receipt
   Component and to supply ALL Packaged Content Elements which are
   referred to.

   Input Parameters

   o  Consumer Payment Identifier, Payment Handler Payment Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  Payment Receipt Name References
   o  (Payment Receipt and Payment Scheme) Packaged Content -
      originates from the Payment Receipt Component and previous
      Payment Request/Exchange/Response Components

   XML definition:

   <!ELEMENT ExpandPaymentReceipt (PackagedContent*) >
   <!ATTLIST ExpandPaymentReceipt
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     PayReceiptNameRefs  NMTOKENS  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Brand Identifier
   o  Protocol specific Brand Identifier
   o  Payment Instrument Identifier
   o  Currency Code and Currency Code Type
   o  Payment Amount
   o  Payment Direction
   o  Time Stamp - issuance of the receipt
   o  Protocol Identifier
   o  Protocol specific Transaction Identifier - this is an internal
      reference number which identifies the payment
   o  Consumer Description, Payment Handler Description, and a
      language annotation
   o  Style Sheet Net Location
   o  Payment Property List. A list of type/value/description triples
      which contains additional information about the payment which
      is not covered by any of the other output parameters; property
      descriptions have to consider the language annotation.



Werner, et al                                                 [Page 128]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   The Style Sheet Net Location refers to a Style Sheet (e.g. [XSL])
   that contains visualization information about the reported XML
   encoded data. However, the IOTP Application Core may ignore this
   attribute.

   XML definition:

   <!ELEMENT ExpandPaymentReceiptResponse (PaymentProperty*) >
   <!ATTLIST ExpandPaymentReceiptResponse
     BrandId  CDATA  #IMPLIED
     PaymentInstrumentId  CDATA  #IMPLIED
     Amount  CDATA  #IMPLIED
     CurrCodeType  NMTOKEN  #IMPLIED
     CurrCode  CDATA  #IMPLIED
     PayDirection  (Debit|Credit)  #IMPLIED
     TimeStamp  CDATA  #IMPLIED
     ProtocolId  CDATA  #IMPLIED
     ProtocolBrandId  CDATA  #IMPLIED
     ProtocolTransId  CDATA  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     ConsumerDesc  CDATA  #IMPLIED
     PaymentHandlerDesc  CDATA  #IMPLIED
     StyleSheetNetLocn  CDATA  #IMPLIED>

   <!ELEMENT PaymentProperty EMPTY >
   <!ATTLIST PaymentProperty
     PropertyType  NMTOKEN  #REQUIRED
     PropertyValue  CDATA  #REQUIRED
     PropertyDesc  CDATA  #REQUIRED >

   The Existing Payment Software should return as many attributes as
   possible from the supplied IOTP Payment Receipt.

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.5.3  Inquire Process State

   This API function returns the current payment status and optionally
   the Payment Receipt Component's Packaged Content. The Payment
   Handler's IOTP Payment Bridge must return this Packaged Content if it
   has been created. The Consumer's IOTP Payment Bridge may return it if
   it has been received and accepted by "Check Payment Receipt".

   Input Parameters

   o  Consumer Payment Identifier, Payment Handler Payment Identifier
      - known payment identifiers should be provided.


Werner, et al                                                 [Page 129]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  Wallet Identifier and/or Pass Phrase

   XML definition:

   <!ELEMENT InquireProcessState EMPTY >
   <!ATTLIST InquireProcessState
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Current Process State and Percent Complete
   o  Completion Code
   o  Status Description and its language annotation
   o  Payment Receipt References
   o  Payment Receipt Packaged Content Data, if available

   The Internet Open Trading Protocol provides a linking capability to
   the payment receipt delivery. Instead of encapsulating the whole
   payment specific data into the packaged content of the payment
   receipt, other Payment Scheme Components' Packaged Content might be
   referred to.

   XML definition:

   <!ELEMENT InquireProcessStateResponse
   (PayReceiptPackagedContent*) >
   <!ATTLIST InquireProcessStateResponse
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #REQUIRED
     PercentComplete  CDATA  #IMPLIED
     CompletionCode  NMTOKEN  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     StatusDesc  CDATA  #IMPLIED
     PayReceiptNameRefs  NMTOKENS  #IMPLIED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.








Werner, et al                                                 [Page 130]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


10.5.4  Start Payment Inquiry

   This API function responds any additional payment scheme specific
   data which is needed by the Payment Handler for Consumer initiated
   payment transaction inquiry processing. The IOTP Payment Bridge resp.
   Existing Payment Software has to determine the payment related items
   inclusive any call back functions that were provided with the "Start
   Payment Consumer" API function call.

   Input Parameters

   o  Consumer Payment Identifier
   o  Wallet Identifier and/or Pass Phrase

   XML definition:

   <!ELEMENT StartPaymentInquiry EMPTY >
   <!ATTLIST StartPaymentInquiry
     ConsumerPayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  (Payment Scheme) Packaged Content - intended for insertion in
      the Payment Scheme Component of  the Inquiry Request Block

   XML definition:

   <!ELEMENT StartPaymentInquiryResponse
   (PaySchemePackagedContent*) >
   <!ATTLIST StartPaymentInquiryResponse >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



10.5.5  Inquire Payment Status

   The Payment Handler uses this API request for Consumer initiated
   inquiry processing. It differs from the previous "Inquire Process
   State" API function by the optional supplement of payment scheme
   specific data. The response may encapsulate further details about the
   payment transaction. However, payment schemes may omit any supplement
   of additional data and may mimic the "Inquire Process State" API
   function by neglecting any returned payment receipt.

   Input Parameters



Werner, et al                                                 [Page 131]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  Consumer Payment Identifier, Payment Handler Payment Identifier
      - known identifier should be provided
   o  Wallet Identifier and/or Pass Phrase
   o  (Payment Scheme) Packaged Content - copied from the Inquiry
      Request Block's Payment Scheme Component

   XML definition:

   <!ELEMENT InquirePaymentStatus (PaySchemePackagedContent*) >
   <!ATTLIST InquirePaymentStatus
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Current Process State
   o  Completion Code
   o  Status Description and its language annotation
   o  (Payment Scheme) Packaged Content - intended for insertion in
      the Payment Scheme Component of the Inquiry Response Block

   XML definition:

   <!ELEMENT InquirePaymentStatusResponse
   (PaySchemePackagedContent*) >
   <!ATTLIST InquirePaymentStatusResponse
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #REQUIRED
     CompletionCode  NMTOKEN  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     StatusDesc  CDATA  #IMPLIED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

   10.6  Other API Calls

   10.6.1  Manage Payment Software

   The following API function notifies the IOTP Payment Bridge about the
   intended registration, modification, or deletion of a payment
   instrument. The actual processing is up to the IOTP Payment Bridge.


Werner, et al                                                 [Page 132]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   This API request may also be used to activate the IOTP Payment Bridge
   resp. Existing Payment Software for general administration purposes.

   Input Parameters

   o  Brand Identifier
   o  Protocol Identifier
   o  Any action code:
   o  New - add new payment method / instrument
   o  Update - change the payment method's / instrument's data
   o  Delete - delete a payment method / instrument
   o  Wallet Identifier and/or Pass Phrase
   o  (Brand) Packaged Content - further payment brand description
   o  (Pay Protocol) Packaged Content - further payment protocol
      description
   o  (Protocol Amount) Packaged Content - further payment protocol
      description

   If the Action attribute is set, the Brand and Protocol Identifier
   have to be set, too. The IOTP Payment Bridge has to provide the
   required user dialogs and selection mechanisms. E.g., updates and
   deletions may require the selection of the payment instrument. A new
   wallet might be silently generated on the supplement of a new Wallet
   Identifier or after an additional end user acknowledge. The IOTP
   Application Core should not provide any pass phrases for new wallets.
   Instead, the IOTP Payment Bridge has to request and verify them which
   may return their value to the IOTP Application Core in plain text. In
   addition, the IOTP Payment Bridge returns the supported
   authentication algorithms when a new brand and protocol pair has been
   registered.

   If the "Action" attribute is omitted, the IOTP Payment Bridge resp.
   Existing Payment Software pops up in a general interactive mode.

   XML definition:

   <!ELEMENT ManagePaymentSoftware (BrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*) >
   <!ATTLIST ManagePaymentSoftware
     BrandId  CDATA  #IMPLIED
     ProtocolId  CDATA  #IMPLIED
     Action  (New |
      Update |
      Delete)  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters



Werner, et al                                                 [Page 133]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  An action code:
   o  New - added new wallet
   o  Update - changed wallet's configuration
   o  Delete - removed a wallet
   o  Wallet Identifier and/or Pass Phrase

   The IOTP Payment Bridge does not return any information about the set
   of registered payment instruments because these data items are
   dynamically inferred during the brand selection process at the
   beginning of each IOTP transaction. However, the IOTP Application
   Core has to be notified about new wallets and should be notified
   about updated and removed wallet (identifier)s". Alternatively,
   removed wallets can be implicitly detected during the next brand
   selection phase. Updated wallets do no affect the processing of the
   IOTP Application Core. The IOTP Payment Software resp. Existing
   Payment Software should only support the addition of at most one
   wallet because it is not able to report multiple additions at once
   back to the IOTP Application Core.

   XML definition:

   <!ELEMENT ManagePaymentSoftwareResponse EMPTY >
   <!ATTLIST ManagePaymentSoftwareResponse
     Action  (New |
      Update |
      Delete)  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED
     AuthNames  NMTOKENS  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.



11.  Called Functions

   There are two functions which can be called by the payment software:

   o  The Call Back Function, which is used to provide information for
   Consumer or Payment Handler notification about the progress of the
   payment transaction.  o  The Database Function which is used to
   store, modify, and retrieve both temporary data during the payment
   transaction and data about suspended or completed payment
   transactions.

   Their use is illustrated in the diagram below.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                         IOTP Application   ----calls----


Werner, et al                                                 [Page 134]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


                         |     Core     |               |
          display        |              |               v
            to  <----------  Call Back <--calls---  Payment
           user          |              |           Software
                         |   Data Base  |
                         |   |       |  |               |
                         |   |  Work | <--calls---------|
                         |   |  and  |  |               |
                         |   |Logging| <--calls----------
                         |   ---------  |
                         |              |
                         ----------------
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                        Figure 19 Called Functions



11.1  Call Back Function

   The "Call Back" function provides the Consumer or Payment Handler
   with information about the payment's progress. Whenever this function
   is called, the content of the status description should be made
   available to the user. For example on a status bar, a pop up window,
   etc.

   A reference to the Call Back function is passed as a parameter to the
   Start Payment X API input message. The Call Back function is then
   called whenever the status changes or progress needs to be reported.

   Input Parameters

   o  the software identifier of the caller
   o  Consumer Payment Identifier, Payment Handler Payment Identifier
      - known identifier should be supplied
   o  Process State and Percent Complete
   o  Completion Code
   o  Status Description and its language annotation, text which
      provides information about the progress of the call. It should
      be displayed or made available to, for example, the Consumer.

   Examples of Status Description could be:

   o  "Paying 12.30 USD to XYZ Inc"
   o  "Payment completed"
   o  "Payment aborted"

   The valid languages are announced in the Call Back Language List
   attribute in "Start Payment X" API function calls.

   XML definition:


Werner, et al                                                 [Page 135]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   <!ELEMENT CallBack EMPTY >
   <!ATTLIST CallBack
     ContentSoftwareID  CDATA  #IMPLIED
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #IMPLIED
     PercentComplete  CDATA  #IMPLIED
     CompletionCode  NMTOKEN  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     StatusDesc  CDATA  #IMPLIED >

   Output Parameters

   XML definition:

   <!ELEMENT CallBackResponse EMPTY >
   <!ATTLIST CallBackResponse >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes. Basically, the call back function accepts
   all input arguments or rejects the whole request. It may even accept
   malformed requests.

   Some payment schemes may require that the Consumer may be able to
   cancel the payment at any time. The Call Back function can be used to
   facilitate this by returning the cancellation request on the next
   call. Note that there exist two mechanisms to notify the IOTP Payment
   Bridge about Cancellations or Suspensions. Either the "Call Back"
   function might use the response the next time it is called or the
   IOTP Application Core might issue a "Change Process State" request to
   the IOTP Application Core. Due to the latter case, IOTP Payment
   Bridge or Existing Payment Software, may ignore the details of the
   "Call Back" response.



11.2  Work and Payment Log Database Function

   The Work Database Function stores, modifies, and retrieves temporary
   data. It is used, for example, to store data about pending payments,
   so that even if the payment software fails, it may be possible to
   restart payments by retrieving the data held in this database. When a
   payment completes, the data about the payment held in the Work
   Database is deleted.



Werner, et al                                                 [Page 136]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   The Payment Log Database Function stores receipt data about a
   payment. It is used to store information about payments with a
   suspended or final payment status. This data should be held on
   permanent storage. It may even, for example, be held remotely in
   order to support keeping of payment records where there is no local
   permanent storage device.

   The API for both databases have been merged for homogeneous database
   access. It is assumed, that the IOTP Application Core defers most of
   the business related database care to the IOTP Payment Bridge and
   Existing Payment Software. Nevertheless, their data management may
   rely on the generic database capabilities of the IOTP Application
   Core.

   Deferring the actual data housekeeping to the IOTP Application Core
   is the proposed implementation because it offers IOTP Application
   Core the opportunities for further features.

   Input Parameters

   o  the software identifier of the caller
   o  Database Type which distinguishes between the Work and the
      PaymentLog Databases
   o  Database Action:
   o  New - which stores a new record
   o  Update - which updates an already stored data record
      identified by the Database Entry Identifier
   o  Get - which retrieves the record identified by the Database
      Entry Identifier
   o  Delete - which deletes the record identified by the Database
      Entry Identifier
   o  First - which positions a record pointer to the "first"
      record in the database and returns the Database Entry
      Identifier
   o  Next - which positions the record pointer to the next record
      and returns the new Database Entry Identifier
   o  Database Entry Identifier - which needs to be supplied on all
      actions except special "New" cases (see below).
   o  Further attributes rephrase those from the "Start Payment
      X" and "Inquire Payment Log" Response message. They are set on
      action "New" and "Update" and omitted otherwise.
   o  Database Data - additional payment software specific data,
      encoding IOTP Payment Bridge's and Existing Payment Software's
      internal states and data
   o  (Brand and Protocol Brand) Packaged Content - further payment
      brand description
   o  (Protocol Amount) Packaged Content - further payment protocol
      description
   o  (Protocol) Packaged Content - further payment protocol
      description


Werner, et al                                                 [Page 137]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  (Payment Receipt and Payment Scheme) Packaged Content - only
      the Packaged Content Elements that form the payment receipt are
      expected to be stored in the data base. However, it is up to
      the IOTP Payment Bridge to decide which elements it stores
   o  (Protocol) Packaged Content - further payment protocol
      description
   o  (Trading Role) Packaged Content - further payment protocol
      description
   o  (Authentication Request and Authentication Response) Packaged
      Content
   o  (Algorithm) element - details about the authentication method;
      its ID attribute is neglected

   Typically, the entries of each wallet" define a collection of data
   items whereby the "First" and "Next" actions are used for sequential
   database scans. The Wallet Identifier identifies the associated
   collection in the data base. In this way records of the work database
   which relate to payments which are not complete and need to be
   canceled after a period of time, may be removed.

   The definition of which record represents the "First" and how the
   "Next" record is identified, is implementation dependent. The is no
   predefined order of the elements within each collection. However the
   use of "First" and "Next" must allow every record on the database to
   be referenced with exactly one report of each entry.

   The "New" action is used to extend a possibly empty collection.
   Omitted attribute values and elements' contents remain undefined.
   However, all REQUIRED attributes from the output parameter list -
   except the Data Entry Identifier - must be set.  The "Update" action
   replaces only the attribute and content values of the referred
   database entry which are mentioned in the database request. The other
   values of the omitted attribute and elements are not affected.

   The "Delete" action returns the data base identifier or the next
   entry.

   XML definition:

   <!ELEMENT AccessDataBase (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*, PackagedContent*,
   TradingRolePackagedContent*,
   AuthReqPackagedContent*,
   AuthResPackagedContent*, Algorithm*) >
   <!ATTLIST AccessDataBase
     ContentSoftwareID  CDATA  #IMPLIED
     DatabaseType  (Work|PaymentLog) #REQUIRED
     Action  (New |


Werner, et al                                                 [Page 138]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


      Update |
      Get |
      Delete |
      First |
      Next)  #REQUIRED
     DataEntryId  NMTOKEN  #IMPLIED
     BrandId  CDATA  #IMPLIED
     PaymentInstrumentId  CDATA  #IMPLIED
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #IMPLIED
     PercentComplete  CDATA  #IMPLIED
     CompletionCode  NMTOKEN  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     StatusDesc  CDATA  #IMPLIED
     PayReceiptNameRefs  NMTOKENS  #IMPLIED
     TimeStamp  CDATA  #IMPLIED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #IMPLIED
     Amount  CDATA  #IMPLIED
     PayDirection  (Debit|Credit)  #IMPLIED
     ProtocolId  CDATA  #IMPLIED
     ProtocolBrandId  CDATA  #IMPLIED
     OkFrom  CDATA  #IMPLIED
     OkTo  CDATA  #IMPLIED
     WalletID  CDATA  #IMPLIED
     CallBackFunction  CDATA  #IMPLIED
     CallBackLanguageList  NMTOKENS  #IMPLIED
     DatabaseFunction  CDATA  #IMPLIED
     Data  CDATA  #IMPLIED >

   Output Parameters

   o  Database Entry Identifier which uniquely identifies the record
      within the database
   o  Further attributes and elements rephrase those from the "Start
      Payment X" and "Inquire Payment Log" Response message (or the
      input parameter list). They are copied from the input message
      on actions "New" or "Update" and filled with the actual values
      otherwise
   o  Database Data - additional payment software specific data about
      the retrieved record

   Generally, the response should contain all the available attribute
   values. The behavior on undefined values is undefined.


Werner, et al                                                 [Page 139]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   XML definition:

   <!ELEMENT AccessDataBaseResponse (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*, PackagedContent*,
   TradingRolePackagedContent*,
   AuthReqPackagedContent*,
   AuthResPackagedContent*, Algorithm*) >
   <!ATTLIST AccessDataBaseResponse
     DataEntryId NMTOKEN  #IMPLIED
     BrandId  CDATA  #REQUIRED
     PaymentInstrumentId  CDATA  #IMPLIED
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     ProcessState  (NotYetStarted |
            InProgress |
            Suspended |
            CompletedOk |
            Failed |
            ProcessError)  #REQUIRED
     PercentComplete  CDATA  #IMPLIED
     CompletionCode  NMTOKEN  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     StatusDesc  CDATA  #IMPLIED
     PayReceiptNameRefs  NMTOKENS  #IMPLIED
     TimeStamp  CDATA  #IMPLIED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     PayDirection  (Debit|Credit)  #REQUIRED
     ProtocolId  CDATA  #REQUIRED
     ProtocolBrandId  CDATA  #IMPLIED
     OkFrom  CDATA  #REQUIRED
     OkTo  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     CallBackFunction  CDATA  #IMPLIED
     CallBackLanguageList  NMTOKENS  #IMPLIED
     DatabaseFunction  CDATA  #IMPLIED
     Data  CDATA  #IMPLIED >
   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes. However, it is assumed that the typical
   caller, i.e.,  IOTP Payment Bridge or Existing Payment Software,
   implements very basic resolution strategies. The caller may retry the
   API requests on error and give up after several retries. But the end
   user should be provided with the error description because it might
   contain further explanations. The error code "ReqRefused" may be used
   to signal the following example errors:

   o  database entry not found


Werner, et al                                                 [Page 140]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   o  database full, no space left
   o  database entry exceeds length limitation

   The Error Code "ReqRefused" is used to signal that the end of the
   database has been reached on the "Next" Action.



12. Security Consideration
   [T.B.D.]



Full Copyright Statement

   Copyright (C) The Internet Society 2000.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



References

   [RFC XXXX] - D. Burdett, "Interenet Open Trading Protocol - IOTP,
   Version 1.0", September 1999. (currently draft-ietf-trade-iotp-v1.0-
   protcool-07.txt)

   [HTML] - Hyper Text Mark Up Language. The Hypertext Markup Language


Werner, et al                                                 [Page 141]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


   (HTML) is a simple markup language used to create hypertext documents
   that are platform independent. See RFC 1866 and the World Wide Web
   (W3C) consortium web site at: http://www.w3.org/MarkUp/

   [HTTP] - Hyper Text Transfer Protocol versions 1.0 and 1.1. See RFC
   1945: Hypertext Transfer Protocol - HTTP/1.0. T. Berners-Lee, R.
   Fielding & H. Frystyk. May 1996. and RFC 2068: Hypertext Transfer
   Protocol - HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T.
   Berners-Lee. January 1997.

   [ISO4217] - ISO 4217: Codes for the Representation of Currencies.
   Available from ANSI or ISO.

   [MIME] - Multipurpose Internet Mail Extensions. See RFC822, RFC2045,
   RFC2046, RFC2047, RFC2048 and RFC2049.

   [SET] - SET Secure Electronic Transaction(TM) , Version 1.0, May 31,
   1997
   Book 1: Business Description
   Book 2: Programmer's Guide
   Book 3: Formal Protocol Definition
   Download from: <http://www.setco.org>.

   [SET/IOTP] - Yoshiaki Kawatsura "SET Supplement for IOTP" (currently
   draft-ietf-trade-iotp-v1.0-set-00.txt)

   [UTC] - Universal Time Coordinated. A method of defining time
   absolutely relative to Greenwich Mean Time (GMT). Typically of the
   form: "CCYY-MM- DDTHH:MM:SS.sssZ+n" where the "+n" defines the number
   of hours from GMT. See ISO DIS8601.

   [XML] - Extensible Mark Up Language. A W3C recommendation. See
   http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998
   version [XSL] Extensible Style Language. See http://www.w3.org/TR



Author's Address

        Hans-Bernhard Beykirch and Werner Hans
        IT Development & Coordination Center for the German Savings Banks
        Organization (SIZ)
        Konigswinterer Strase 553
        53227 Bonn
        Germany
        E-mail: Hans-Bernhard.Beykirch@siz.de, Werner.Hans@siz.de

        Masaaki Hiroya and Yoshiaki Kawatsura
        Hitachi, Ltd.
        890 Kashimada Saiwai-ku Kawasaki-shi


Werner, et al                                                 [Page 142]



INTERNET-DRAFT          SET Supplement for IOTP               March 2000


        Kanagawa, Japan 212-8567
        E-mail: hiroya@sdl.hitachi.co.jp, kawatura@bisd.hitachi.co.jp



Expiration and File Name

   This draft expires September 2000.

   Its file name is draft-ietf-trade-iotp-v1.0-papi-00.txt.










































Werner, et al                                                 [Page 143]