Subject: Version 1.0 changes from Hitachi IOTP meeting 9-11 November, Tokyo

From: David Burdett <[email-masked]>
Date: Tue, 17 Nov 1998 01:34:46 -0000

The following is a list of the changes identified during the IOTP
meeting held at Hitachi premises in Tokyo on 9-11 November.

1)	Packaged Content. There is a need for Packaged Content to contain
multiple items of data e.g. in the Pay Receipt Component, to support
encapsulation of SET messages. To support this propose the following
amendment to the Packaged Content element (see section 3.7.1):
a)	allow multiple occurrences of PackagedContent wherever it occurs.
This makes it a general solution
b)	add an optional Name attribute to the definition of packaged content
which can be used to identify which PackagedContent is used for which
purpose
c)	also clarify description of the Trading Role Data component (see
section 6.16) to suggest that it can contain payment protocol specific
information as well
d)	this change is backwards compatible with Version 1.0
2)	The definition of the Packaged Content in the Payment Component
suggests that its use is the same as for the Packaged Content in the
Trading Role Data Component. (Raised by 'Yoshiaki Kawatsura'). Suggested
answer Trading Role Data component should be used instead of the
Packaged Content in the Payment Component since it is more general
approach to the problem which allows any two parties to exchange
information. This also means that the Packaged Content element within
the Payment Component should be removed.
3)	Brand ID. SET defines its own rules for identifying Brands with the
structure, "BrandId:Product:PromotionalBrand". Since this naming
convention for Brands already exists, suggest that it is adopted by IOTP
as follows
a)	add "SET" as a valid "BrandIdDomain" for credit cards (see section
6.6.1)
b)	It is also suggested that the SCCD protocol adopts SET conventions
for identifying brands
4)	Change definition of Brand ID domain to conform to IETF/IANA
conventions. The current convention for identifying Brand Id Domains
(see section 6.6.1) does not conform to IETF/IANA conventions. Suggest
that its definition is changed to comply. Also applies to other names in
IOTP
5)	Registration procedure for new names. Procedures need to be defined
for the registration of new names, for example Brand Id domain. ACTION:
Don Eastlake.
6)	Text version diagrams. The start and end of diagrams in the ASCII
text versions of the specification are hard to identify. Recommend that
it is made clearer. For example start each diagram with a line of "dash"
characters and end it with a line of "equals" characters.
7)	Correction. CancelNetLocn attribute definition needs to added to the
XML definition given in section 6.5.2.
8)	Digital Signatures. The section on Digital Signatures (section 5)
needs to be updated to reflect how OTP should use the XML signatures as
defined in Richard Brown's proposal. ACTION: Don Eastlake
9)	Net Locations. Change net locations in Protocol Options or Trading
Role Elements to reflect:
a)	SuccessNetLocn - per transaction - Where the Consumer goes if the
transaction is successful
b)	CancelNetLocn - per trading role - where the Consumer goes if the
Consumer cancels the transaction at some point
c)	xxxRequestLocn - where xxx is payment, delivery, etc the location to
which incoming messages with either no errors or technical errors of any
Severity are sent. This means that anybody who sends a message with
errors in it receives a message that indicates there was an error
d)	ErrorLogNetLocn - per trading role, optional -  where the Consumer
sends IOTP messages if they receive an incoming message in which they
detect a technical error with Severity of HardError or TransientError.
Could be used to send error messages to the software company or some
other organisation responsible for fixing problems in the software which
sent the incoming message.
e)	ErrorNetLocn - per trading role - where the consumer goes after
receiving or generating an Error Block with severity of HardError or
TransientError
f)	Also need to provide guidelines which indicate how the consumer
determines which redirect location to use based on where they are I the
location.
10)	Unknown Error. Add an additional error code  (see section 6.19.2)
called UnknownError to indicate that the transaction cannot complete for
some reason. This could be used to indicate an internal error of some
kind. The ErrorDesc attribute should be used to indicate the nature of
the problem.
11)	Authentication Transaction. 
a)	Standalone Authentication. Add an Auth Status message from the
authenticator to the authenticatee to indicate that success or failure
of the authenticator's validation of the Authentication Response
message.
b)	Pre authentication. Allow purchase, refund, withdrawal, deposit and
value exchange IOTP transactions to be preceded by an optional pre
authentication sequence which does an authentication request and
response and then segue's into the real transaction with a new TPO. A
failed authentication will result in an Auth Status as in the Standalone
Authentication
12)	Authentication Method and Authentication Response. In the
Authentication Data Component (section 6.2). Needs to be revised.
ACTION: Richard Brown to provide input.

>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]

---

From: David Burdett <[email-masked]>
Date: Wed, 18 Nov 1998 06:31:56 -0000

... in fact Mondex e-cash can make good use of this feature too ...
which proves the point.

Regards

David

>----------
>From: 	Donald E. Eastlake 3rd[SMTP:[email-masked]]
>Sent: 	17 November 1998 12:32
>To: 	David Birch
>Cc: 	David Burdett; [email-masked]'
>Subject: 	Re: Version 1.0 changes from Hitachi IOTP meeting 9-11 November,
>Tokyo 
>
>
>IOTP is not dependent on SET but SET is an interesting test case for a
>payment system to be carried within IOTP.  Whatever you think of SET,
>other payment systems might have similar requirements.  And some IOTP
>implementors specifically plan to include SET among the payment sytems
>they are going to be using with IOTP which is why we have a specific
>subgroup looking into that.
>
>I think the right way to look at this is that some uses of IOTP will
>need to send multiple items where there is currently a provision for a
>single Packaged Content.  People designing those uses can, of course,
>figure out their own way to include multiple items within a Packaged
>Content.  And if they need to include dozens or hundreds of items,
>they probably should figure out some technique that is suitable to the
>data they are packaging.  But it seeme likely that it will be common
>enough for their to be a few separate items to be packaged that a
>standard technique will save people the trouble of re-inventing
>combined packaging ever time such a requirement appears.  The fact
>that the first couple of times the requirement has come up were with
>regard to SET does not mean it won't come up elsewhere.
>
>Thanks,
>Donald
>
>From:  Dave Birch <[email-masked]>
>Date:  Tue, 17 Nov 1998 19:12:48 +0000
>To:  David Burdett <[email-masked]>,
>            "[email-masked]'" <[email-masked]>
>Message-ID:  <[email-masked]>
>
>>David Burdett said
>>
>>Wouldn't it greatly simplify IOTP and speed the time to market if we got 
>>rid of SET altogether? See for example
>>
>>http://www.americanbanker.com/cgi-bin/print_tagstory?981117DIGI002
>>
>>Regards,
>>Dave Birch.
>>
>>=== mailto:[email-masked] ===== http://www.hyperion.co.uk/ ===
>