Subject: RE: Authorization before OTP

From: Donald Eastlake <[email-masked]>
Date: Thu, 24 Sep 1998 01:57:44 -0400

I'm not sure why this failed the first time....

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

---------------------- Forwarded by Donald Eastlake/Hawthorne/IBM on 09/23/98
10:44 PM ---------------------------
Please respond to [email-masked]
To: Donald Eastlake/Hawthorne/IBM@IBMUS
cc:
Subject: Returned mail: Host unknown (Error 281)

The original message was received at Tue, 22 Sep 1998 08:34:16 -0400
from relay1.server.ibm.com [9.14.2.98]

   ----- The following addresses had permanent fatal errors -----
<[email-masked]>

   ----- Transcript of session follows -----
550 <[email-masked]>... Host unknown (Error 281)
--------------------------------------------------------------------------------
Final-Recipient: RFC822; [email-masked]
Action: failed
Status: 5.1.2
Remote-MTA: DNS; smtp.elistx.com
Last-Attempt-Date: Tue, 22 Sep 1998 08:37:29 -0400
--------------------------------------------------------------------------------
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)...

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:
Subject: Authorization before OTP

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]

-----------------------------------------------------------------------
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: Hannu Nikkanen <[email-masked]>
Date: Thu, 24 Sep 1998 12:20:55 +0300

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