Subject: TRADE WG Draft Minutes from Minneapolis

From: [email-masked]
Date: Fri, 19 Mar 1999 15:14:33 -0500

Here are draft minutes of the TRADE working group meeting at the 44th IETF
meeting in Minneapolis taken by Kent Davidson.  Please send comments or
corrections to the list.  Thanks, Donald

TRADE Meeting 3/17/1999
-----------------------
Started 1999, March 17th, 13:05

Chair, Donald Eastlake

Agenda presented

David Burdett, Mondex: talk about evolution of documents

Changes between draft versions 02 and 03 of the main IOTP protocol
document.
    Outlined below...

Digital Signatures
    - Updated to reflect dsig draft. Updated section 5
    - separate paper covering dsig
    - revised DTD

Authentication
    - Last November, decided to permit authentcation to preceed any
transaction
    - Changes to offer and payment request

IOTP Transactions Section
    - Changes driven by authentication changes
    - Result:
    - Single def of message flow (how you do the payment, etc.)
    - Individual sections for each tranactions
    - Shorter!

- Payment Instrument Customer Care (PICC)
    Concluded:
    - Transaction definition not fully developed
    - really more of a financial transaction doesn't involve in "trade"
    Therefore
    - Removed PICC transaction
    - Removed PICC role

Hitachi: putting a document together on how they will implelement PICC

- Packaged Content
    Indentified requirements for multiple Packaged Content
    - Support some Payment protocols, receipts for SET
    - to support encapsulation of HTML

- BrandID
    - confusion over brand names and distinguish
    Therefore:
    - changed the way payment brands are identified to more closely mirror
the approach adopted by SET
    - Payment brands are now: "SET:" or "IOTP:" followed by the SET brand
structure or IANA registered IOTP name space brands, respectively

Q: SET uses internal colons in it Brands, problem?
A: Andrew: No - uses whole SET name, not a problem.

Use of IETF/IANA as registry of names and identifiers:
    - BrandIDs
    - Trading Role
    - Methods of delivering data

Delivery Exchange
    - Delivery Response may now also be signed
    Rationale:
    - Consisteny
    - easy
    - implementators thought was good Idea

HTML Support
    - All v0.9 implementations have used HTML as packaged content,
        spec doesn't support it so decided to add it

Misc
    - Removed XML tutorial section
    - Net Locations - tidied up defs

Donald:
    - How to proceed
    - Working Group last call
    - Any objections for continuing that way?  None, so will proceed.

David:
    Created document called XML Messaging
    Could call something different, suggestions
    In a sense, tied into how IOTP might evolve in the future

Evolution of IOTP?
    This is how it could evolve:

DSIG to go to its own BOF, related to IOTP dsig
XML messaging make use of constructs in IOTP, could be a separate standard

Develop domain specific items after feedback from pilots of IOTP 1.0

Any questions? (None.)

XML Messaging
     - What might be in this spec?

Start off by looking in the overview.
    What do you do on the internet? Make a request, send a response.
    Very simple exchange of messages.

Some exchanges need to be more complex than that. More than one
interaction, both parties need to end in a consistent state.
1st party -> 2nd party. Swapping messages until necessary until get a
response back.

More general case in how IOTP is done, use this type of message to do a
delivery.

Multiple document exchange to combine multiple messages together, creating
transactions.

Example of doing purchase of a airline ticket. All these messages need to
be encapsulated inside of something.

What do people think?

- Audience: Absolutely, my company is trying to send encapsulated XML data
back and forth.

David:
    - This is an example of how we can combine things together

Lifted from the current IOTP spec the data elements which are used in
messaging

At start of IOTP, transaction reference block
A complete message would be all of that (pointing to transaction page)

Within each transaction block have a Signature block which is optional

The actual data can be anything

Lets look at a transaction and the signatures bit

Trans Ref Block: Consists of trans ID block, msg ID block
    The transID contains the ID for the element and a globally unique ID
for the whole transaction, plus a timestamp
    The msgID gives the ID of the software, the time created, and the
message id, unique for the message

Q: Can you link transactions?
A: Yes, RelatedTo option allows for linking of different transactions

Audience: Good example is authorization for credit card payment and
subsequent settlement

Signatures can sign any data, any message in the same transaction

If you've got 1 transaction here, this 3rd party could sign some data which
it would then receive. Provide the credentials of the signer to
authenticate through another party for a 3rd party. If that trust hierarchy
is there.

We then got into an example of how signatures would work. (Wish this could
be in color.)

Signature 1 could be used to authorize a service to start.
Sig 2 can authenticate completion of transaction, even if a failure state.
Sig 1 and 2 can get send to 3rd party who can then authenticate both, and
provide a complete audit trail of what is going on.

This is the way IOTP works right now.

Q: ... (can't hear)
A: any sort of 3 party exchange can be reduced to a series of 2 party
exchanges. No reason why the 1st party here...

Back to 1st example (flight example)

This 2nd party may be intermediary. Parallel inquiries on other airline
databases, no reason why you can't have other inquiries to other databases.

Did this answer your question?

Q: Does the 2nd party in this example keep state about the transaction?

A: Quite possible that the 2nd party and the 4th party are the same people.
They need to maintain state between the request and the response. The 1st
party (Consumer) needs to maintain state all the way through.

Errors
------
Receive errors - document received was wrong and here's why
May optionally apply to any data within a message

Error Block: 2 compoments
    - Description of the error
    - Textual desc
    - Where the error exists
Could be a fatal error, can specify severity
Generalized mechanism, got an error, here's why

Another thing inside IOTP is packaged content, may want to encapsulate data
within other docs. IOTP has a way of doing this...

Single Round Trip document exchange, or may have a more complex doc
exchange

Request, any number of Exchange messages, Response messages

Common requirements for document exchanges:
- Request Message
    - What you want to do, may use signatures, may depend on success of
previous exchanges
    - Who sent the message

Exchange Message
    - Optional
    - May contain data

Response Messages
    - What happened, status information indiciated success for failure
    - signatures to prove action happened

Response Message, Example
    In response message got data describing result. Depended on what data
you're swapping, what sevice you're trying to do
    It also needs some status information about business success of
failure, payment failed, funds not available. Technical failure is "XML is
not correct". Business failure is "XML is perfect, just can't do what you
want to do."
    May link signatures back to earlier signature. You can see how this
signature signed this signature up top.

This kind of thing you may have inside a response message, inside a request
message, which resulted in that as a response.

talked about how signatures can link requests across organizations or
across requests, slide 23

Q: (Handout is different than printed slides)
A: Mentioned that, minor error in two slides in handout has been fixed.

Status component
    - Report on the status of a particular service or response reference to
that data element which describes what you were going to do. The Status
component which is not shown here which should refer to a particular
element. Got a completion code which indicates the status of the process.
It is a useful way for defining this type of thing which may be extended.

Part 3:
Transaction Status Inquiry
    - Quite easy for one party to send to another party to get status of a
transaction.
    If transactions are broken down can restart a transaction.
    If you're waiting for goods to be delivered, waiting for them to be
shipped, can inquire as to the status of the shipping

Payment transaction

What we could do is take this specification and back to (slide 4) use these
for implmenetation, lift this out and create a new standard for exchanging
XML documents. How can we best take it forward.

Donald:

Favorable response to modularizing documents, whether it should be handled
in some other way, say, as a general way for doing this for a variety of
applications.

Core applications protocol BoF (APPLCORE), asking for drafts for this type
of thing. The mindset tere, however, was different than this so they may
not want to take it.

Q: For now the focus is to stay in the IOTP protocol? Is there any intent
of becoming generic XML messaging?

A: Donald: It was described in that fashion but it was designed part of the
trading protocol effort. There's virtue in layering, etc. Even if it's
never used outside of this protocol, it makes sense to keep it as a
separate, modular document.

Q: May apply in the OBI community
A: OBI is heading towards XML, should serve OBI quite well. Requirements
might be different, but messaging might fit in unmodified. OBI is another
organization. Any individuals may present this to OBI, and if I receive
requests from them I'm happy to speak with them.

Q: ApplCore, creating something general, cautious about calling it generic
when it has no experience outside of IOTP.
A: David: Talked with an individual who said they needed this for apps work
for XML

Q: Same as in dsig BOF, XML owned by W3C, should we be taking this on
A: IP was designed by IETF, not all applications using IP are within IETF,
not a great argument.

Q: David: Useful? Donald: Separate into a different document?
A: (Consensus in favor)

Audience: Useful to unclutter the current docuemnt.

Donald introduced:

Kent Davidson, Differential: Spoke about XML DSIG document
    Based on Richard Brown's digital signing document, which was going to
be originally part of IOTP.
    His document was very broad and had various aspects which did not apply
to IOTP, and so in a smaller meeting in Ft. Lauderdale we spoke
specifically about how to reduce his document into what we have today.
    Major changes were making Originator and Recipient information specific
to IOTP, instead of the generic representation in dsig, made the algorithm
specifications more reusable to keep the signature components of IOTP
small. Questions, or comments, speak with me.

HTTP Supplement:
    How to do IOTP over HTTP
    originally by Chris Smith
    not a high level
    suggest reading with critical eye
    HTTP expertise before last call

Architecture and Payment API
    - Example of how you might structure an implementation, how you might
have an interface to different payment systems, etc.
    - URL on slide is not valid for this, yet but it has been mailed to the
list and will be at the URL real soon now.  It's still a Microsoft World
document and has not yet been IETFized

Mailing list comments

SET Supplement
    To talk about how to interoperate with SET
    Andrew: Changes made on current API document. New version will be out
in a month or two.

SCCD Supplement
    Secure Channel Credit Debit
    early draft of that, JCP draft coming this week
    Use credit card info in SET structure to transmit the essential
information back and forth

No doc yet to use eCheck with IOTP
Wallet Detection item, described below, could use its own document, etc.

David: SCCD help?

Q: We interface with a ton of payment gateways, willing to take that on.
[Tom Arnold from CyberSource.]

Implementations
- SMILE: Hitachi, Fijitsu, NTT, etc.
    - Andrew Drapp
- Royal Bank of Canada
     - Chris Smith
- Differential
    - Kent Davidson
- CyberSource
    - Tom Arnold
- British Telecom (JCP, Ltd.)

Andrew Drapp: SMILE project
1) Standard Smart Card Interface for smart cards
- Consumers can use their cards everywhere
2) Trading protocol for multi-payment methods in Japan
- Based on IOTP 1.0
- Enhanced for Japanese specific options (Payment with Bonus Plan)

Q: David: Feed changes back through IOTP group
A: No, not initially.

Q: Donald: IOTP additions or SET additions?
A: SET already includes Japanese additions. Won't make it incompatible.

Settlement Support Center
- Standard IOTP Format
Consumer at home, visits Virtual mall, does IOTP with Settlement Center.

Settlement Center connetcs to banks, credit card, or electronic cash
issuer.

Retailer, pay in stores with these smart cards

Smart Card to purchase from Home, Retailer, Public Facility
Connect through internet to virtual malls.

Trial Systems Overview
    - Pay via IOTP, download

Project Schedule
    - Implementation this fall

Member Companies
    - VISA, MC Japan, UC Card, DC Card, JCB, Orient Corp., Hitachi Credit

Banks: Tokyo-Mitsubishi, Sanwa, Asahi, Daiichi Kangyo, Fuji, Association of
Regional Banks

Vendors: Hitachi, Fujitsu, NTT, Oki

Content Providers: DNP, PA

Sponsored by MITI (Ministry of International Trade and Industry)

Donald: Wallet Detection

Most browser don't tell you it accepts a type in the header, just pass in
*/*, really have to use JavaScript or ActiveX.

Kent: We've actually solved this problem, have to detect browser type, and
solved the problem for both browser types.

Donald: Ok, if this is or is not a problem, make sense to create a document
which outlines how to do this, and it will be applicable for
application/iotp as it will for any other MIME type.

Miscellaneous:

X9.59 - Secure Object for account based payment protocols. Not a payment
system. Objects which are signatures over data elements. Request whether
someone has access to that account. Since we have a mechanism which is
payment system independent. Less practical in the short run, the banks need
to support it.

Easier to send along with a X9.59 object the credit card info which it
secures.

No one volunteer to do any work or further investigation in this area.

Updating the Working Group Charter
- "v2" Schedule

Nothing specific, people should be thinking about that.
May end up updating it before next IETF meeting.

Current Charter on www.ietf.org

Lastly:

Future Meetings: July IETF, Oslo, Norway.

No additional working group meetings anticipated in the short term.
Schedule meeting at next IETF in Oslo, Norway.

Meeting terminated 1999, March 17, 14:35

_____________________________
Kent M. Davidson
Vice President of Engineering
Differential, Inc.
direct (408)864-0604
fax    (408)864-0601
mailto:[email-masked]
http://www.differential.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]