NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99
Chair(s):
Donald Eastlake 3rd <dee3@torque.pothole.com>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>
Applications Area Advisor:
Patrik Faltstrom <paf@swip.net>
Editor(s):
Surendra Reddy <skreddy@us.oracle.com>
Mailing Lists:
General Discussion:ietf-trade@lists.eListX.com
To Subscribe: ietf-trade-request@lists.eListX.com
In Body: (un)subscribe
Archive: http://www.eListX.com/archives/ietf-trade
Description of Working Group:
The Internet Open Trading Protocol provides an interoperable framework for Internet commerce. It is optimized for the case where the buyer and the merchant do not have a prior acquaintance and is payment system independent. It will be able to encapsulate and support payment systems such as SET, Mondex, CyberCash's CyberCoin, DigiCash's e-cash, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, the payment handler, the deliverer of goods or services, and the provider of customer support are performed by different Internet sites.
The Internet Open Trading Protocol (IOTP) working group will (1) determine requirements and document scenarios for IOTP message transport and for IOTP version 2 specification, (2) document interoperability experience with IOTP version 1 (which will have been published as Informational), and (3) develop the specification for IOTP transport and IOTP version 2.
Selection of items for inclusion in version 2 is expected to be from the following and others suggested by the Working Group:
- Dynamic Definition of Trading Sequences - Multiple Protocol Options - Offer Request Block - Public Key Signatures (v1.0 uses secret key signatures) - Signatures on the Delivery Response - Improved Problem Resolution (extend to cover presentation of signed receipt to customer support party, etc.) - Selection of Additional Options - OTP Architecture (informational development of standard interfaces to software components).
The following are out of scope for version 2:
- server to server messages (except as messages needed for client to server communications may also be useful for server to server communications) - legal or regulatory issues surrounding the implementation of the protocol or information systems using it.
Goals and Milestones:
Jul 98 |
|
Submit IOTP v1.0 to the IESG to consider publication as an Informational RFC. |
Oct 98 |
|
Submit Internet-Draft of Open Trading Protocol requirements and scenarios |
Oct 98 |
|
Submit IOTP transport requirements Internet Draft |
Dec 98 |
|
Submit Internet-Draft on IOTP v1.0 interoperability experience |
Jan 99 |
|
Submit Internet-Draft on IOTP transport requirements to IESG for publication as an Informational RFC. |
Jan 99 |
|
Submit Internet-Draft on IOTP v1.0 interoperability experience to IESG for publication as an Informational RFC. |
Feb 99 |
|
Submit Internet-Draft of IOTP v2.0 specification |
Feb 99 |
|
Submit Internet-Draft of IOTP transport specification |
May 99 |
|
Submit IOTP transport specification I-D to IESG for consideration as a Proposed Standard. |
Jun 99 |
|
Submit IOTP v2.0 specification I-D to IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· Internet Open Trading Protocol - IOTP Version 1.0
· Internet Open Trading Protocol (IOTP) HTTP Supplement
· Digest Values for DOM (DOMHASH)
No Request For Comments
IETF 46, TRADE Working Group Minutes
Notes taken by Maryann Hondo, edited by Donald Eastlake
Chair, Donald Eastlake
[See TRADE Working Group Agenda Slides]
planned agenda
- status of main documents
- implementation news
- digital rights
- Supporting Contracts (Eric Brunner wished to speak but was unable to attend due to illness.)
- XML Messaging (Dave Burdett unable to attend.)
- charter update
A summary of the ECML BOF was given along with the slides presented there [see minutes for the ECML BOF]. The ECML BOF concluded that ECML was an appropriate work item for the TRADE working group
Status of documents:
The main three are ready for publishing as RFCs and are through last call. ((They have since been approved by the IESG as Informational and are in the RFC Editor's queue.))
The Hiroshi Maruyama DOMHASH document
Very few comments have been received. It provides canonicalization and hashing together. It will be replaced by the XMLDSIG standard when it comes out.
IOTP digital signature draft
Only one minor change needed and revised version has been created.
main protocol document
Needs the same minor change as the IOTP digital signature draft plus one other minor change and some clarification to the text.
<<comment that the documents may not need new revision numbersare further along than might have been thought the rfc editor might be able to just fix these>>
main protocol document
[See Dave Burdett changes05to07.ppt slides]
Minor changes between 5 & 6. Version 6 was Last Called.
Even smaller changes in Version 6 to 7 as follows:
question of what IOTP XML namespace should be...
question of id prefix letter on inquiry,
currently to specify prefix letter q
question on transaction equality test,
only test transaction id and timestamp
no change to protocol structure or flow
other document status:
http transport document
Not much activity, more feedback is needed.
how can a merchant tell if a consumer has something that supports IOTP? ECML may be helpful.
Check for a mime type? There is a draft of how to do this.
Architecture & payment API document is almost in an internet draft form....need finish converting to draft and get it out.
SET supplement (how to use with IOTP)
Less conversion to internet-draft so far, still has line drawn figures
SCCD, simple way to use credit cards with IOTP, without SET
Somewhat broader in scope than just IOTP, which only needs consumer to merchant. This document also contains merchant acquirer aspects.
Implementation news...
Hitachi is working on several implementations:
domestic:
- SMILE coding is moving forward, trial in March or April.
international:
- Taiwan, Costa Rica
- Use a slightly older version of the specification.
- Other known implementation plans include
- Royal Bank of Canada
- JOTP: posted on the web...a java library for IOTP.
Ko Fujimora:
- Digital Rights Trading Infrastructure(DRTI) [ietf46-DRTI.ppt slides]
- The DRTI is a proposed new work item.
- Background objectives include mechanisms to create coupons and credit loyalty points.
Donald Eastlake: I suggest we should start with a requirements document before moving to a draft specification on the Digital Rights language
Charter update:
The Working Group Charter is out of date: the main documents are complete, the supplemental documents need new milestones. There is the possible addition of xml messaging as a task (ie, take content independent part of IOTP and make it a separate document), digital rights, and ECML v2.
All the slides presented here will be in the proceedings and on Donald's web site
<< question on whether version 2 which is the goal of the original charter, will be delayed because of these new requirements >>
Donald asserted that version 2 is only delayed because people need more experience with deployment and interoperability on version 1.
<< does XML messaging include discovery of DTDs? >> no
<< does IOTP have its own DTD? >> probably
XML and cookie analogy....
<< wedge green....there are two ASN1 deployments, cartography database and the library system, that have been converted to XML. >>
Tony Lewis, VISA: WG bandwidth question....does this working group have the bandwidth to pickup ECML?
WG consensus that it does have the bandwidth.
Working Group support voiced for at least doing the digital rights requirement here and then decide where detailed design lives.
<< questions on what is it meant to be integrated with privacy? >>
Things like the W3C P3P protocol.
<< would support of ECML dilute the IOTP, since it is weaker than IOTP? >>
ECML looks like it will be widely deployed sooner, could be a bridge or lead in to IOTP.....The MS passport Wallet uses ECML....
TRADE Working Group Agenda
Internet Open Trading Protocol Changes "05" TO "07"
TRADE WG New Charter
Digital-Right Trading Infrastructure (DRTI)