Subject: Authorization before OTP

From: Andrew Drapp <[email-masked]>
Date: Tue, 22 Sep 1998 12:15:18 +0900

At the OTP meeting in Reston, there was some discussion of using the 
Authorization exchange to automate the collection of personal information 
for a sale.  This would save time in typing out you name and address each 
time you purchased something.  This would have to occur before the first OTP 
message is sent, because the Org block is in the first message and cannot be 
changed later on.

From what I remember of the meeting, it was generally agreed that this was a 
good idea, and should be included in version 1.0 or 2.0.

However, I recently noticed a problem with that approach.  When the consumer 
receives an AuthReq block, it will have to be in HTML because the OTP client 
has not started yet.  This will kick off the OTP client which will create 
the AuthResp block.  The problem is, that the OTP client does not know where 
to send the AuthResp block.  No address information is included in the 
AuthReq block.  It is assumed that the OTP client could just check the 
TransId for the location, but because this occurs before the Offer Exchange, 
there is no TransId to refer too.

Because of this, I suggest that:

1.  We add addressing information to the AuthReq block,

or

2.  We dump the idea to use the Authorization exchange outside of an OTP 
transaction.

Regards,

Andrew Drapp

--
Andrew Drapp
[email-masked]
Hitachi Systems Development Laboratory
1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN
TEL:+81-44-966-9111   FAX:+81-44-966-1796
Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F

-----------------------------------------------------------------------
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, 23 Sep 1998 08:33:27 +0100

Andrew

Not quite right. The TPO Block can contain Organisation Components. We
should change the definition of the Authentication Transaction to
require that this contains the details of the organisation which is
requesting the Authentication specifying the role in which the
authenticator is taking in the transaction (Merchant, Payment Handler or
Delivery Handler).

The consumer will then know who to send the response to.

David

>----------
>From: 	Andrew Drapp[SMTP:[email-masked]]
>Sent: 	22 September 1998 04:15
>To: 	[email-masked]'
>Subject: 	Authorization before OTP
>
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mondex International Limited
47-53 Cannon Street, London  EC4M 5SQ
England
Registered No: 3122085, England

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.com
-----------------------------------------------------------------------
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: Andrew Drapp <[email-masked]>
Date: Thu, 24 Sep 1998 14:02:09 +0900

David,

I think I explained myself poorly.  When I said that the Org component is in 
the first OTP message, I was referring to the TPO as the first OTP message. 

When you say "The TPO Block can contain Organization Components" how exactly 
do you mean *can*.  From what I understood, the Org components were removed 
from the Offer response, and placed only in the TPO Block.  The Org 
component would then be copied from message to message.  So, once the TPO 
message is sent, the Org component has a fixed value that cannot be changed. 

If we change the Authentication Transaction so that it contains the details 
of the organization which is requesting the Authentication, then those 
details should also include a net location for the auth response to go to. 
 If we made that change, then both the consumer and the merchant could 
authenticate each other before a trade actually occurs.

I think that would solve this problem.

-----Original Message-----
From:	David Burdett [SMTP:[email-masked]]
Sent:	Wednesday, September 23, 1998 4:33 PM
To:	'Andrew Drapp'
Cc:	[email-masked]'
Subject:	RE: Authorization before OTP

Andrew

David

---

From: David Burdett <[email-masked]>
Date: Thu, 24 Sep 1998 13:41:36 +0100

See comments below

>----------
>From: 	Donald Eastlake[SMTP:[email-masked]]
>Sent: 	24 September 1998 06:57
>To: 	[email-masked]

>I think that some way to deliver a ship-to address to the merchant, while it
>may seem minor, is an important capability in practice.  The problem of where
>to send the IOTP response for an IOTP authentication request that is included
>in an HTTP response might eventually occur with other requests than
>authenticaiton and in other trasnports than HTTP.
>
>Perhaps there should be an optional ContinuationNetLoc field which, if it
>occurs in a response, is where to send the next request and if it occurs in a
>request is where to send the response.  This would raise the question of what
>this means if it occurs in an IOTP request enclosed in an HTTP request but
>that
>could be treated as an error (i.e., the documention of ContinuationNetLoc
>could
>say that it may be prohibited in some transport contexts as indicated in the
>IOTP supplement for that transport)...
>>> I don't really like the idea of dynamically re-directing responses
although it is very flexible and powerful since it could potentially
be a "spoofer's" charter so that a message, e.g. for a payment could
be sent anywhere.

One way around this is to use signatures on the messages which contain a
re-direction which could potentially be any message.

I think it better to just use the Organisation Component net location.

David
<<<
>
>Donald
>
>Donald E. Eastlake, 3rd
>318 Acton Street, Carlisle, MA 01741 USA
>Internet: [email-masked]
>Notes: Donald Eastlake/Hawthorne/IBM@IBMUS
>1-978-287-4877, fax 1-978-371-7148
>
>
>
>[email-masked] on 09/21/98 11:40:16 PM
>Please respond to [email-masked]
>To: [email-masked]
>cc:

---

From: David Burdett <[email-masked]>
Date: Thu, 24 Sep 1998 13:45:26 +0100

>Hannu said "Also, it would be nice to have (optional) receiver name (if
different from "payer"). "

I *think* this is already covered in that the "DelivTo" role is the name
of the "reciever" where the Consumer role is the person or organisation
that is the "payer".

David

>----------
>From: 	Hannu Nikkanen[SMTP:[email-masked]]
>Sent: 	24 September 1998 10:20
>At 01:57 AM 9/24/98 -0400, Donald Eastlake wrote:
>
>>---------------------------------------------------------------------------
>-----
>Strong support, in real life that's often needed.
>
>Also, it would be nice to have (optional) receiver name (if different from
>"payer"). In the office we use company credit card for authorized purchases
>and sometimes it's really difficult to find out, whose purchases the
>different records in the bill are.
>
>Hannu
> 
>
> 
>
>
>

---

From: Andrew Drapp <[email-masked]>
Date: Thu, 24 Sep 1998 22:10:47 +0900

This message from David Burdett, and meant for the list.

-----Original Message-----
From:	David Burdett [SMTP:[email-masked]]
Sent:	Thursday, September 24, 1998 9:36 PM
To:	'Andrew Drapp'
Subject:	RE: Authorization before OTP

See comments below.

David
>Sent: 	24 September 1998 06:02
>To: 	David Burdett; [email-masked]'
>>>Agreed. Provided that the trading role(s) used by the requesting
organisation reflect the organisation's intended role in the actual
transaction. You could also make a constraint that the Organisation
component should not change between the use in the authentication and
the use in, for example, the Baseline Purchase.<<<