Subject: IOTP version 2.0 ideas

From: David Burdett <[email-masked]>
Date: Thu, 19 Nov 1998 16:02:52 -0000

This note describes ideas for Version 2 of  IOTP. It contains
1)	Suggested enhancements which were identified before the IOTP meeting
in Tokyo. These have been documented previously but are included for
completeness
2)	Suggested enhancements identified during the IOTP meeting in Tokyo,
and
3)	A possible structure for the version 2.0 specification. The main
change is to split the existing specification into several smaller
separate specifications which address specific topics. This should make
the specification more reusable and accessible.

Comments are welcome

David

SUGGESTED ENHANCEMENTS PRIOR TO TOKYO MEETING
=============================================
1)	Change the Authentication Trading Exchange so that it now includes an
Authentication Exchange message to occur between the Authentication
Request and the Authentication Response (see Chris Smith e-mail).
2)	Add an optional Offer Request Block to be included in a message to
the Merchant that precedes the Offer Response message from the Merchant
to the Consumer. It could be used to contain, for example, purchase
order details
3)	Include Authentication Method Selection as an option for version 2.0
4)	Develop messages to support reconciliation between the trading roles
in IOTP. This would allow, for example, a Payment Handler to report the
results of a payment to a Merchant in a standard way.
5)	Develop messages/transactions to support Merchant Customer Care.
6)	Revise the Pay Amount Component to support multiple payment amounts
for recurring (e.g. subscription) payments.

ENHANCEMENTS SUGGESTED DURING TOKYO MEETING
===========================================
1)	Extending OTP. The current way of using a "Critical"attribute to
define elements which are extensions to OTP means that a validating XML
parser cannot be used to check messages. This means that if you come
across a message with extensions and a validating parser is used, then
the message cannot be examined at all since it will fail the message. An
alternative would be to define a separate element designed to hold
extensions with content type of ANY.
a)	Advantages of this approach would mean that the OTP messages with
extensions could checked using a validating XML parser
b)	The disadvantage is that extensions to IOTP messages could only occur
in specific places.
c)	Needs further discussion to resolve - Action: Chris Smith will post
separate message Trade WG
2)	Add an additional optional Order Payment Annotation element to the
Order Description Component. The purpose of the element is to enable
various amounts which relate to the Order to be recorded. This could be
used, for example to describe:
a)	the tax paid on the order
b)	loyalty points acquired
c)	the fee paid on a withdrawal or value exchange
d)	Action David Burdett provide write up and post to Trade WG list

POSSIBLE STRUCTURE FOR VERSION 2 SPECIFICATION(S)
=================================================
This section describes ideas for the structure of version 2. 

The following principles were thought good ones to follow:
1)	re-work the structure of version 1.0 into several separate documents
to make it more modular and accessible. This would mean that parts of
IOTP could be more easily referenced and used by other e-commerce
standards where appropriate.
2)	adopt an evolutionary approach, by re-structuring the existing
protocol and so aim to preserve current implementer's investment in
development wherever possible
3)	provide new functionality in separate documents - e.g. dynamic
sequencing of steps/services
4)	Aim for no radical re-working of the current architecture, design or
content of IOTP.

There would be several separate documents:
1)	IOTP Overview - a guide on how to use all the other documents.
2)	IOTP Messaging - how to exchange data reliably between trading roles
3)	IOTP Offer/Payment/Delivery/Authentication Trading Exchange (4
separate documents)
4)	IOTP Baseline Transactions
5)	IOTP Dynamic Transactions - how to sequence steps in a transaction
dynamically
6)	IOTP Customer Care Exchange
7)	IOTP Inter Trading Role Reporting Exchange
8)	IOTP Payment Supplements (as now)
9)	IOTP Transport Supplements (as now)

Where relevant, each part would have its own separate DTD.

In the outlines of each document which follow, the numbers in brackets,
indicate the number of the relevant section in the version 1-0
specification which would form the basis of the new document.

IOTP OVERVIEW

This document should be read first and provides an overview of the other
documents

It includes information from the Business Specification.

IOTP MESSAGING

Would explain how to exchange information between the Trading Roles in
e-commerce. It would be generic and not define or refer to any specific
trading role or transaction apart from some examples.

Contents:
1)	IOTP Overview
a)	Architecture
i)	Trading Role principles (2.1)
ii)	Trading Exchange principles (2.2)
b)	Messages and Transactions
i)	IOTP Message Structure (3.1.1)
ii)	IOTP Transactions (3.1.2)
iii)	IOTP Message (3.2)
c)	Guidelines for creating Transactions from blocks and components
2)	Common concepts
a)	Trans reference block (3.3)
b)	ID attributes (3.4)
c)	Element References (3.5)
d)	Packaged Content Element (3.8)
e)	Identifying Languages (3.9)
f)	Secure and Insecure Net Locations (3.10)
g)	Extending IOTP (3.7)
3)	IOTP Error handling (4)
4)	Security Considerations (5)
5)	Components:
a)	Organisation Component (6.5)
b)	Status Component (6.15)
c)	Trading Role Data Component (6.16)
d)	Inquiry Type Component (6.17)
e)	Signature Component (6.18) - refers to Dsig proposal
f)	Error Component (6.19)
6)	Trading Blocks
a)	TPO Block ? (7.1)
b)	TPO Selection Block ? (7.2)
c)	Signature Block (7.18)
d)	Error Block (7.19)
7)	Transactions
a)	Inquiry Transaction
i)	Transaction Message flow (8.8)
ii)	Inquiry Request Trading Block (7.14)
iii)	Inquiry Response Trading Block (7.15)
b)	Ping Transaction
i)	Transaction Message flow (8.9)
ii)	Ping Request Block (7.16)
iii)	Ping Response Block (7.17)
8)	IOTP Message DTD definition

IOTP PAYMENT TRADING EXCHANGE

Defines how to do a payment. 

The payment exchange would have its own version number. This means that
payment exchange could evolve independently of other parts of the IOTP
specification.

Contents:
1)	Introduction
2)	Payment Handler Trading Role (from 2.1)
3)	Payment Exchange (2.2.2 - part)
4)	Brand Selection Exchange (2.2.2 - part)
5)	Brands and Brand Selection (3.6)
6)	Components
a)	Brand List Component (6.6)
b)	Brand Selection Component (6.7)
c)	Payment Component (6.8)
d)	Payment Scheme Component (6.9)
e)	Payment Receipt Component (6.10)
f)	Payment Note Component (6.11)
7)	Blocks:
a)	Payment Request Block (7.6)
b)	Payment Exchange Block (7.7)
c)	Payment Response Block (7.8)
8)	Status Component
a)	valid codes for payment
9)	Error Component
a)	codes to apply for payments
10)	Retrieving Logos (9)
11)	Brand List Examples (10)
12)	Payment DTD definition

IOTP OFFER/DELIVERY/AUTHENTICATION EXCHANGE

These would be separate documents each similar in structure to Payment
Trading Exchange.

Enhancements would be included where agreed, for example "Offer
Request".

IOTP BASELINE TRANSACTIONS

Describes how to do existing baseline transactions by reference to
exchanges. Existing IOTP transaction types would be defined be under a
domain (e.g. the Baseline domain, e.g Baseline:Purchase). 

Also possible for organisations to declare new "fixed" transaction types
by registering domain and name with IANA. Examples of names would be:
1)	BizToBiz:Purchase - variation of purchase invented by "Biz to Biz"
group
2)	UsedMicro:Auction - an auction transaction invented by a particular
company.

Each declared Transaction type would have an implied sequence for
carrying out each step.

Refers to other specs, e.g. IOTP Messaging and relevant "Exchange"
specs.

Contents:
1)	Introduction
2)	Baseline Authentication (8.1)
3)	Baseline Deposit (8.2)
4)	Baseline Purchase (8.3
5)	Baseline Refund (8.4)
6)	Baseline Withdrawal (8.5)
7)	Baseline Value Exchange (8.6)

Each Transaction would have a DTD which defines how other elements in
other DTDs are re-used.

Sample messages would be provided.

IOTP DYNAMIC TRANSACTIONS

New document which describes how to do dynamic transactions. Dynamic
transactions allow trading exchanges to be grouped together as required
to do a particular trade. For example a purchase with two payments, e.g.
a credit card followed by loyalty points.

IOTP PAYMENT SUPPLEMENTS

Essentially these would be the current documents, e.g. the SET
supplement

IOTP TRANSPORT SUPPLEMENTS

Essentially the current documents e.g. HTTP supplement

>Mondex International Limited
mailto:<[email-masked]>
>US Advanced Technology Office: 111 Pine St, 6th Floor, San Francisco, CA
>94111
Tel/Voicemail: +1 415 645 6973	Fax: +1 415 956 9370

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]