idnits 2.17.1 draft-hallam-micropayment-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 28 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 65 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. ** The abstract seems to contain references ([PayWords], [Manasse95], [Rabin79], [RivestSh95], [Collection], [EvenGoMi90], [Vendor], [ChainFlag], [Shamir95], [Haler94], [AccountData], [Octet], [RivestShAd78], [Hallam-Baker95a], [Hallam-Baker95b], [ElGamal85], [Attribute], [AccountFlags], [Lamport81], [Customer], [Revocation], [BrokerServer], [ReissueCertificateData], [AccreditedSC93a], [Hallam-Baker95], [Schneier96], [Broker], [AuthorityData], [SteinStBoRo94], [BellareEt95], [ChainResponse], [DeleteAccount], [Any], [ElGamal95], [Rivest92c], [PayChain], [NIST91]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 15 has weird spacing: '...raft as http:...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RivestSh95' on line 1410 looks like a reference -- Missing reference section? 'Manasse95' on line 1391 looks like a reference -- Missing reference section? 'BellareEt95' on line 1353 looks like a reference -- Missing reference section? 'SteinStBoRo94' on line 1429 looks like a reference -- Missing reference section? 'Lamport81' on line 1387 looks like a reference -- Missing reference section? 'Haler94' on line 1370 looks like a reference -- Missing reference section? 'Rivest92c' on line 1406 looks like a reference -- Missing reference section? 'AccreditedSC93a' on line 1349 looks like a reference -- Missing reference section? 'Schneier96' on line 1419 looks like a reference -- Missing reference section? 'EvenGoMi90' on line 1365 looks like a reference -- Missing reference section? 'NIST91' on line 1394 looks like a reference -- Missing reference section? 'ElGamal95' on line 497 looks like a reference -- Missing reference section? 'Shamir95' on line 1423 looks like a reference -- Missing reference section? 'Rabin79' on line 1401 looks like a reference -- Missing reference section? 'Octet' on line 911 looks like a reference -- Missing reference section? 'Any' on line 766 looks like a reference -- Missing reference section? 'ReissueCertificateData' on line 818 looks like a reference -- Missing reference section? 'DeleteAccount' on line 828 looks like a reference -- Missing reference section? 'AccountData' on line 840 looks like a reference -- Missing reference section? 'AccountFlags' on line 844 looks like a reference -- Missing reference section? 'BrokerServer' on line 846 looks like a reference -- Missing reference section? 'Attribute' on line 847 looks like a reference -- Missing reference section? 'AuthorityData' on line 874 looks like a reference -- Missing reference section? 'PayChain' on line 883 looks like a reference -- Missing reference section? 'ChainFlag' on line 888 looks like a reference -- Missing reference section? 'PayWords' on line 907 looks like a reference -- Missing reference section? 'Collection' on line 929 looks like a reference -- Missing reference section? 'ChainResponse' on line 944 looks like a reference -- Missing reference section? 'Revocation' on line 974 looks like a reference -- Missing reference section? 'Customer' on line 1072 looks like a reference -- Missing reference section? 'Vendor' on line 1083 looks like a reference -- Missing reference section? 'Broker' on line 1049 looks like a reference -- Missing reference section? 'Hallam-Baker95a' on line 1381 looks like a reference -- Missing reference section? 'ElGamal85' on line 1360 looks like a reference -- Missing reference section? 'Hallam-Baker95' on line 1377 looks like a reference -- Missing reference section? 'Hallam-Baker95b' on line 1384 looks like a reference -- Missing reference section? 'RivestShAd78' on line 1414 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 39 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Micro Payment Transfer Protocol (MPTP) Version 1.0 3 INTERNET DRAFT Phillip M. Hallam-Baker 4 November 22nd 1995 World Wide Web Consortium 5 Expires May 27th 1996 email: 7 Micro Payment Transfer Protocol (MPTP) Version 0.1 8 10 Status of this Memo 12 This draft, filename draft-hallam-baker-internet-micropayment-00.txt 13 is intended to be become one or more Proposed Standard RFCs. It is 14 also available as hypertext as a World Wide Web Consortium Working 15 Draft as http://www.w3.org/pub/WWW/TR/WD-mptp951122.html. 16 Distribution of this document is unlimited. Comments should be sent 17 to the author . 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet- Drafts as 27 reference material or to cite them other than as ``work in 28 progress.'' 30 To learn the current status of any Internet-Draft, please check the 31 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 32 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 33 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 34 ftp.isi.edu (US West Coast). 36 Micro Payment Transfer Protocol (MPTP) Version 1.0 38 Abstract 40 A protocol for transfer of payments through the services of a common 41 broker is described. The processing demands of the protocol make it 42 practical for small payment amounts. The latency makes it practical 43 for use in interactive applications. The scheme thus satisfies the 44 two key criteria for a micropayments scheme. MPTP implements a 45 variation of the Pay-Word proposal of Rivest and Shamir 46 [RivestSh95]. It is also inspired by the Millicent proposal by 47 Manasse [Manasse95] and the iKP proposal by Bellare et. al. 48 [BellareEt95]. A proposal similar to the PayWord scheme by Torben 49 Pedersen [Pedersen9?] was reported after this draft was begun. 51 For efficiency it is desirable to be able to combine transfer of 52 payments instructions with those accomplishing the delivery of 53 goods. For this reason MPTP may be layered on a variety of Internet 54 protocols including HTTP and SMTP/MIME. 56 Although the protocol is optimized for use as a payment scheme it is 57 suitable for the transfer of larger amounts. The protocol is also 58 suitable for use as an access control or resource allocation 59 mechanism. With modification the protocol could be made to provide 60 anonymity guarantees. 62 Micro Payment Transfer Protocol (MPTP) Version 1.0 64 Contents 66 * Introduction ...................................................... 5 68 o Principles and Parties ........................................ 6 70 o Risk Model .................................................... 7 72 o Policy ........................................................ 8 74 o Mechanism ..................................................... 9 76 o Signature .................................................... 10 78 o Certificates and establishment of trust. ..................... 11 80 o Distributed Implementation ................................... 12 82 o Risk Control ................................................. 12 84 - Credit Liability ......................................... 12 86 - Credit Abuse ............................................. 13 88 - Counterfeiting ........................................... 13 90 - Unauthorized Withdrawal .................................. 13 92 - Purchase Order Modification .............................. 13 94 - Double Spending .......................................... 13 96 - Failure to Credit Payment ................................ 14 98 - Denial of Service ........................................ 14 100 - Repudiation .............................................. 14 102 - Failure to deliver ....................................... 14 104 - Framing .................................................. 14 106 * Message Formats .................................................. 15 108 o Account Establishment and Maintenance ........................ 15 110 - Create Account ........................................... 16 112 - Reissue Certificate ...................................... 16 114 - Delete Account ........................................... 16 116 - Account Certificate ...................................... 17 118 Micro Payment Transfer Protocol (MPTP) Version 1.0 120 o Payment Dataflow ............................................. 17 122 - Authority ................................................ 17 124 - Charge ................................................... 18 126 o Vendor-Broker Communications 128 - Collection Request ....................................... 18 130 - Collection Response ...................................... 19 132 - Validation Request ....................................... 19 134 - Validation Response ...................................... 19 136 - Revocation List .......................................... 19 138 * Processing of Data Flows ......................................... 19 140 o Account Creation ............................................. 20 142 o Account Modification, Enquiry, Deletion ...................... 20 144 o Payment Flow ................................................. 20 146 o Collection Flow .............................................. 22 148 * Resource and Performance Analysis ................................ 22 150 o Latency ...................................................... 22 152 - Establishment of Payments Session ........................ 22 154 - Subsequent Payments ...................................... 22 156 o Processing ................................................... 22 158 - Customer ................................................. 22 160 - Vendor ................................................... 23 162 - Broker ................................................... 23 164 o Storage ...................................................... 23 166 - Customer ................................................. 23 168 - Vendor ................................................... 23 170 - Broker ................................................... 24 172 * Commentary and Further Work ...................................... 24 174 Micro Payment Transfer Protocol (MPTP) Version 1.0 176 o Benchmarks and statistics .................................... 24 178 o Risk factors ................................................. 24 180 o Inter-Broker Settlement Model ................................ 25 182 o Wider Applications ........................................... 26 184 * Security Considerations .......................................... 26 186 * Patent Rights .................................................... 26 188 * References. ...................................................... 26 190 * Acknowledgements ................................................. 28 192 * Contact .......................................................... 28 194 * To Do List ....................................................... 28 196 Introduction 198 Commerce on the Internet may be broadly divided into three 199 categories, advertising, sale of tangible goods and sale of 200 non-tangible goods. Advertising is not directly considered in this 201 paper. Movement of tangible goods requires handling and shipping 202 whose costs set a minimum value for which trading is economic and 203 introduces a substantial delay into the process. Speed and cost of 204 processing are thus not the critical factors in evaluating payment 205 systems for this application. Where non-tangible goods are involved 206 the contract may in many cases be fulfilled through the internet. 208 There is a large interest in payment systems which support charging 209 relatively small amounts for a unit of information. Here the speed 210 and cost of processing payments are critical factors in assessing a 211 schemes usability. Fast user response is essential if the user is to 212 be encouraged to make a large number of purchases. Processing and 213 storage requirements placed on brokers and vendors must be economic 214 for low value transactions. MPTP is optimized for use for low value 215 transfers between parties who have a relationship over a period of 216 time. It also provides a high degree of protection against fraud 217 making it applicable in wider scenarios, including sale of tangible 218 goods. 220 The following performance statistics were used as a guide in 221 designing the protocol [RivestSh95]. Current workstation and high 222 end personal computer class machines are capable of approximately 223 two public key signature creation operations, two hundred public key 224 verification operations and 20,000 one way hash functions per 225 second. Latency introduced by round trip communications may be a 226 second or more, the time taken for a signal to be relayed by a 227 satellite in geostationary orbit. Communications also introduce 228 potential unreliability. 230 Micro Payment Transfer Protocol (MPTP) Version 1.0 232 A distinction is made between the cost of inline and offline 233 processing. Inline processing takes place on the critical path for 234 payments. Servers must thus have substantial excess capacity to deal 235 with fluctuation in demand. Offline processing may be performed 236 asynchronously when processing load permits. As a rough estimate 237 inline processing was considered to incur two orders of magnitude 238 more cost than offline processing. 240 In addition to processing costs, the cost of online storage must be 241 borne in mind. If online storage must be accessed during a payment 242 transfer the cost of storing the data in RAM or of disk head 243 contention must be considered. 245 MPTP is an asynchronous protocol. Much of the processing required 246 may be done offline. In particular payment does not require an 247 online communication with the broker (unless the symmetric signature 248 option is used). MPTP is also symmetric, there is no distinction 249 between customer and vendor accounts except in relation to specific 250 transactions where the flow of payment is generally in a single 251 direction. The ability to make payments need not preclude the 252 ability to accept payments unless this is a matter of broker policy. 253 However in some cases it might be desirable to have different 254 accounts for these functions, a vendor accepting large payments 255 might wish to avoid the danger of a security compromise allowing 256 unauthorized payments to be made via the Internet accept only 257 account. 259 One of the most significant differences between the World Wide Web 260 and print media is that the cost of publishing on the Web is 261 commensurate with the cost of readership and does not involve a high 262 capital outlay. Many of the initial users of the Web were primarily 263 interested in publishing existing information, both within 264 organizations and to the wider internet community. One important 265 characteristic which a Web micropayment scheme must satisfy is that 266 it permit access to commercial publication to both small and large 267 publishers. MPTP provides for transfer of small payment amounts 268 through vendor amortization. Use of public key signature screening 269 as opposed to verification makes it economic for use by small 270 publishers. 272 Principles and Parties 274 MPTP involves three parties, a customer _C_ who makes the payment, a 275 vendor _V_ who receives the payment and a broker _B_ who keeps 276 accounts for the parties concerned. At present only a single broker 277 model is considered, this means that both customer and vendor must 278 share the same broker. Note however that the protocol does not 279 restrict the broker to use of a single server. 281 Such a capability is essential if customers are to be able to surf 282 the Web using a single payment account and vendors are to be able to 283 accept payments from any source through a single account. Although 284 accounts are in principle being used by both customers and vendors 286 Micro Payment Transfer Protocol (MPTP) Version 1.0 288 it is likely that brokers will wish to specialize in particular 289 types of account. ISPs for example have an existing client base 290 which is billed on a regular basis. Issuing bills requires a very 291 different type of procedure to issuing payments however and thus 292 vendor support may require the services of a specialist broker. 293 Support for Inter-Broker transfers will be required in the long term 294 to permit the system to be scaled effectively. Some notes on the 295 technical and political difficulties involved are made in the 296 commentary section at the end. 298 It is important that a payment protocol does not interfere with the 299 established trust relationships between the parties. Where a 300 protocol allows collection of data on another parties activity this 301 should be made clear in advance. It is not a requirement that the 302 protocol duplicate the trust models of a particular financial 303 instrument precisely. It is more important that the protocol provide 304 flexibility in the establishment of trust relationships than attempt 305 to define which party accepts what risk. 307 The term Broker is used to refer to a financial intermediary. In the 308 context of this proposal a broker might be any organization with the 309 ability to bill a significant number of customers at a small 310 marginal cost. This means that in addition to use by financial 311 institutions MPTP might be suitable for use by Internet Service 312 Providers (ISPs), telephone companies or any other organization 313 sending out large numbers of invoices. 315 Risk Model 317 [The risk model will be developed in depth in a companion paper. It 318 is intended that the risk model be comprehensive, permitting cross 319 comparisons between different types of schemes to be made.] 321 The main risks faced by the customer are liability for unauthorized 322 payment and either not receiving the goods at all or receiving goods 323 different from those advertised. The vendor risks not being paid. 324 The broker risks the cost of customer service due to malfunction or 325 incompatibilities and liability for payments in cases where the 326 customer and vendor are in dispute. 328 The following risks were considered: 330 Credit Abuse 331 An account is used to make repeated payments without intention 332 to pay. 334 Counterfeiting 335 A fake payment order is constructed. 337 Unauthorized Withdrawal 338 The broker (or an employee) makes an unauthorized withdrawal 340 Micro Payment Transfer Protocol (MPTP) Version 1.0 342 from an account. 344 Purchase order modification. 345 A customer issues a payment order intending to purchase one set 346 of goods but the order is intercepted and modified by a third 347 party. 349 Failure to Credit Payment 350 The broker debits the customer account but does not credit the 351 vendor account. 353 Double Spending 354 A payment instruction is used twice, either by a customer, a 355 vendor or a third party. 357 Denial of Service 358 A customer or vendor is denied use of their account. 360 Repudiation 361 A party may deny making a payment. 363 Credit liability 364 Where a customer is extended credit liability must be 365 controlled. 367 Failure to Deliver 368 A vendor may accept payment but fail to supply the advertised 369 goods. 371 Framing 372 A party is able to convince another that a third party acted in 373 bad faith. 375 In many cases it is in the interests of a party to accept risk. 376 A broker may offer to guarantee payments to vendors irrespective 377 of whether the customer pays and require a payment of a higher 378 commission in return. The high cost of customer service 379 enquiries must be borne in mind. Protocols which cannot clearly 380 identify which party was at fault are likely to incur 381 substantial customer service costs. 383 Policy 385 The interests of the parties may conflict. In such cases the choice 386 of which parties interest will be prioritized is a matter of policy. 387 MPTP is designed to be policy neutral, permitting a broker to offer 388 a wide number of policy options. Individual vendors may thus choose 389 the precise terms on which they offer goods. Customers may choose 390 the terms they are willing to accept on a vendor by vendor basis 392 One of the areas in which conflict of interest occurs is whether 393 goods are to be delivered before or after payment. It is in the 394 customers interest to withhold payment until the goods are delivered 396 Micro Payment Transfer Protocol (MPTP) Version 1.0 398 to ensure that they are satisfactory. The Vendor may wish to 399 ensuring payment is made by insisting of payment in advance however. 401 As previously noted it may be in the interest of the vendor to 402 encourage customers to purchase goods by accepting a degree of risk. 403 This is particularly important when the vendor has no established 404 reputation with the customer. This risk may be made acceptable to 405 the vendor provided there is a high enough probability that payment 406 will be made. In the green-commerce model [SteinStBoRo94] the broker 407 acts to encourage this by monitoring the number of refusals made by 408 a customer and excluding customers with a bad track record. 410 MPTP permits a considerable degree of flexibility in establishing a 411 payments policy. A vendor may permit a customer a certain amount of 412 trade before requiring a firm payment commitment or require all 413 purchases to be paid for in advance. The first policy may be 414 applicable where the goods offered cannot be evaluated by the 415 customer in advance. A Vendor who has established a reputation with 416 the customer may be in a position to insist on prior payment. 418 As an example consider the vendor of a software program who wishes 419 to charge for its use on an hourly basis. The vendor may be willing 420 to offer a customer a free trial provided there is a guarantee that 421 the customer cannot simply request a fresh retrial each time a trial 422 expires. 424 Mechanism 426 In the Pay Word scheme a payment order consists of two parts, a 427 digitally signed payment authority and a separate payment token 428 which determines the amount. A chained hash function,is used to 429 authenticate the token. These are described by Lamport [Lamport81] 430 and employed in the S/Key [Haler94] authorization mechanism. To 431 create the payment authority the customer first chooses a value _w_n 432 _at random. The customer then calculates a chain of payment tokens 433 (or _paychain_) _w_0, w_1, ... w_n _ by computing 435 _w_i = h (w_i+1)_ 437 Where h is a cryptographically secure one way has function such as 438 MD5 [Rivest92c] or SHA [AccreditedSC93a]. 440 The signed payment authority contains _w_0_, the root of the payment 441 chain and defines a value for each link in the chain. Payments are 442 made by revealing successive paychain tokens. Once the vendor or 443 broker has authenticated a payment authority an arbitrary payment 444 token may be authenticated by performing successive hash functions 445 and comparing against the root value. It should be noted however 446 that the broker is only presented with the final payment order. It 447 is therefore unnecessary for the broker to maintain large online 448 databases. 450 MPTP permits use of double payment chains. This allows 452 Micro Payment Transfer Protocol (MPTP) Version 1.0 454 implementation of a broker mediated satisfaction guarantee scheme. 455 The pair of payment chains represent the high and low watermarks for 456 the payment order. The low watermark chain represents the amount 457 that the customer has fully committed to pay. The high watermark 458 chain represents partial commitments. The vendor exposure is the 459 difference between the counter values. 461 MPTP also supports use of multiple payment counters denoting 462 different units of currency. This allows some optimization of 463 processing time through shortening of the payment chains. 465 MPTP provides protection against double spending through vendor and 466 broker checking of authority identifiers. The size of required 467 Vendor authority identifier matching tables (th _double spending 468 buffer_may be controlled by checking that the authority timestamp is 469 within bounds. An alternative approach would incorporate 470 challenge/response sequence into the session establishment protocol. 471 This could be used to simplify broker double spending prevention 472 measures if constraints were placed on the challenge identifiers. 473 The reduction in vendor resource requirements do not appear to 474 justify an additional round trip delay however. 476 The mechanism could be modified to use a collection of payment 477 tokens as opposed to a chain. Each token would consist of a the hash 478 of a shared secret which would be revealed to make a payment. This 479 might provide a solution to possible patent difficulties concerning 480 the use of the Lamport hash chain mechanism. It would also permit 481 payments to take place in parallel. 483 Signature 485 MPTP permits use of both shared secret and public key based 486 signature schemes. Schneier [Schneier96] describes a wide variety of 487 public key signatures schemes and one way hash functions suitable 488 for constructing Message Authentication Codes (_MACs_). Choice of 489 algorithm, key length etc. is left to the parties involved. It is 490 desirable to minimize the latency introduced in the signing of the 491 initial payment order and also to minimize computational needs of 492 the vendor and broker. 494 A number of digital signature techniques permit some calculations to 495 be performed offline, i.e. in advance of the message being known 496 [EvenGoMi90]. Such schemes include the Digital Signature Standard 497 [NIST91] and El-Gamal [ElGamal95]. Pre-calculation permits the time 498 taken to generate a signature to be performed outside the human 499 interaction loop and thus appear transparent to the user. Note 500 however that many MPTP applications may chose to perform speculative 501 calculation of an authority in advance of user instructions, unused 502 calculations would simply be discarded. Note however that use of 503 this technique might negatively interact with techniques intended to 504 prevent double spending since a user might delay sending the 505 authority for a significant time. 507 Micro Payment Transfer Protocol (MPTP) Version 1.0 509 A recent proposal by Shamir [Shamir95] permits signatures to be 510 validated very rapidly, although at the cost of introducing a small 511 risk that an invalid signature will be accepted. Shamir describes a 512 variation of the Rabin [Rabin79] signature scheme which permits 513 signatures to be "screened" using a test which will detect a 514 fraudulent signature half the time and never reject a valid one. The 515 scheme may be applied repeatedly to provide the desired degree of 516 assurance as to the authenticity of the result. 518 The signature screening approach has a number of characteristics 519 which are particularly suitable for micropayment schemes. The degree 520 of assurance may be adjusted to reflect the level of risk. Small 521 payments might be accepted with only minimal checking and additional 522 checks performed as the risk increased. another useful property is 523 that the level of protection may be adjusted to reflect server load. 524 This is especially important since it substantially reduces the 525 excess server capacity required to cope with peaks in demand and 526 allows unexpected increases in demand to be dealt with in an orderly 527 manner. 529 A final signature option is to used a shared secret and keyed 530 digest. This requires the customer and broker to establish a shared 531 secret and for the broker to provide an online verification service. 532 Use of shared secret authentication permits rapid generation of 533 payment authorities. Validation of such authorities requires 534 communication between vendor and broker which may incur a delay. 536 Certificates and establishment of trust. 538 Certificates bind a public key to an account number under the public 539 key of the broker. It is assumed that the broker public key is known 540 to all parties. Implementations might require broker public keys to 541 be verified through some additional means. 543 Each party generates their own public-private key pair locally. The 544 public key certificate is communicated to the broker at account 545 establishment. 547 The certificate issuance policy may require frequent re-issuance of 548 certificates to enable close control of credit risks or permit 549 certificates to be valid for longer periods of time. It is not 550 necessary for a re-issued certificate to establish a new public key. 552 Account revocation lists are supported to enable credit risks to be 553 prevented from engaging in further abuse. Separate certificate 554 revocation lists are not supported since compromise of public key 555 certificates may be dealt with through the same mechanism. 557 Where an account has special attributes concerned with risk 558 management these attributes should be included in and authenticated 559 by the certificate. For example an account might be limited to 560 making payment orders for no more than a certain amount. A broker 561 might chose to guarantee payments up to a certain amount but require 563 Micro Payment Transfer Protocol (MPTP) Version 1.0 565 an authorization to guarantee payments for larger amounts. 566 Alternatively a broker might require a vendor to accept the risk 567 regardless of amount and authorization. The following certificate 568 attributes are supported: 570 IP-Address _mask_, _value_ 571 Specifies a set of internet addresses for which the certificate 572 is valid. Only payment requests originating from IP addresses 573 which equal the specified value after being logically ANDed with 574 the mask. If more than one IP-Address attribute is specified a 575 single match is sufficient. 577 Not Guaranteed _amount_ 578 The broker will not guarantee that payment will be made for 579 amounts exceeding the specified amount. 581 Guaranteed _amount_ 582 The broker guarantees payment up to the specified amount without 583 separate authorization. 585 Authorization-Required _amount_ 586 Payments above the specified amount require separate 587 authorization to be guaranteed. 589 Distributed Implementation 591 The offline nature of PayWord lends itself well to a fully 592 distributed solution. It is not necessary for the Broker to use a 593 single server for all customers. 595 Online verification of credit-worthiness (e.g. in the symmetric 596 signature scheme) requires a vendor to have access to a server which 597 holds the authentication information. This information may be 598 encoded in the account certificate. 600 Risk Control 602 Having described the risk model and mechanism of MPTP we describe 603 the manner in which risk may be controlled. 605 Credit Liability 607 If a broker chooses to act as guarantor for a payment a credit 608 liability risk may be incurred. Note that MPTP supports an option 609 for the broker to transfer this risk to the vendor by refusing a 610 guarantee of payment. 612 In either case a credit liability is incurred. Such liabilities are 613 a familiar consideration in the financial industry. A similar risk 614 is accepted in parts of the publishing industry where newspapers are 615 sold from unattended vending machines which cannot control the 616 number of copies taken by each customer. In certain countries no 617 precautions are taken to prevent a copy being taken without any 619 Micro Payment Transfer Protocol (MPTP) Version 1.0 621 payment at all. 623 Credit Abuse 625 The problem of credit abuse is linked to but distinct from that of 626 credit liability risks. For example an account might be created in a 627 false name and its authentication information widely published with 628 the intention of permitting general access to charged material for 629 free. 631 Credit abuse might be discovered through broker tracing of payment 632 patterns to detect sudden increases in payment activity and then 633 terminated through the revocation list mechanism. The case of 634 widespread use of a single connection may be controlled through 635 checking of the certificate IP-Address attribute if specified. If no 636 IP address attribute is specified a vendor might employ code to 637 detect accesses from multiple IP addresses within a suspiciously 638 short interval. 640 Counterfeiting 642 MPTP payment orders are vendor specific and digitally signed. 643 Provided the signature scheme is secure it is not possible for a 644 party to construct a payment order without having access to the 645 secret information corresponding to the key. 647 Unauthorized Withdrawal 649 Unauthorized withdrawal is not possible without detection by the 650 account holder who may require an audit trail from the broker for 651 each transaction. Note that this requires the broker to maintain a 652 substantial quantity of online logging information. 654 Purchase Order Modification 656 In a purchase order modification attack an external party modifies a 657 purchase request in order to cause different goods to be delivered. 658 This risk is not directly addressed in the MPTP scheme although the 659 satisfaction guaranteed policy might be used to protect the 660 customer. 662 Without authentication of the purchase order there is no method of 663 avoiding this attack. The cost of this authentication might be 664 reduced by establishing a shared key between vendor and customer 665 during the session establishment protocol. Such shared keys might 666 have a lifetime spanning several payment orders. 668 Double Spending 670 Payment orders are specific to a particular vendor and carry a 671 unique authority identifier. A broker is required to detect an 672 attempt to deposit the same payment order more than once and act 673 accordingly. In some cases this may mean increasing the amount of 675 Micro Payment Transfer Protocol (MPTP) Version 1.0 677 payment authorized. 679 Failure to Credit Payment 681 Currently MPTP does not address this risk. A Broker may deliberately 682 deduct a payment amount from the account of one party without making 683 a corresponding credit to another party. 685 One approach to this problem is to make information concerning bad 686 debts available for scrutiny. A broker might be required to issue a 687 frequent list of bad debts signed under the broker's public key. 688 Such debts might be rendered unlinkable through a use of a one way 689 hash function on the authority identifier. The proportion of bad 690 debts might be concealed through addition of padding. In this way 691 both customer and vendor could ensure that the broker acted in good 692 faith. 694 Denial of Service 696 Denial of service is a significant risk, unfortunately it is one 697 that the underlying infrastructure of the Internet does not protect 698 against. Consequently any application protocol level protection 699 against a denial of service attack can at best provide limited 700 protection against this risk. 702 Use of Shamir's signature screening algorithm substantially reduces 703 the risk of a denial of service attack against a vendor or broker 704 through construction of bogus payment orders. 706 Repudiation 708 MPTP payment orders are non-repudiable in the sense that the 709 customer cannot deny having made a payment authorization. This is 710 distinct from the option for a vendor or broker to permit a customer 711 the right to refuse payment after receiving the goods. 713 Failure to deliver 715 Failure to deliver may occur for many reasons including vendor 716 fraud. The Internet is an unreliable transport medium and a customer 717 may in good faith offer to buy an article and a vendor in good faith 718 may intend to supply but delivery fail nevertheless. The HTTP 719 protocol in particular does not currently provide for customer 720 acknowledgment of receipt. 722 One solution to the failure to deliver risk is to permit the 723 customer to refuse payment through the "satisfaction guaranteed" 724 policy described earlier. 726 Framing 728 The vendor has the opportunity to frame a customer, albeit at a 729 direct monetary loss to himself. In this scenario a vendor receives 731 Micro Payment Transfer Protocol (MPTP) Version 1.0 733 a valid payment chain from a customer but chooses not to deliver the 734 authorization paychain token, instead delivering only the promissory 735 paychain token. The vendor is thus able to frame the customer, 736 albeit at the cost of the payment. 738 This risk is not currently addressed in MPTP. One approach to 739 addressing this risk would be for the customer to opt to make the 740 payment during account reconciliation. 742 Message Formats 744 In this draft we describe the message content without entering into 745 consideration of the corresponding byte streams. We assume that a 746 systematic encoding of these message formats is employed such as the 747 Basic Encoding Rules ASN.1. Choice of encoding rules is left to the 748 working group. It is assumed that the encoding permits payment 749 messages to be transport via standard Internet protocols through 750 simple processing (e.g. BASE-64 encoding). 752 We define the following data types which are of general use: 754 Identifier : Array [Octet] 756 Amount : Struct 757 value Integer 758 currency Identifier 760 Signed [Any] : Struct 761 data Any 762 certificate AccountCertificate 763 signature_algorithm Identifier 764 signature Identifier 766 Wrapper [Any] : Struct 767 version Identifier 768 message-id Identifier 769 data Any 771 All messages are transported enveloped using the Wrapper structure 772 which states the protocol version and message identifier. 774 Account Establishment and Maintenance 776 The following account options are supported: 778 Accept Payments Only 779 The account will only accept payment. 781 Refuse Payments 782 The account does not accept payments of any type. 784 Micro Payment Transfer Protocol (MPTP) Version 1.0 786 Refuse Micropayment 787 The account permits payments to be made to it but cannot 788 initiate micropayments. Such accounts may be useful for 789 customers who may wish to be able to transfer money into their 790 account but do not require the ability to accept large numbers 791 of arbitrarily small payments. 793 Create Account 795 Account creation requires a binding to be established between an 796 account identifier supplied by the broker, a public key supplied by 797 the potential client and billing information. The exact nature of 798 the billing information is left to implementations. 800 CreateAccountRequest : Struct 801 public_key PublicKey 802 identity_binding ??? 804 AccountFlag : Choice 805 AcceptPaymentsOnly 806 RefusePayments 807 RefuseMicroPayments 809 It might be appropriate to encrypt the identity binding information. 811 Reissue Certificate 813 Depending on broker policy certificates may require frequent 814 reissue. This process may or may not require the establishment of a 815 new public key. Note that this is not a suitable mechanism for 816 dealing with certificate compromise situations. 818 ReissueCertificateRequest : Signed [ReissueCertificateData] 820 ReissueCertificateData : Struct 821 account_id Identifier 822 public_key PublicKey 824 Delete Account 826 The delete account message is used to terminate an account. 828 DeleteAccountRequest : Signed [DeleteAccount] 830 DeleteAccount : Struct 831 account_id Identifier 833 Micro Payment Transfer Protocol (MPTP) Version 1.0 835 Account Certificate 837 The account certificate is returned by the broker in response to an 838 account creation request. 840 AccountCertificate : Signed [AccountData] 842 AccountData : Struct 843 account_id Identifier 844 flags Set[AccountFlags] 845 credit_limit Amount 846 broker_servers List [BrokerServer] 847 attributes List [Attribute] 848 not_valid_before Date 849 not_valid_after Date 851 Attribute : Choice 852 IPAddress 853 mask Address 854 value Address 855 NotGuaranteed 856 amount Amount 857 Guaranteed 858 amount Amount 859 AuthorizationRequired 860 amount Amount 862 Payment Dataflow 864 The payment dataflow consists of three phases. First an account 865 authority is created, next a sequence of paywords is transferred, 866 finally a termination message closes the payment session. Payment 867 sessions may span multiple transport sessions. 869 A payment authority may optionally incorporate a direct payment 870 instruction which does not require confirmation using a pay-chain. 872 Authority 874 Authority : Signed [AuthorityData] 876 AuthorityData : Struct 877 version Identifier 878 authority_id Identifier 879 payer_id Identifier 880 recipient_id Identifier 881 date Date 882 hash_algorithm Identifier 883 chains List [PayChain] 885 Micro Payment Transfer Protocol (MPTP) Version 1.0 887 PayChain : Struct 888 flags Set[ChainFlag] 889 amount Amount 891 ChainFlag : Choice 892 Accepted 893 Pending 895 BrokerServer : Struct 896 address Array [Octet] 897 port Array [Octet] 898 quality Integer 900 It is assumed for the sake of convenience that all pay-chains under 901 a given authority will employ the same hash function. 903 Charge 905 Charge : Struct 906 authority_id Identifier 907 paywords List [PayWords] 908 terminate Boolean 910 PayWord : Struct 911 pay_word Array [Octet] 912 increment Integer 914 The terminate flag terminates a payments session and informs the 915 vendor that no further payments are to be made. 917 Vendor-Broker Communications 919 The collection process permits the vendor to collect payment on 920 paychains 922 Collection Request 924 A collection request consists simply of a list of authority, charge 925 pairs. 927 CollectionRequest : Struct 928 account_id Identifier 929 collections List [Collection] 931 Collection : Struct 932 authority Authority 933 charge Charge 935 Micro Payment Transfer Protocol (MPTP) Version 1.0 937 Collection Response 939 There is no need to respond with an affirmation for every payment. 940 Simply provide a list of the duds. 942 CollectionResponse : Struct 943 status BrokerStatus 944 refusals List [ChainResponse] 946 ChainResponse : Struct 947 authority_id Identifier 948 reason RefusalReason 950 Validation Request 952 Validation requests are required whenever symmetric key signatures 953 are employed. Validation requests might also be required as a matter 954 of broker policy in certain circumstances, such as purchases for 955 large amounts or to guarantee payments. 957 ValidationRequest : Struct 958 vendor_id Identifier 959 authority Authority 961 Validation Response 963 ValidationResponse : Struct 964 broker_id Identifier 965 vendor_id Identifier 966 authority_id Identifier 967 response ValidationResponseCode 968 ValidationResponseCode : Choice 969 Authorized 970 NotAuthorized 972 Revocation List 974 RevocationList : List [Revocation] 976 Revocation : Struct 977 account_id Identifier 978 reason RevocationReason 980 Processing of Data Flows 981 Micro Payment Transfer Protocol (MPTP) Version 1.0 983 [This is a placeholder for detailed descriptions of the required 984 processing steps.] 986 Account Creation 988 _[To Be Specified]_ 990 Account Modification, Enquiry, Deletion 992 _[To Be Specified]_ 994 Payment Flow 996 Session Establishment [Customer] 997 The customer performs the following steps to create an 998 Authority: 1000 1. Calculates PayChains, stores head, may additionally store 1001 all or part of PayChain. 1003 2. Creates unique authority identifier. Alternatively the 1004 paychain root might be used for this purpose. 1006 3. Fills remaining slots in Authority structure. 1008 4. The authority is sent to the vendor. 1010 Session Establishment [Vendor] 1011 On receipt of an Authority the vendor performs the following 1012 steps: 1014 1. The date of the authority is checked to ensure that it is 1015 within the vendor determined permitted timeframe. 1017 2. The authority identifier is checked against those in the 1018 double spending check buffer. 1020 3. The authority identifier is added to the double spending 1021 check buffer. [The vendor may opt to remove expired entries 1022 from the double spending check buffer at this time]. 1024 4. If public key signatures are used 1025 the signature of the customer certificate validated. 1027 5. If public key signatures are used: 1028 The signature of the authority is validated. 1030 6. If the account certificate does not offer the required 1031 payment guarantees or symmetric signatures are used: 1032 A validation request is performed. 1034 7. The Authority is appended to the online file. 1036 Micro Payment Transfer Protocol (MPTP) Version 1.0 1038 Session Establishment with Validation Request [Vendor] 1039 If the vendor determines that an account enquiry is required an 1040 account enquiry is created: 1042 1. The account enquiry packet is created 1044 2. The account enquiry is authenticated using a MAC and a 1045 shared secret established between vendor and broker. 1047 3. The account enquiry is sent to the broker. 1049 Session Establishment with Validation Request [Broker] 1050 1. A Validation Request is received. 1052 2. The validation request is authenticated 1054 3. The account information corresponding to the customer id is 1055 retrieved. 1057 4. A decision is made to accept or reject the authorization. 1059 5. The Validation Response is sent to the Vendor 1061 Session Establishment with Validation Request [Vendor] 1062 On reciept of an account enquiry response a vendor: 1064 1. Checks to see that the response is genuine. 1066 2. Checks to see that the account is authenticated and the 1067 required payments guarantees provided. 1069 The Customer may then send a sequence of Paywords which are 1070 processed as follows: 1072 Payment Transfer [Customer] 1073 The Customer prepares a Charge message as follows: 1075 1. The Authority information corresponding to the vendor id is 1076 retrieved. 1078 2. The Payword(s) corresponding to the desired payment amount 1079 is determined. 1081 3. The Charge message is sent to the vendor. 1083 Payment Transfer [Vendor] 1084 The Vendor processes the Charge message as follows: 1086 1. The vendor receives the charge message. 1088 2. The session record is retrieved using the authority-id. 1090 3. The payword is validated using the paychain root. 1092 Micro Payment Transfer Protocol (MPTP) Version 1.0 1094 4. The payword information and increment are updated in the 1095 session record. 1097 Collection Flow 1099 _[To Be Specified]_ 1101 Resource and Performance Analysis 1103 The critical features distinguishing a micropayments protocol from a 1104 payments protocol are low latency, low processing requirements and 1105 low storage requirements. 1107 Latency 1109 Processing of MPTP micropayments should not introduce noticable 1110 delay into the user interaction of a well written application 1111 program during normal browsing patterns. 1113 Establishment of Payments Session 1115 Establishment of a payment session requires one digital signature to 1116 be generated and two signatures to be checked plus the generation of 1117 one or more paychains. Paychain generation and part of the signature 1118 generation may be performed offline as a background task, reducing 1119 the latency of the interation. 1121 Note that in many cases a sophisticated customer application program 1122 may perform the entire process of creating an authority on a 1123 speculative basis before the user requests a session to be 1124 established. This carries no risk since an authority does not allow 1125 payment unless accompanied by a valid payword and in any case the 1126 authority would not be sent to the vendor unless a session was to be 1127 established. 1129 Subsequent Payments 1131 Subsequent payments require only the generation of the next payment 1132 token in the chain and its verification. The generation process may 1133 be accelerated or avoided entirely through partial or complete 1134 caching of the original paychain. 1136 Processing 1138 The most common processing operation are those connected with the 1139 payments dataflow itself. 1141 Customer 1143 The customer bears the most substantial processing costs. 1144 Establishment requires the creation of a paychain and digital 1145 signature. Offline signature techniques and pre-calculation of 1146 pay-word chains may often be performed as background tasks while the 1148 Micro Payment Transfer Protocol (MPTP) Version 1.0 1150 processor is idle. 1152 Vendor 1154 The vendor must process two signature verifications per 1155 establishment of a payment session and one hash operation per 1156 payword transferred, two if double chains are employed. 1158 Hash chain and signature calculations would normally be calculated 1159 inline. Use of signature screening might be combined with signature 1160 verification to control the inline/offline calculation load. 1162 Broker 1164 The broker must perform one signature verification per collection, 1165 plus one hash calculation per payword transferred. It may be 1166 possible for a broker to perform probabilistic checking of 1167 collection operations, checking only ten percent of a vendors 1168 collection request. 1170 All broker calculations may be performed offline. 1172 Storage 1174 Many proposed micropayment schemes offer low processing overhead but 1175 require large quantities of data to be kept online for rapid access. 1176 Where the frequency of incomming requests is high online access 1177 cannot be satisfactorily provided by secondary storage such as disks 1178 since head contention becomes the limiting factor. Online storage 1179 requirements are thus effectively RAM storage requirements. 1181 Offline storage requirements are unlikely to be a significant factor 1182 in the economics of a payments scheme. Many existing servers handle 1183 a heavy load of incoming requests while keeping comprehensive log 1184 files. 1186 Customer 1188 The customer must track each open session. It may in addition be 1189 desirable to store the computed paychains in complete or partial 1190 form. 1192 Vendor 1194 The vendor must maintain an online record for each open session. 1195 This record is fixed in length consisting of the authority 1196 identifier and payer identifier from the authority, and the paychain 1197 root or most recent valid pay-word plus the currency unit. 1199 Prevention of double spending requires the maintenance by the vendor 1200 of an online record of all payment sessions established within the 1201 timestamp validity window. Note however that it may be desirable to 1202 place loose limits on validity windows to permit use of speculative 1204 Micro Payment Transfer Protocol (MPTP) Version 1.0 1206 calculation of authorities. 1208 A server satisfying 100,000 micropayment operations per hour of 1209 which 10% are session establishment requests would require only 8Mb 1210 of online storage for both recording of current sessions and 1211 maintenance of the double spending prevention window. Such a server 1212 would generate $1000 per hour at a cent per transaction which would 1213 be more than enough at present prices to meet the cost of the 1214 memory. 1216 Broker 1218 If the symmetric signature option is not provided the broker may 1219 perform almost all operations offline in batch. Incoming collection 1220 requests from vendors may be pre-processed to optimize access to 1221 secondary storage such as disk. Detection of double spending 1222 requires a record of all transactions to be available at the time 1223 when a record is added. This need not involve the expense of online 1224 memory however. 1226 One way round the double spending problem is to give each vendor a 1227 counter which must be incremented at each step. It is then only 1228 necessary to keep one online storage location per account. Note 1229 however that it is undesirable that this token be advertised to the 1230 customer since it would reveal the number of purchase requests made 1231 to that vendor. Another problem would be enforcing the serialization 1232 of the tokens, what would happen if one customer terminated a 1233 session much later than one started after it? This would seem to 1234 imply that the serialization option would require rapid redemption 1235 of the tokens which is itself undesirable. 1237 If the symmetric signature option is provided the registry of shared 1238 secrets must be available in primary storage. In most practical 1239 schemes this will require the data to be stored in RAM. 1241 Commentary and Further Work 1243 This proposal is considered incomplete and comments are invited. A 1244 number of additional considerations which might be explored are 1245 noted below. 1247 Benchmarks and statistics 1249 It would be useful to have timings for the various processes 1250 involved and more comprehensive estimates of relative costs. 1251 Detailed statistics concerning customer browsing patterns would be 1252 an advantage. How frequently does a customer change site, what 1253 proportion of one off purchases does a customer make? 1255 Risk factors 1257 Statements concerning the relative importance of various risk 1258 factors to potential customers, vendors and brokers would be of 1260 Micro Payment Transfer Protocol (MPTP) Version 1.0 1262 assistance. 1264 Inter-Broker Settlement Model 1266 The protocol described requires perfect trust between servers acting 1267 as brokers. Compromise of one server compromises all others. The 1268 provisions allowing for multiple servers are not designed to permit 1269 multiple brokers competing brokers to participate within a single 1270 payment system. 1272 In a large scale use more than one organization would offer broker 1273 services but payment transfer should be possible nevertheless even 1274 if the parties did not have a common broker. Each transaction may 1275 thus involve two brokers, in credit card terminology an acquiring 1276 (vendor appointed) bank and issuing (customer appointed) bank. In 1277 addition the services of a clearing house may also be required. Such 1278 a provision is probably essential to the long term acceptability of 1279 a scheme. 1281 The chief difficulty in extending the scheme concerns the 1282 establishing to what trust relationships may be assumed between 1283 brokers and to what degree enforcement mechanisms must be provided 1284 for. If brokers are able to establish a high degree of trust the 1285 impact upon the protocol is small. If brokers are unable to 1286 establish such trust the impact might be large. 1288 As an example of a nave Inter-Broker settlement scheme let us 1289 consider extending the certification hierarchy to include one or 1290 more broker certification authorities. We assume that inter-broker 1291 settlement takes place either through direct exchange of payment 1292 orders or employs the services of a clearing house. The only direct 1293 impact of these changes as far as the customer and vendor are 1294 concerned is the need to authenticate the broker certificate. 1296 The impact on the broker trust relationship is more complex. In 1297 particular a customer's broker has the opportunity to commit fraud 1298 with negligible probability of detection. On receipt of a payment 1299 instruction a customer broker might deduct the amount from the 1300 customer's account but report it as bad credit to the vendor's 1301 broker. 1303 A more subtle problem concerns the trust relationships between the 1304 vendor and the vendor's broker. In the credit card system this 1305 relationship is transparent. The identity of the vendor's broker is 1306 not revealed either to the customer or even the customer's broker. 1307 While this is a significant disadvantage for a scheme intended to 1308 use the credit card charging infrastructure as previously noted this 1309 need not be the case. 1311 Many of the trust and information sharing issues connected with the 1312 introduction of inter-broker settlement may be rendered moot by the 1313 nature of the initial acceptance community. In particular the 1314 question of which party bears what risk is central to this issue. It 1316 Micro Payment Transfer Protocol (MPTP) Version 1.0 1318 is therefore premature to make a detailed proposal concerning this 1319 issue. 1321 Wider Application 1323 MPTP is a general resource management protocol. It might also be 1324 used for control of resources such as printer pages [Hallam-Baker 1325 95b], CPU time and similar low unit cost items within an 1326 institution. MPTP might also be applied to provide resource 1327 constraint enforcement in applications such as interactive 1328 multi-player games (e.g. MUDs, MOOs). [Hallam-Baker95a] 1330 Another potential application area is authorization. MPTP might be 1331 used to establish generalised and decentralized authorization in a 1332 distributed environment in a similar manner to Kerberos. 1334 Security Considerations 1336 This whole document is about security 1338 Patent Rights 1340 A number of companies sell patent rights to public key technology. 1341 The legal status of a number of these patents is currently disputed. 1342 Until then the standard IETF spiel with a revision to the PKP bit 1343 will appear here. Reports have also surfaced that the CAFE 1344 consortium may have a patent covering certain uses of S/Key 1345 technology with respect to payments applications. 1347 References. 1349 [AccreditedSC93a] _Working Draft: American National Standard 1350 X9.30-1993: Public Key Cryptography Using Irreversible Algorithms 1351 for the Financial Services Industry: Part 2: The Secure Hash 1352 Algorithm (SHA)_ Accredited Standards Committee X9 1993, 1353 [BellareEt95] 1354 _Internet Keyed Payment Protocols (iKP)_ Mihir Bellare, Juan A. 1355 Garay, Ralf Hauser, Amir Herzberg, Hugo Krawczyk, Michael 1356 Steiner, Gene Tsudik, Michael Waidner: In Proceedings of the 1357 First USENIX Workshop on Electronic Commerce, New York, July 1358 1995 1360 [ElGamal85] 1361 _A Public Key Cryptosystem and a Signature Scheme Based on 1362 Discrete Logarithms_. T. El Gamal. IEEE Trans. Inform. Theory, 1363 Vol.31, 1985, pages 469--472 1365 [EvenGoMi90] 1366 _Online/offline digital signatures._ S. Even, O. Goldreich and 1367 Silvio Micali. CRYPTO 89, pages 263-277. Springer-Verlag, 1990, 1368 Lecture Notes in Computer Science No. 435. 1370 [Haler94] 1372 Micro Payment Transfer Protocol (MPTP) Version 1.0 1374 _The S/Key One-Time password system._. N. M. Haller, In ISOC 1375 1994 1377 [Hallam-Baker95] 1378 _Electronic Payment Schemes_. P. M. Hallam-Baker. 1379 http://www.w3.org/pub/WWW/Payments/roadmap.html 1381 [Hallam-Baker95a] 1382 _Multi User Dungeons_ P. M. Hallam-Baker 1384 [Hallam-Baker95b] 1385 _Why Printing Should be via The Web_ P. M. Hallam-Baker 1387 [Lamport81] 1388 _Password Authentication with Insecure Communication_ L. 1389 Lamport, Communications of the ACM Nov 1981 pages 770-771. 1391 [Manasse95] 1392 _Millicent (electronic microcommerce) _ Mark S. Manasse. 1995. 1394 [NIST91] 1395 _Digital Signature Standard (DSS)_ National Institute for 1396 Standards and Technology Federal Register, vol 56 No. 169 August 1397 1991. 1399 [Pedersen9?]Technical report? Torben Pedersen, DAIMI, Aarhus 1401 [Rabin79] 1402 _Digital Signatures and Public Key Functions as Intractable as 1403 Factorization"_. M. O. Rabin. MIT Laboratory for Computer 1404 Science Technocal Report, MIT/LCS/TR-212 Jan 1979. 1406 [Rivest92c] 1407 _RFC 1321, The {MD5} Message-Digest Algorithm_ R. L. Rivest, 1408 Internet Request for Comments, April 1992 1410 [RivestSh95] 1411 _PayWord and MicroMint--Two Simple Micropayment Schemes, R.L. 1412 Rivest and A. Shamir. (To Appear.) _ 1414 [RivestShAd78] 1415 _A Method for Obtaining Digital Signatures and Public-Key 1416 Cryptosystems_ R. L. Rivest, A. Shamir and L. M. Adleman. CACM, 1417 Feb 1978 p 120-126. 1419 [Schneier96] 1420 _Applied Cryptography (Second Edition)_. Bruce Schneier, John 1421 Wiley & Sons 1996. 1423 [Shamir95] 1424 _Fast Signature screening_. CRYPTO'95 rump session talk. to 1425 appear in RSA Laboratories _Cryptobytes_. 1427 Micro Payment Transfer Protocol (MPTP) Version 1.0 1429 [SteinStBoRo94] 1430 _The Green Commerce Model_ L. H. Stein, E. A. Stefferud, N. S. 1431 Borenstein and M. T. Rose, Internet Draft. October, 1994, Work 1432 in Progress. 1434 Acknowledgements 1436 Thanks are due to Ron Rivest and Adi Shamir for their suggestion to 1437 use a chained hash function. The help and advice of Rohit Khare, 1438 Dave Ragget, Jim Gettys and Mark Manasse were of great assistance in 1439 producing this proposal. 1441 Contact 1443 The author may be contacted via email at hallam@w3.org 1445 To Do List 1447 * Check over symmetric key mode 1449 * Firm up language, inline/offline poorly explained, establishment 1450 of payment session etc. Label each term introduced and check for 1451 definition. [would not a tool for this be nice] 1453 * Message id business is poorly explained. 1455 * Should firm up the collection loop semantics. It is not 1456 absolutely essential that payments be collected only once. If 1457 the server can check against double spending could allow partial 1458 and incremental collection 1460 * Consider leakage of data to various parties. 1462 * Protection against double spending by customer currently 1463 requires each vendor to maintain an online check of all previous 1464 payments by the customer. This is weak protection and could be 1465 firmed up substantially. 1467 * Include a challenge response loop to initiate the establishment 1468 instruction, thus ensuring that double spending cannot take 1469 place? 1471 * Response messages by the broker should be considered somewhat. 1473 * Consider the specific case of payment for software on an hourly 1474 basis in detail. 1476 * The issue of maintenance of blacklists by individual merchants 1477 requires special attention. 1479 * Should there be a reputation mechanism built into the system so 1480 that poor payers suffer a declining credit rating which is 1481 advertised in their certificate? 1483 Micro Payment Transfer Protocol (MPTP) Version 1.0 1485 * Need to consider the issue of account enquiries. There should be 1486 a mechanism whereby a client can rapidly ascertain that the 1487 broker account is correct, establish which funds are cleared 1488 etc. 1490 * Should there be a validity interval for payments built into each 1491 payment order (cash by date) built into each authority? 1493 * Should there be a do not pay before date in a payment authority? 1495 * Additional references: Kerberos, HTTP, SMTP, MIME. 1497 Expires May 27th 1996